Legacy GM Cheap trick to speed up your games.

Misty

Member
GM VERSION: GM STUDIO
Target Platforms: Unknown, but probably all of them.
Download and Links: N/A

Summation: A cheap trick to give you a 20-50% performance optimization in your game.

Tutorial:
Go in the Room Editor and disable "Clear Display Buffer With Window Color".

Create a new object called "ortho".
Set it's depth to -1000.
Put in it's Create Event:
Code:
application_surface_draw_enable(false);
inc=0;
EDIT:
Put in it's Step Event:
Code:
// toggle inc between true and false each step
inc=!inc

if (inc) draw_enable_drawevent(1);
else
draw_enable_drawevent(0);
Put in it's Draw Gui Event:
Code:
draw_surface(application_surface, 0, 0)
draw_set_color(c_white);
Also remember to disable fog and lighting before the draw, and reenable it afterwards if you are in 3D. Also remember that game critical code, if it is in the Draw Event, is skipped for one frame.

This code works by only rendering half of the frames. The application surface is the default surface that GM renders the scene to. Normally it is enabled by default but in this code we want to control when we draw it ourselves. This is analogous to the old function in GM8 called set_automatic_draw.
Clear Display Buffer must be disabled, because if you enable it, it fills the screen with a solid color eliminating the afterimage effect.

This is a neat trick that skips the rendering of a frame but tricks the human eye into thinking it's smooth, because there is a transparent afterimage left over from the last frame allowing the eye to interpolate the frames like in movies.
Even without the frame boost, the afterimage looks kind of neat, and professional.

This is not the end of the tutorial. The tutorial continues onward, with you.
This topic is dedicated to posting optimization tips to the new GM Studio.
 
Last edited:

KurtBlissZ

Member
I can see this being useful in some games but probably not all, since you do get a visual effect from it, it probably varies how good it looks from game to game.

One big performance saver I can think of is taking advantage of being able to resize instances in the room editor, then using the sprite_width and sprite_height variables when determining what size to draw your walls, floors, and blocks. So instead of placing a bunch of small walls and floors together you just resize them to bigger peace’s too lesser down the performance. I imagine there's even better methods of drawing but that's always been easy to do.

I don't know what monitor you have, but I see a clear flickering effect, but this seems interesting
I think that happens when you skip these two things, go in the Room Editor and disable "Clear Display Buffer With Window Color" or setting its depth to -1000.
 

obscene

Member
Considering everything in your game is still being drawn to the application surface every frame, simply not drawing the application surface every other frame would seeminly do nothing.

How about this... draw_enable_drawevent(enable);
 

Misty

Member
Here is a clear indication of what dropping alternate frames looks like

http://www.testufo.com/#test=framerates-text&pps=240

And that's 60 FPS cut back to 30. God forbid what 15 FPS would look like.
Most games do not involve walls of text, but that leads me to something after I noticed the inherent ocular blur of 30 fps.
If you want your game to be more dreamy and cinematic, set it to 30 fps. If you want your game more bright and focused, set it to 60 fps.

Very interesting, I'll have to check this out. Also you can simplify the code that toggles inc to:

inc = !inc;
Thanks, I will add it to my tutorial.

Considering everything in your game is still being drawn to the application surface every frame, simply not drawing the application surface every other frame would seeminly do nothing.

How about this... draw_enable_drawevent(enable);
Thanks, I will add it to my tutorial.

I just think this whole topic wasn't thought through. How it 'qualified' as a tutorial bewilders me.
It is being upgraded, and updated as we speak. All good tutorials are flexible.
 

RangerX

Member
To me this more sounds like a thread where we should all share the optimizing tricks we learned.
What the tutorial here suggest isn't like a general solution someone would expect to find here. Doing what it suggest is very specific and would benefit only certain games. There's also tons of other general stuff people should attempt in order to optimize their games before chopping frames like this.
 

Misty

Member
Such as?

I cannot underestimate the success of this example. The fps has been doubled, literally been doubled, ease on the CPU.
 
Last edited:

RangerX

Member
I already gave general suggestions earlier in the thread Misty.
Might add more in the future if the thread is still moving.
 

Misty

Member
Already read the blogs, in fact that is what set me on the path to make this example in the first place.

To be honest, none of the techniques in the blogs actually improved my fps, sad as it is.
 

Misty

