GMS 2 [SOLVED] Really Weird instance_deactivate Glitch

Anixias

Member
Hello there. I'm currently focusing on optimizing my game as much as possible before I begin adding multiplayer and other new content. In my terrain object, I am deactivating all par_doodad objects and reactivating a region around the view. Here is the hierarchy of obj_tree (like, all of it's parents to the top):
par_entity
par_doodad
par_collision
obj_tree

Here is the hierarchy of obj_player:
par_entity
par_living
par_good
obj_player

Notice, the only thing trees and players share in common is the highest parent "par_entity". The weird glitch is that I am deactivating all par_doodad objects outside of the view. This includes things like trees, bushes, etc. However, for some really odd reason, if the player walks upwards in ANY way (like at an angle >0 and <180), the player suddenly no longer calls their draw events, but still executes step events, user defined events, etc. but the deactivated trees run NO code and are not included in "with(obj_tree)" calls.

I've tried many things, even simplifying my movement code heavily, and using the debugger. The player is always visible (built-in variable visible = 1 always) even after suddenly not executing draw calls anymore. Also, I noticed the player no longer animates. I know this because I have a user defined event that draws a water reflection of the player and I can see it, but not the player himself. Also, footstep sounds (which are triggered in the step event, after movement) still play, but are suddenly really distorted.

Do you have any idea what might be happening? It also happens to animals and wildlife, if they walk upwards at an angle between 0 and 180 degrees, they stop natively executing draw events, and stop increasing image_index.
 

TheouAegis

Member
Well it isn't the deactivation script. You need to go through all of your objects and see what's going on between angle 0 and 180 in the code. I would guess it has something to do with the xscale or yscale getting set to 0.
 

Anixias

Member
It is definitely not image_xscale or yscale, because the water reflection is still visible. Nothing special happens in that angle range. This weird glitch does not occur if I disable the deactivation script. If I deactivate par_doodad, par_entity seems to be affected in this weird way. I mean the draw events literally cease to run, as in show_debug_message in a draw event no longer prints for whatever reason. It has everything to do with the deactivation script and is definitely not a scaling issue.
 
T

TimothyAllen

Guest
I would have guessed that your visible variable was set to false but you claim it is 1. Is it possible that it is 0 for part of the frame (before draw is called) but then 1 again afterwards? Also if you get really weird behavior, its always good to clean your build with the brush icon.
 

Anixias

Member
No, it is not the visible variable. Even pausing in debug mode, it is 1 always.

EDIT: Cleaning the build did nothing to resolve the issue...

PS, even if I deactivate obj_tree itself instead of a parent, or use with(obj_tree) deactivate(id), it has the same effect. Commenting out the deactivation code fixes the issue, but makes the game take a moderate performance hit.

EDIT:
I have discovered something.
  1. Running terrain generation as normal, which spawns trees, HAS the glitch.
  2. Running terrain generation without spawning trees does NOT have the glitch.
  3. Not running the terrain generation, and spawning 1 tree outside of the view does NOT have the glitch.
  4. Same as 3. but the tree inside the view still does NOT have the glitch.
  5. Spawning 1 tree in the terrain generation does NOT have the glitch.
  6. Spawning 10 trees in the terrain generation SOMETIMES HAS the glitch.
  7. Spawning 100 trees in the terrain generation HAS the glitch after a few seconds.
  8. Spawning 1000 trees in the terrain generation HAS the glitch after a few seconds.
So based on this test, it seems more instances of par_doodad = higher chance of glitch occurring.

I can post screenshots or a video/gif if needed.

EDIT:
This does not produce the glitch:
Code:
instance_deactivate_object(par_doodad);
instance_activate_all();
This DOES produce the glitch:
Code:
instance_deactivate_object(par_doodad);
instance_activate_region(view_xview()-PAD,view_yview()-PAD,view_xview()+view_wview()+PAD,view_yview()+view_hview()+PAD,true);
Even though the view is following the player, and the player and animals aren't even children of par_doodad! (Note: PAD is a macro defined as 64 for padding so larger doodads don't randomly appear/disappear at the edges of the screen.)
 
Last edited:
T

TimothyAllen

Guest
I suggest you look at instance_activate_region in the docs... you will see that your arguments are incorrect. Also If you are using GMS2, view_xview stuff is replace with camera_

EDIT: Just a hint.
instance_activate_region(left, top, WIDTH, HEIGHT, inside)
 

Anixias

Member
Notice my view_xview stuff is a custom script, not an array. I made it simply to avoid having to type the long camera functions.

Even if they are width and height, they should still not cause this weird effect on players and animals...
 
T

TimothyAllen

Guest
Notice my view_xview stuff is a custom script, not an array. I made it simply to avoid having to type the long camera functions.

Even if they are width and height, they should still not cause this weird effect on players and animals...
Well I suggest you fix that issue then go on from there.
 

Anixias

Member
Alright I updated the arguments to look like this:
Code:
instance_activate_region(view_xview()-PAD,view_yview()-PAD,view_wview()+2*PAD,view_hview()+2*PAD,true);
It still has the weird glitch.
Btw thank you for at least trying to help me!
 
T

TimothyAllen

Guest
Its definitely a weird issue. But really with the little info I have, I don't think I can help much more because I've never encountered this particular problem myself.
 

Anixias

Member
I honestly have no clue as to what is specifically causing the issue. I really don't know where to begin. It only occurs if the player or an animal walks upwards while par_doodad are being deactivated, which doesn't make any sense. Would providing the project files maybe help?
 
T

TimothyAllen

Guest
Maybe. Ill take a look and see if anything catches my attention
 
T

TimothyAllen

Guest
Well I at least found the source. I commented out the Pre-Draw in the par_entity "depth = -y" and the glitch doesn't happen. Its a very inefficient way (i think) to do it in GMS2 anyway. I would write a script that sorts and draws entities that are on the screen.

EDIT: Just an update. Setting depth = -y in END STEP. Somewhat fixes the issue (it will flicker instead). Its probably a bug with how GMS2 handles the underlying layers. As I stated, i would sort and draw manually.
 
Last edited by a moderator:

Anixias

Member
Whaaaat how did you figure that that was the issue? Thanks man! Now, should I create a renderer that simply has a priority of all par_entity instances using y as pri and just call event_perform for their draw events? Or is there a more efficient way?
 
T

TimothyAllen

Guest
I would use an array (or grid) that is the height of my view (ds_list in each entry). Have a controller loop through all the entities and add them to the array before drawing and clearing the lists as it draws them.

Edit: just remember to set all the entities visible to false so you aren't drawing twice.
 
Last edited by a moderator:

Anixias

Member
Okay, I made a renderer. I changed all par_entity draw events into User Defined 2, made par_entity's Draw Event simply a comment "/// @description BYPASS", and I used the system you described where I have an array the size of view's height (I padded +32), and simply add them to the correct list in the array based on floor(y-view_yview()). It works perfectly! Thank you so much.
 
Top