Debugger: call count and Ms in profiling

Hi everyone.

Today i've been trying to tackle an issue I have with my project: lag.
At first I thought it was my surfaces, which in some way: yes, absolutely. For
some reason when I minimize the game, a lag spike appears, and endures after i maximize.
I'm still trying to resolve that.

However, I came across something very interesting that I didn't know was possible to track in the debugger.
You see, when I have a large amount of objects and I minimize the game, the lag becomes really bad. It is a combination of amount of objects and something with surfaces...

But that's not the topic of this post. I delved deeper and noticed something very interesting, so time to learn what this means:
What I want to ask about is the debugger. When i profile my current room, I can
see a list of objects, variables,... with next to them:
a) call count
b) time (Ms)
c) step%

My question is: how do I interpret these? What's the difference between "average" and "total"?

The object I want to duplicate a lot clearly shows some concerning numbers, both for its step AND draw event:
call count: 800 (800 objects)
time: 3.3 Ms (game should run at 60 fps but now it's around 30)
step%: 22.2%

Still having trouble trying to interpret these, but I have some other complicated objects that don't nearly get those values.
If this is the root of my lag problems, I'm going to have to figure out how to run the code just once in a controller object, and then somehow execute that ONCE per frame at each x and y position of my large amount of instances.
Which is uh, a problem, as i need to draw things with a depth, depending on an instance's position.

As far as I'm aware of, there is no function like draw_at_depth or something. And that's not even mentioning the step event...
 
Last edited:

Simon Gust

Member
One thing I can tell you is that ms can directly impact fps. Switch to profiling (I don't know how, don't use GM:S 2)
Tick Average Values:
if you divide 1000 (milliseconds) by 60 (fps) you get 16.6667. this is how much ms your game can afford before dropping below 60.
upload_2019-11-29_22-10-48.png
Of course this is just the game objects and it's events.
To view your whole game and engine you must change the View target to "Both" you can also see some engine times.

If you say your game is about 3.3 ms then it definetly must be in the engine step.
 
One thing I can tell you is that ms can directly impact fps. Switch to profiling (I don't know how, don't use GM:S 2)
Tick Average Values:
if you divide 1000 (milliseconds) by 60 (fps) you get 16.6667. this is how much ms your game can afford before dropping below 60.
View attachment 27856
Of course this is just the game objects and it's events.
To view your whole game and engine you must change the View target to "Both" you can also see some engine times.

If you say your game is about 3.3 ms then it definetly must be in the engine step.
No not my game, just one object, of which there are hundreds.
 
One thing I can tell you is that ms can directly impact fps. Switch to profiling (I don't know how, don't use GM:S 2)
Tick Average Values:
if you divide 1000 (milliseconds) by 60 (fps) you get 16.6667. this is how much ms your game can afford before dropping below 60.
View attachment 27856
Of course this is just the game objects and it's events.
To view your whole game and engine you must change the View target to "Both" you can also see some engine times.

If you say your game is about 3.3 ms then it definetly must be in the engine step.
I also would like to add: thanks soooo much for this explanation. I feel like this debugger, thanks to profiling, opens up a whole new world to me when it comes to tracking down causes of lag and other issues!
 
Top