Member
Of course the 'reported' FPS will double as you are drawing half as much and making the project twice as choppy along with it.

Actual FPS is halved.

CPU load will remain the same BTW, it will only ease the load on the GPU.

So in essence, your hack doesn't do anything except make the game look laggy and choppy.

My guess is that CPU and GPU are linked, so when one goes down both go down.

And it doesn't look choppy, it creates the illusion of smoothness because of how the human eye works and how it registers buffered after images.
 

RangerX

Member
Of course the 'reported' FPS will double as you are drawing half as much and making the project twice as choppy along with it.

Actual FPS is halved.

CPU load will remain the same BTW, it will only ease the load on the GPU.

So in essence, your hack doesn't do anything except make the game look laggy and choppy.

That's how I feel.
What this "tutorial" suggest isn't an optimization but rather a compromise.
 

JML

Wabbajackalope
misty this is not a hack you are just drawing half the frames, of course the fps counter would increase but by the same logic you could put in a step counter to do it once every three frames and that would make it even more powerful.

now with that said their could be potential here by selectivly apply this to specific objects in a room by only drawing an object when it moves but as it is, unless their is something huge im missing here, you could accomplish the same thing by just changing the fps in the room options AND doing it the way you are you are (double you are intentional) making the player blind to half the loops going on on the screen which will limit the players ability to respond to the events occuring in game.

please let me know if im at fault on this and if so could you go into detail about precisely why.

thank you.
 

Misty

Member
You'd be guessing wrong (again).

There are actually ways of balancing both to further increase framerate. But this is way beyond the scope of your *cough* tutorial.

Maybe I'll write one some time for you ;)
Don't do it only for me, but for the community as well.

This technique will double the internal loops of the game, allowing games with higher precision. Also it smooths it with the afterimage effect.

If you had a game running at 60 fps, if you do this it will run at 120 fps doubling your loops, while keeping the same framerate of 60 fps + smoothing effect so it actually looks like 90 fps.
 
Last edited:

Misty

Member
Then you introduce 'tearing' as you wont be able to run your 'technique' at vSync.
It's a small price to pay.

If you have vSync enabled you don't 'magically' get 120 logic loops, you get 60 along with a framerate of 30 FPS.
Then don't enable vSync.
vSync is the equivalent of non-interlaced video. Noone really needs it or notices it, its a small bell and whistle.
 

Misty

Member
Huge price to pay, if you ask me.
On people with super computers who get no lag even from GM games who need 8x antialiasing and vsync, yes.

On people just trying to improve their framerates, not so much.

And you are not getting any benefit from your magical logic loop doubling. None whatsoever.
I explained the speed boost behind it earlier.
 

ParodyKnaveBob

The Laughing Rogue
Fwiw, about V-sync...

It's a small price to pay.

Then don't enable vSync.
vSync is the equivalent of non-interlaced video. Noone really needs it or notices it, its a small bell and whistle.
This past week, I was playing a game that was overall pretty fun, but the noticeable non-V-sync got really distracting at times. It was already a high-tension die-at-any-moment action platformer, thus adding fidgety video tearing to things catching the player's eye didn't help matters at all.
On people with super computers who get no lag even from GM games who need 8x antialiasing and vsync, yes.

On people just trying to improve their framerates, not so much.
I don't have a supercomputer. I have a subcomputer. (I'm not complaining about it. I'm just describing. It has low RAM, low GHz, and it's been known to crash playing browser Flash games. Ontop that, my DirectX broke some while back.)

Regards, ~nodnod~
Bob
 

Surgeon_

