Optimization

[squirrelah]

I have a few questions about optimizing for increased performance. I know very little about this, so any tips will help, but I also have a few direct questions.

Is there a benefit to using events like left mouse pressed, keyboard pressed, key pressed, etc above setting a variable in the step event equal to change the variable to true if it is pressed and then running everything in the step event?

For example, let's say I want my character to move up when I press "w". To do this I have a variable set to true when w is pressed, and then code that moves him up when that variable is true in the step event.

Alternatively, I could just have that code run in the "key pressed letters "w"" page, and not have it run every step.


In addition how many global variables is too many? I know it can affect performance issues, but I don't really have a clear understanding of when it becomes too many. I think right now I have about 30 and I don't notice any issues, and I only use them because it was a lot simpler to do so.

Or is any of this even worth worrying about? I haven't gotten anywhere close to animations and sound, and I have a feeling doing that correctly is far more important than this but I just don't know enough about it to be sure.

What im really worried about is making something, getting really far in and having to backtrack to optimize because i didn't do it before.

 

[obscene]

None of this is worth worrying about. Variables don't affect performance.

I will say though that the keyboard events are useless if you plan on letting the players customize controls. Do it all yourself in code so it's flexible.

 

[squirrelah]

None of this is worth worrying about. Variables don't affect performance.

I will say though that the keyboard events are useless if you plan on letting the players customize controls. Do it all yourself in code so it's flexible.

Its an RTS so there will be a lot of hotkeys. I basically just finished the only customizable hotkey im going to have which is 1-9 for selecting units, and making the camera jump to those units if its double pressed.

 

[Pfap]

For most things you will be fine. I always think of this quote by Donald Knuth when anybody mentions optimizations.

The real problem is that programmers have spent far too much time worrying about efficiency in the wrong places and at the wrong times; premature optimization is the root of all evil (or at least most of it) in programming.

There are quite a few interesting ones on this list at least to me...
https://en.wikiquote.org/wiki/Donald_Knuth


I think after awhile of working with Gamemaker you just get a "sense" about what to use where and what will happen. So, to sum up you are probably fine; but, I would still recommend trying to fully grasp the way the different variables are used.
I guess a way to think of var variables would be a note that you only need for a limited amount of time. They're quick like jotting down a number your Dad gave you to call the mechanic, something that will end up in the garbage the next day.
Global variables are more like community variables like the pool in a hotel everybody who rents a room can have access to it, but it takes up more room then a shower which is something in every single hotel room.
The shower could be thought of as a regular instance variable.

A good way to pick a variable is to ask yourself who is going to need access to it and for how long?
Although, there is more to it... a good term to google is "variable scope" or "variable scope in gamemaker".


Personally, I think too many global variables can make code hard to read and if it does not need to be global it shouldn't be.

 

[Lonewolff]

This is about the only one that consistently goes in to my projects. Gives an instance performance boost.

application_surface_enable(false);

Other than that, just address the bottlenecks as you come to them. Over time experience will tell you what is going to cause a performance hit or not.

 

[Cameron]

When it comes to optimization, your main focus should always be on draw code. Draw functions are what uses up the most processing. Mastering surfaces is one of the biggest keys to optimizing your draw code. As your project grows more complex and you have more draw functions going on every step you can look in the profiler on the debugger and see what object.events are the most expensive and optimize them.
The stuff you are currently worried about, what your post mentions above, are considered micro-optimizations and will have little to no effect on actual performance.
I wouldn't worry about it though, you can get far in to a project and optimize, it's not "backtracking" as much as refining.
My advice is to work on a project for a little while and then do some optimization to it so you can get a better understanding of what the process entails. Mainly, when that time comes, you will want to use the debugger, look at the profiler, and then look at the most expensive processes and work on that code.

 

[Lonewolff]

^^ Pretty much that.

Worry about making an actual game first and then refactor bottlenecks as they come.

 

[RefresherTowel]

Alternatively, I could just have that code run in the "key pressed letters "w"" page, and not have it run every step.

But it -does- run every step (or at least, kinda). If you have a keyboard event, that keyboard event is checking to see if a key is pressed, and if it is, it runs it's code. If you're checking for a variable in the step event, you're checking if a key has been pressed, and if it is, it runs the code in your if statement. They are both doing basically the same thing. There's only one extra layer of abstraction if you use the step event (which is actually setting the variable to the keyboard_check function). Of course, GM optimises some things under the hood and I assume that the optimisation is slightly better for a keyboard event than a step event you are controlling yourself. However, computers can do billions of operations per second, so this is not a cause for worry. As obscene pointed out, the real strength in using the step event rather than the keyboard events is that you can reassign what key is being checked for, allowing players to customise their controls.

 

[nacho_chicken]

When it comes to optimization, your main focus should always be on draw code. Draw functions are what uses up the most processing. Mastering surfaces is one of the biggest keys to optimizing your draw code. As your project grows more complex and you have more draw functions going on every step you can look in the profiler on the debugger and see what object.events are the most expensive and optimize them.

I want to bring special attention to this specific point and reiterate: Drawing events are going to be 90-95% of your code overhead. That is such a large difference that it rarely becomes worth it to optimize step events. As an example: Some parts of my game was running significantly slower than the rest. I open the debugger and check it. 95% going to obj_main's draw event. Clean the draw code up a bit. Went from 250 fps to 3500 fps. The biggest issue with that is nobody will ever notice it. I only did it for fun. Maybe 0.1% of the people who play my game will even have a monitor that displays at 240Hz. As long as your game doesn't drop below 60fps, it's borderline useless to optimize. Nobody will complain unless your game is actively dropping frames.

Maybe with an RTS drawing will take a backseat to the step event, especially with pathfinding. You'll only need to worry about it when you get there. A complete game is better than an optimized but unfinished one.

 

[Lonewolff]

Went from 250 fps to 3500 fps. The biggest issue with that is nobody will ever notice it.

Someone who owns an older rig that is 10% of the speed of yours will notice it. That's 25 FPS back up to 350 FPS.

The biggest issue with that is nobody will ever notice it.

That's the thing. If people don't notice it, it is a job well done.