GameMaker Is deactivating worth it?

[Turbulence421]

Hello,

I'm have a platformer game in GMS2 that currently deactivates instances outside the view every couple steps in order to help with processing power. However, I have heard that deactivating instances doesn't always help and it might wind up slowing the game even more if you have a lot of instances turning on and off.

I have been wondering if it is time to switch to a different system that manually shuts off certain things when they are outside the view. Would it be easier on the CPU to activate and deactivate a bunch of instances according to the view, or to have a bunch of instances always activated but not running their code when they are off view? Is there a general consensus about which method is best? (Some of these instances also have collision events in the object event list, which may factor into the decision)

Thanks!

 

[Nocturne]

I'm have a platformer game in GMS2 that currently deactivates instances outside the view every couple steps in order to help with processing power. However, I have heard that deactivating instances doesn't always help and it might wind up slowing the game even more if you have a lot of instances turning on and off.

Have you tested this? Make a "stress test" room, with what you think will be the maximum number of instances a level could have at any one time and then run the game in debug mode with deactivation on and deactivation off and then compare the FPS from the debug graph. In general (and in my experience) deactivation does help, but it's only really useful when there are a large number of instances in the room and the room is pretty large.

 

[TheouAegis]

Deactivating helps in a couple of ways. First off, pretty much all of the automatic functions in Game Maker will cease to operate on deactivated instances, thus a deactivated instance is paused in the strictest sense of the word. In terms of performance, this can be a substantial gain if the deactivated instance has a lot events, especially alarms. In the movement handling stage, GM will skip right over the instance instead of attempting to move it; for a handful of instances, this is a negligible gain, but for lots of instances it can add up. In the draw phase, GM won't need to verify if the instance is inside the view at all, so you'll get a boost in performance during the draw event. Collision checks won't occur against a deactivated instance, nor will any code that explicitly requires an instance's presence, such as with, place_meeting, instance_find, as well as indirect object referencing like obj_enemy.x; if your code relies heavily on these functions or if you have a with() call followed by a large, complex block of code, then deactivating would help your performance potentially drastically.

However, that final point is also a counter-argument to deactivating, at least in special cases. Since you cannot use a universal reference such as with(obj_enemy) x++ or obj_enemy.x++ on deactivated instances, this could potentially inhibit certain features in your program you might want. For example, what if you had a code that moves everything in the room right 1 pixel at a time? Those codes wouldn't work with deactivated instances, so then you'd have to activate all instance in the room first, run the movement code, then deactivate them again. You're probably not gaining any benefit in that situation. You could alleviate this by having a list of every deactivated instance's id, then looping through the list when you want to move all instances via (deactivated[|i]).x++; but if your room will have a lot of deactivated instances, that's a lot of memory allocated to just keeping track of deactivated instances.