Symbian Curator
Actually this isn't anything new, I remember some time back when draw_enable_drawevent(bool) had just been introduced to GMS, I included exactly this in my game (Though I'm pretty sure I wasn't the first one to do so). Of course, it's a choice in settings, so people can choose for themselves if it's worth using.
And I made it so that it triggers only when FPS drops a few frames below room_speed - so ideally it would only skip frames in performance intensive situations, but considering how choppy these would be at full load it should make the game less choppy overall. This is something you may want to add to the tutorial.
All in all, from my experience it does help with performance and isn't that noticeable if your game's room_speed is 60 (because that's 30 when cut in half, and, even though it's not a very fair comparison, most movies are in 24 fps, so it's bearable). However, if your room_speed is capped at 30, I'd say don't bother with this, it would probably look terrible.

-Surgeon_
 

chance

predictably random
Forum Staff
Moderator
Actually this isn't anything new, I remember some time back when draw_enable_drawevent(bool) had just been introduced to GMS...(snip)
I recall lots of discussion about techniques like these on the old GMC -- as well as lots of confusion. Same for disabling the automatic draw to the application surface. There are definitely good uses for these functions in GM, under the right circumstances. But understanding the potential benefit (if any), versus the illusion of benefit, can sometimes be subtle.

So I think this discussion is useful.
 

Surgeon_

Symbian Curator
Guys you're missing the point here. The whole point of this trick is to trade off visual quality in order to make the game's logic more smooth and responsive. Yes, there's no doubt that if you skip every other frame the game will look more jittery, but behind the scenes it will run better. And the human brain can "interpolate" and make up for the missing images, but it can't make up for the missed inputs caused by the slow-running game logic.
 

Roa

Member
Guys you're missing the point here. The whole point of this trick is to trade off visual quality in order to make the game's logic more smooth and responsive. Yes, there's no doubt that if you skip every other frame the game will look more jittery, but behind the scenes it will run better. And the human brain can "interpolate" and make up for the missing images, but it can't make up for the missed inputs caused by the slow-running game logic.
It doens't make the logic smooth at all. Step events tick all the same and cutting visual responce back to the player deffintly doesnt make it feel responcive. Those things are mutually exlusive. It's not even really interpolated. It's just simply not clearing the back buffer. That means you see the same image for twice the frames. Its like a cheap frame skip without much of the benefits.

And I swore before the edit that this said something about using orthographic project, which is the last thing I think of when it comes to drawing speed.
 

seanm

Member
If you skip frame drawing you get twice the input polling, as opposed to drawing the frame, and having both logic and render slow down.
 

Surgeon_

Symbian Curator
Step events tick all the same
Well the problem is that they don't. Let me give you an example: In a 60 fps game one frame should take up a maximum of 17ms (a bit less actually, but let's go with 17 for the same of simplicity). Not let's say that everything in the Step events and everything else before Draw events needs 10ms to be processed. That's okay for now. But what if you have some really demanding graphics so that the Draw event also needs 10ms to be processed? Now the game cannot run at full speed and suddenly 60 steps of game time is not one second of real world time, but rather 1,2 seconds. Now with frame skipping, you give your game some room for breathing every other step. So now you have 30 frames which last 20ms, and 30 frames which last for the optimal 17 ms - and this, in real world time, is ~1100ms - which still isn't what we're going for, but it's definitely better. On computer with poor graphic handling, the draw event could very well take more time than the others, and there this betterment would be even more noticeable.

And here's a real-world example:
A few days ago I was playing Wrath of the Lich King with some people online and we were doing some random dungeon. At one boss we encountered a bug, which made so many particle effects that the game which is almost a decade old ran at a pathetic 14 fps, and my PC isn't bad at all. Now usually all of my abilities share a 1,5 sec cooldown so I spam them every 1,5 seconds. But when the game started crawling, I could not cast a spell every 1,5 seconds because the game was too sluggish, as same goes for other player from the party and the boss wiped us all. Now imagine if the game processed the graphics every 5 frames instead of every frame - yes, this is an extreme example but on the average the responsiveness would have been better and maybe we would have beaten the boss.

So all in all, this cannot solve all of your problems if the draw event takes too long to process, but it can, on average, make the game run better.

EDIT: As I said before, with things of this kind, you should include an on/off switch somewhere in the game because you can't predict what will happen in any given situation - so the players can turn it on if it helps, and ignore it if it doesn't.
 
Last edited:

Roa

Member
Well the problem is that they don't. Let me give you an example: In a 60 fps game one frame should take up a maximum of 17ms (a bit less actually, but let's go with 17 for the same of simplicity). Not let's say that everything in the Step events and everything else before Draw events needs 10ms to be processed. That's okay for now. But what if you have some really demanding graphics so that the Draw event also needs 10ms to be processed? Now the game cannot run at full speed and suddenly 60 steps of game time is not one second of real world time, but rather 1,2 seconds. Now with frame skipping, you give your game some room for breathing every other step. So now you have 30 frames which last 20ms, and 30 frames which last for the optimal 17 ms - and this, in real world time, is ~1100ms - which still isn't what we're going for, but it's definitely better. On computer with poor graphic handling, the draw event could very well take more time than the others, and there this betterment would be even more noticeable.

