Deactivating instances outside of view

E

elsi11

Guest
First off, someone said somewhere that gamemaker now does this automatically to some extent. Is that true?

Secondly, should I use this:
Example:

instance_activate_all();
instance_deactivate_region(view_xview[0] - 64, view_yview - 64, view_wview[0] + 128, view_hview + 128, false, false);
The above code activates all instances within the room and then deactivates those that are outside of the limits of the current view.
And a bonus problem with this, I read, is that if you use static objects like walls, IF you don't reactivate the walls first in a longer range, and then reactivate enemies, in a shorter range, the enemies might get stuck in walls because they could spawn on the enemies.

How do you pro guys handle this common problem?

Are there some things like this in gamemaker 2, that studio 1.4 doesnt have?

Thank you !!!
 

Tommah

Member
yes that is the common solution, I don't THINK gamemaker does this automatically because I never heard of it.

however for walls and such I would simply just activate all walls since they don'thave any code inside them and don't slow your game:

Code:
instance_activate_all();
instance_deactivate_region(view_xview[0] - 64, view_yview - 64, view_wview[0] + 128, view_hview + 128, false, false); //deactiveate all outside view with a 64 border
instance_activate_object(obj_wall); //reactivates walls
 
T

TonyCold

Guest
P.S: I am not Pro.
Anyways. I basically do the same with my game. I simply use the Event - Other - Out of view - The put the Code:
Code:
instance_deactivate_all(true or false(Depends on you))
. Another method is to set a variable(outofview) for objects such as enemies which returns either "0(false)/1(true)" under the event (Other - out of view)
and Put
Code:
if (outofview = 1){
  instance_deactivate_all(Your Decision)
} else {
  instance_activate_all()
}
About walls Just let them Always Activated.
 

RangerX

Member
GMS doesn't do this automatically I can confirm it to you.
And if you don't want your activation system to take a toll on your game running, do like TonyCold up here.

- Let each object deactivate itself in an Outside View event or with a code in Step event considering buffer space, depending the game's needs.
- Have your player or object that the cam follow activate a region every few steps that correspond to the view size (or a bit larger depending the game's needs)

If you do like in your opening post you will affect performance much as soon as your game will become a tad bigger.
 

Yal

🐧 *penguin noises*
GMC Elder
I'm (debatably) pro and have been using the deactivation system for years, so here's some ideas:
  • It's the most efficient to use an alarm in a control object to handle all deactivations every 10 steps or so. Alarm delays and region sizes should be adjusted based on the speed stuff moves in your game, but I find 10 steps alarm time and view size + a handful of "object blocks" region size works pretty well for the kind of games I make.
  • Have a greater border for terrain than for 'anything else' to avoid issues with stuff getting stuck in terrain when it pops in. Faster alarm time means less demands on the border size and vice versa, but keep in mind that there's overhead involved in the activation functions (they have to loop through ALL objects, including inactive ones) so ideally you shouldn't do it every step.
  • Instance deactivation is based on the collision mask of instances from what I can tell, so you don't need to compensate for big objects.
  • My usual deactivation routine is this:
    • Deactivate everything
    • Activate terrain
    • Deactivate terrain outside the "terrain graze border" region
    • Activate all objects inside the "objects graze border" region (which, as mentioned before, is smaller than the terrain graze region)
    • Activate "parent_active", a special object that stuff that must always be active inherits from. For instance, controllers should inherit from this, and generally it's useful if the player object and such does too. Having an active-parent simplifies a LOT of things.
  • Take advantage of the fact that deactivated objects "don't exist" - enemies that chase you down won't start moving until they're activated, so they stay at their starting point until you're nearby with no extra programming effort.
  • Keep in mind that stuff might "stop existing" if it gets deactivated, and that might mess with your game logic. Make sure control objects don't get deactivated, and be careful about counting the number of active instances for things like 'are all enemies dead?' checks.
 
>>>Deactivate terrain outside the "terrain graze border" region

Ноw one can do it? Is it something custom code smth about ~
with (objTetrain)
 

Yal

🐧 *penguin noises*
GMC Elder
>>>Deactivate terrain outside the "terrain graze border" region

Ноw one can do it? Is it something custom code smth about ~
with (objTetrain)
instance_deactivate_region() with outside set to true. Deactivates EVERYTHING, but if you do things in the right order only terrain will be active at that point, so you get the same effect.
 
D

DKR_87

Guest
Not to hijack a thread, but it's certainly not worth starting a whole new one.

Is deactivating instances say, outside view, a common way of managing frame rate and performance? Is that why people do it? I've never thought about it, to be honest.

Thanks!
 

Simon Gust

Member
Not to hijack a thread, but it's certainly not worth starting a whole new one.

Is deactivating instances say, outside view, a common way of managing frame rate and performance? Is that why people do it? I've never thought about it, to be honest.

Thanks!
A deactivated instance will not run any of their code (of couse), even if they have no code in them, say collision object, they take a lot of processing just to exist.
Another thing is the instance loop. Doing collision checking like place_meeting loops through EVERY instance to find the right one. Deactivated instances are excluded from that loop, making the global collision checks faster.
And of course drawing, which is also an instance loop. every instance of an object will be drawn no matter if it is inside the view or not, deactivated instances are excluded from that loop too.
Same goes if you make your own instance loop using the with() statement.
 
B

Blackened

Guest
It's the most efficient to use an alarm in a control object to handle all deactivation every 10 steps or so.
Hmmm... hadn't thought of that. I'll have to try this. Thanks.
 
Last edited by a moderator:

Yal

🐧 *penguin noises*
GMC Elder
Is deactivating instances say, outside view, a common way of managing frame rate and performance? Is that why people do it? I've never thought about it, to be honest.
It's a way of managing performance, not sure how common it is per se. I like it for its other side effects, though, like making faraway enemies not exist, so you don't need special-case code to stop enemies that chase you down from chasing you down before you get close, and stuff like that. Even though the deactivation loop is O(N), it runs less often than the normal step loop (and is compiled, while your step-event code etc is interpreted), so you get your game performance more or less constant no matter how big your rooms are if you use deactivation. That's also a good thing since it makes it easier to ensure consistent performance.
 
Hello people. I used all the indications made here but I also came across the problem of deactivating the floor and the enemies sinking into it. I solved it by making a code for every time they are sunk, go up until they leave and it worked.

//with enemies

if(place_meeting(x, y-10, obj_ground))
{
y-- ;
}
 

Fredrik

Member
From my experience its better on performance to first deactivate all, and then activate region instead of activating all and then deactivating region.

What Ive heard somewhere is not that GM deactivates instances outside the view, but that nothing is drawn outside of it.
 

Yal

🐧 *penguin noises*
GMC Elder
Hello people. I used all the indications made here but I also came across the problem of deactivating the floor and the enemies sinking into it. I solved it by making a code for every time they are sunk, go up until they leave and it worked.

//with enemies

if(place_meeting(x, y-10, obj_ground))
{
y-- ;
}
If you have two separate activations, one for terrain and one for everything else, you can avoid this happening in the first place: just make sure terrain has a larger active radius than anything else.
 
Top