And here's a real-world example:
A few days ago I was playing Wrath of the Lich King with some people online and we were doing some random dungeon. At one boss we encountered a bug, which made so many particle effects that the game which is almost a decade ran at a pathetic 14 fps, and my PC isn't bad at all. Now usually all of my abilities share a 1,5 sec cooldown so I spam them every 1,5 seconds. But when the game started crawling, I could not cast a spell every 1,5 seconds because the game was too sluggish, as same goes for other player from the party and the boss wiped us all. Now imagine if the game processed the graphics every 5 frames instead of every frame - yes, this is an extreme example but on the average the responsiveness would have been better and maybe we would have beaten the boss.

So all in all, this cannot solve all of your problems if the draw event takes too long to process, but it can, on average, make the game run better.

EDIT: As I said before, with things of this kind, you should include an on/off switch somewhere in the game because you can't predict what will happen in any given situation - so the players can turn it on if it helps, and ignore it if it doesn't.
Ok.. but disabling the application surface doesn't stop the draw event from being processed, it just draws it immediately to the screen buffer, which for some devices is faster NOT because it disables drawing, but because its not drawing once to the app surface and then again to the screen surface. And gamemaker is strictly a tick based engine. True frame skipping is not available because the graphics and the logic are not asynchronous. You can lighten the load possibly, but the events get cycled through whether you expect them to or not. As far as I know, there is no way to avoid an event cycle period, and only the yoyo compiler strips out checking individual cycles for instances.
 

Surgeon_

Symbian Curator
But look at the opening post, it's talking about draw_enable_drawevent(bool);
If you call it every step with alternating values, like Misty wrote, then you truly can skip the whole draw event for that step. But I agree with you that drawing the application surface manually or automatically doesn't make a difference.
 

Roa

Member
so it seems you can skip the entirety of draw events.

But here is a question, why would you do this even if you were lagging? if 60 fps or 30fps are the goal of the game, I would be less concerned about keeping the logic rate at a different rate than the draw FPS. There is no delta time, and by the time the engine realizes it needs to drops frames, the damage has been done to the logic, so you're just taking visual feed back from the player with no benefit. Nothing is proactive, just reactive.

I mean.. unless you start the game skipping frames, but then why even make it 60 fps at all, you know? lol
 

Surgeon_

Symbian Curator
Hmm, you're right, I didn't think about that.
Still, that's why you need to make it toggle-able. So if the player knows that their computer is a potato, they can play the game with frame skipping. Though this really is a bad and lazy way to... well, not optimize, but speed up the game, and should be used only as a last resort when there's nothing left to optimize. It's an option, though.
 

Jaqueta

Member
This should be interesting for my Game Process|Possess, the game runs at 60 FPS, I can do that as an option for the player, since it's not everyone that feels comfortable with 30FPS xD, thanks for the idea!
 

BLang

Member
If you had a game running at 60 fps, if you do this it will run at 120 fps doubling your loops, while keeping the same framerate of 60 fps + smoothing effect so it actually looks like 90 fps.
Wow, are you really implying that rendering 30 frames per second will make my games look like they're running at 90 fps?

I don't mean to be rude, but this is definitely not going to increase your fps, and it's not gonna make it feel like the fps is higher. This is effectively just sacrificing half your frames, which might make the game logic 'smoother', but it's all the same to the player. Trust me. 30 fps is 30 fps, and few people will be able to appreciate that there's actually two logic steps beneath one frame.

There are better ways to optimize your games, and they're usually project specific. No solution is one size fits all.
 

chance

predictably random
Forum Staff
Moderator
No solution is one size fits all.
Very true. Nobody is claiming otherwise.

But I agree we should avoid specific claims about frame rate, and what the effect will "look like". Because that depends entirely on the circumstances. Better to just present the approach.

Personally, I've seen increases in reported FPS, and in the perception of smoothness, by skipping DRAW events (but still updating other events and instance variables). So these technique definitely have uses. But they aren't a general solution for a game that's lagging.
 

Misty

Member
Wow, are you really implying that rendering 30 frames per second will make my games look like they're running at 90 fps?

I don't mean to be rude, but this is definitely not going to increase your fps, and it's not gonna make it feel like the fps is higher. This is effectively just sacrificing half your frames, which might make the game logic 'smoother', but it's all the same to the player. Trust me. 30 fps is 30 fps, and few people will be able to appreciate that there's actually two logic steps beneath one frame.

There are better ways to optimize your games, and they're usually project specific. No solution is one size fits all.
If you get 30 fps, you aren't doing it right.

I said 120 fps, not 30. Big difference.

You are supposed to set the room speed to 3000, so if you have 60 fps you should get 120 fps after this method.
Then combine that with the blur, and viola, the illusion of 90 fps.

I never play my games with Vsync.
 
Last edited:

RujiK

Member
Then combine that with the blur, and viola, the illusion of 90 fps.
Most monitors only go to 60 fps... So 60 fps or 6000 fps will look the same.

EDIT: If Vsync is off, 100 fps may look slightly better due to the game loop and the hardware loop not being synced..
 

RangerX

Member
so it seems you can skip the entirety of draw events.

But here is a question, why would you do this even if you were lagging? if 60 fps or 30fps are the goal of the game, I would be less concerned about keeping the logic rate at a different rate than the draw FPS. There is no delta time, and by the time the engine realizes it needs to drops frames, the damage has been done to the logic, so you're just taking visual feed back from the player with no benefit. Nothing is proactive, just reactive.

I mean.. unless you start the game skipping frames, but then why even make it 60 fps at all, you know? lol
Like me, Jas, Chance and other said, Misty solution is by no mean a good general solution for lagging games. However, knowing you can skip a draw event can actually be useful. Its all about how much you want your game to run on a crappy machine really. Many might not care, some dev might. Personally I had fun making some "performance adapting system" for my game in dev The Life Ruby. I found fun in doing this because another person that is working with me is having a certain model of integrated HP graphic card that really doesn't like GMS surfaces or GMS in general and the game runs inexplicably crappy on it. Just feel like sharing what my system does:

- Check the fps for 10 seconds once in a certain room.
- If I average at 55 fps or less, I step into phase 2: I disable the application surface.
- Check again the fps for 10 seconds.
- If I average again at 55 fps or less I step into phase 3: I skip one out of 2 draw events.

Of course you don't WISH for a player to get to phase 3 really. But if that makes a couple more players enjoying the game still, it makes me happy as a designer.
 

Roa

Member
Yeah, I dont buy it. Interpolation doesn't make it feel like higher frames. It just makes the visuals less responsive to input making the player feel less in control of the game.

60 true fps is 60 true fps and nothing feels like it. It's starting to sound like capcom in here. "Dante's inferno runs at a comfortable 30fps that feels like 60 fps"
 
Last edited:

ParodyKnaveBob

The Laughing Rogue
Another "fwiw" to add:

In the Super Mario World (SNES) level "Yoshi's Island 2," you can run forward at the start, auto-pick-up a Koopa shell, then jump and kick the shell at a long line of Koopa Troopas for a fun 1UP. This creates so much activity onscreen at once, it inevitably causes "slow down." The visuals slow, the inputs slow, the sound effects and music stutter due to slow, etc. The output is absolutely, directly linked to the logic cycle. I found it interesting, as one who enjoyed studying and breaking and learning software as such, but when it actually affects the gameplay, it can get really frustrating. (There's a Nintendo 64 game which constantly hit slow-down, and it could really wreak havoc with the meticulously timed multi-button-sequence combinations you needed. So annoying.)

In any Star Fox (SNES) level where you have gobs and gobs of destruction everywhere, and of course you're firing Twin Blasters like mad, plus perhaps launching a Smart Bomb, the on-screen drawing can screech nearly to a halt, yet the sound and music continue, letting you know the input and logic cycle continue, too. It creates a harrowing experience of desperately trying to keep track of the last thing you saw for aiming/flying purposes and hammering the Blaster and Barrel Roll buttons. Very fun. $:^ D

Of course, I don't know how you young'uns today perceive such nuances exactly. I started laughing the first time I heard/read someone talk about 60 frames per second as if it were a baseline standard (over a decade ago) -- as if we hadn't been watching 30-frame-per-second television for half a century and 24-frame-per-second movies for over a century by that point. Ha ha ha ha. Baseline. Ha ha ha ha. $F^ b

It's okay. I know I'm an old fuddy duddy to some folks. Oh well. $E^ b Regards,
Bob $:^ b
 

RangerX

Member
Well, many many games on NES and SNES were actually running at 60fps, I would even say that even back then (am old too) I always disliked 30fps side scrollers more and the 60fps ones always felt better.
Of course there was slowdown, sprite flickers and the characters themselves did not have 60 fps at all but the general movement, transitions were and it felt sooooo good.

60fps or bust I say. That SHOULD be an industry standard or for anyone with decent quality/graphical fidelity concerns.
 

chance

predictably random
Forum Staff
Moderator
Yeah, I dont buy it. Interpolation doesn't make it feel like higher frames. It just makes the visuals less responsive to input making the player feel less in control of the game.
I agree. But that's not really the intent here -- as least not for me. My intent would be to reduce DRAW event updates as needed in order to preserve the underlying flow of the game, as PBK described it above.

I wouldn't recommend using this techniques routinely throughout the game. But I can see the benefit of an adaptive approach, similar to what Ranger outlined.
 

spinout

Member
I hope I don't find any downfalls on this cause WOW, did this ever give my game a good boost. So far it looks good. I'll keep testing. Thanks!
 

Misty

Member
I hope I don't find any downfalls on this cause WOW, did this ever give my game a good boost. So far it looks good. I'll keep testing. Thanks!
You are welcome.

Just want to update this topic with more news about the war against lag.

I ran a bunch of models in GM, each had a different texture. It was about 3200 triangles and it ran at 160 fps.
I ran a bunch of models in GM, each had a different texture. It was about 1200 triangles and it ran at 200 fps.
I did a test measuring the microseconds. It took only 40 microseconds to render the models.
Then I found a lag in my game, the lag was from 1 d3d_block. 1 d3d_block takes 800 microseconds to render (nearly 1 millesconds.)
But at 60 fps, you can only have up to 16 milliseconds to use in each frame.
The lesson is...Better graphics can reduce the lag in your game.
Instead of using cheesy d3d_blocks, put in more detailed d3d_models. Even a 1000 poly model will lag less than a d3d_block.
Also, when you make a model, only make one of each model and make it a global model that is destroyed after the game ends. Don't make a model for each instance.
Also, when you have 3d billboards, don't draw the billboard for each instance, make a billboard handler that is a persistant object that draws each billboard using a cam transform.
 

zendraw

Member
actually it doesnt boost anything and it looks terrible. ive tested it just now.
with it, and nothing intensive going on it boosts from 400-500 to 1200-1800;

now usually without this cheap trick when i add 100 intensive instances, my fps drops from 400 to 60, which is also the room speed of my game.
with this trick it also drops my fps to 60 with 100 instances.

so what exactly does this trick do when in action it has no positive effect atall but actualy negative?

a real optimisation is when in actions things work better and more smoother and faster, not when nothing is going on.
 

Misty

Member
actually it doesnt boost anything and it looks terrible. ive tested it just now.
with it, and nothing intensive going on it boosts from 400-500 to 1200-1800;

now usually without this cheap trick when i add 100 intensive instances, my fps drops from 400 to 60, which is also the room speed of my game.
with this trick it also drops my fps to 60 with 100 instances.

so what exactly does this trick do when in action it has no positive effect atall but actualy negative?

a real optimisation is when in actions things work better and more smoother and faster, not when nothing is going on.
Hmm...which trick did you do?

Also, there might be other factors which you may have overlooked, which may have caused the fps loss.

I need more information to analyze your performance. If your game is not some top-secret project and you can PM me the gmz that would be great, I have GM Studio 1.4.
 

zendraw

Member
the one that you posted in your first post
Code:
inc=!inc

if (inc) draw_enable_drawevent(1);
else
draw_enable_drawevent(0);
i alredy draw my surface manually so all i did is add the skip in the step event.
what other factors are you talking about?
 

Misty

Member
the one that you posted in your first post
Code:
inc=!inc

if (inc) draw_enable_drawevent(1);
else
draw_enable_drawevent(0);
i alredy draw my surface manually so all i did is add the skip in the step event.
what other factors are you talking about?
I'm not sure. I'd need to study the editable. It's been a while since I made this topic and I'd have to get antiquated with the ins and outs.
 
He worked on my 2D project, thank you very much, you know how to replace this piece of code
(Application_surface, 0, 0)?
Why also deactivate the surface application to have even more performance, greetings, someone to explain to me if you can change application_surface by another function
 
Top