GameMaker Order of instances in layer changing when I leave a room and come back???

[OblivionSkull21]

The room in question is persistent because I want changes in that room to stay throughout the game. In this room, I have one layer that contains nothing but tree instances. I laid down all the tree instances in a very specific order (so that tree trunks weren't sitting on top of tree leaves). All the trees have the same depth.

When I first load the game, everything is fine. The trees appear in the correct order and there aren't any depth problems.

However, as soon as I leave the room and come back, in a few spots the trees are not in the correct order. Why is it doing this? Is it a bug? How can I fix it, other than to manually input the depths for each instance's creation code (Ex. depth = inst_ABCDEFG - 1)

NOTE: This problem doesn't happen if the room is non-persistent, but, again, it needs to be persistent.

EDIT: Read through the manual and found that the layer properties has nothing to do with instance order, and that I should instead look at the instance creation order window. I rearranged the order in THAT window to match what I had in my layer properties window, but the bug is still happening??

EDIT 2: Here's a comparison of the issue.

Correct order of trees:

Incorrect order of trees:

 

[IndianaBones]

Technically its not a bug, there is no guaranteed draw order for instances on the same layer.

It would be nice if there was something like a Draw Order value that could be set to control this.

Although the instances flipping their draw order because of room persistence is something I remember being discussed a long time ago when GMS 2 first came out.

Here is one of the threads discussing it, confirms that draw order is not guaranteed:

https://forum.yoyogames.com/index.p...ng-drawn-properly-2-0-5-72.20584/#post-129927

Draw order within any given layer is NOT guaranteed... If you need something drawn in a specific order, either make it on a different depth or draw it yourself from a controller object in the order you require.

 

[OblivionSkull21]

Technically its not a bug, there is no guaranteed draw order for instances on the same layer.

It would be nice if there was something like a Draw Order value that could be set to control this.

Although the instances flipping their draw order because of room persistence is something I remember being discussed a long time ago when GMS 2 first came out.

Here is one of the threads discussing it, confirms that draw order is not guaranteed:

https://forum.yoyogames.com/index.p...ng-drawn-properly-2-0-5-72.20584/#post-129927

Wow, okay, I understand now. Yes, there should be a way to control the draw order on the same layer. There's an instance creation order, but yet it doesn't control the draw or depth order which seems counter-intuitive??? After reading through the thread, it seems yoyo just wants us to use a controller object to draw all our instances in the correct order (not happening, have way too many instances to do all that), or to put each instance on a different layer (again, not happening... I have 20+ trees... that's a lot of layers)

Regardless, that is definitely a tool they should have implemented back in 2017...

 

[IndianaBones]

Wow, okay, I understand now. Yes, there should be a way to control the draw order on the same layer. There's an instance creation order, but yet it doesn't control the draw or depth order which seems counter-intuitive??? After reading through the thread, it seems yoyo just wants us to use a controller object to draw all our instances in the correct order (not happening, have way too many instances to do all that), or to put each instance on a different layer (again, not happening... I have 20+ trees... that's a lot of layers)

Regardless, that is definitely a tool they should have implemented back in 2017...

Yeah, thinking about it, I seem to remember a bug with persistent rooms that would flip the draw order when you go back into the room. It was a while ago, I don't recall if there was ever a bug logged for it. I tried searching the bug database for something similar but couldn't find anything. Doesn't mean its not there though.

It might be worth it to log it as a bug in my opinion - when you restart the game, the order is preserved, so why is the order not preserved when you go back to a persistent room. I would hope that even though the draw order is not guaranteed, at the very least it would be stable when going from room to room.

At least if you log a bug, you will hopefully get an official reply from Yoyo.

I know in my own level editor, where I'm drawing the instances manually based on a custom depth variable, I came across the same situation. I needed some instances to be on the same layer, but to be drawn in a fixed order, so I implemented a draw order variable for instances that are at the same custom depth. It is something that is also present in other engines that I've looked at as well.

 

[TheouAegis]

Do the instance's ids stay the same after leaving the room and then going back? I would check it for myself, but I have too much stuff already running on my computer right now. Just wondering if perhaps when you leave the room GM writes instance "states" to a buffer and then when you go back to the room it recreates them from the buffer? And in that case, perhaps it's altering the read/write order, causing the issue? Do the sprites draw in the same messed up order every time, or does the order change with each time you go back into the room?

 

[OblivionSkull21]

Do the instance's ids stay the same after leaving the room and then going back? I would check it for myself, but I have too much stuff already running on my computer right now. Just wondering if perhaps when you leave the room GM writes instance "states" to a buffer and then when you go back to the room it recreates them from the buffer? And in that case, perhaps it's altering the read/write order, causing the issue? Do the sprites draw in the same messed up order every time, or does the order change with each time you go back into the room?

From what I found, the id's aren't changing, and the sprites always draw in the same messed up order, they don't change.

I did notice that the order of the instances in the layer properties itself does reflect what happens the first time a room starts. If I purposefully put an instance out of place in the order, it appears like that but fixes itself once the player reenters the room. Like wise, if I put it in the correct order it appears right and then becomes wrong upon return. It does seem like GM is reversing the order.

I went ahead and filed a request to have some kind of draw order tool be implemented in a future update. Keep your fingers crossed.

 

[spoonsinbunnies]

im not sure how complicated your forrest is currently but this seems like something easily fixed with something like
create

if y>room_height*.5
depth=0
depth=round((room_height*.5-y)/room_height*32)

or something in create, this will naturally put trees further up the screen in back. tweak the 32 as needed its just an arbitrary geuss, and if trees are further down than the middle of the screen just remove the *.5 part. What im doing is finding a ratio for middle of the screen to equal 0 and 0y to equal 32 depth wise.
In the really og days of gamemaker depth was usually just -y but newer versions have a max limit. Hope this helps.

 

[OblivionSkull21]

Little update: A ticket has been submitted for the issue and they are checking it out. I made a separate example project demonstrating the issue and upon closer examination I can confirm the draw order is being reversed.

Theoretically, we have a draw order that is 1, 2, 3, 4, 5. If we leave and return to the persistent room, it becomes 5, 4, 3, 2, 1.

Hopefully they can fix this

 

[TheouAegis]

put each instance on a different layer (again, not happening... I have 20+ trees... that's a lot of layers)

Just jumping back in because this statement bugged me when I first read it.

You don't need a new layer for every tree, you need a new layer for every depth and to break the trees up into multiple pieces. That's a minimum of 2 layers. One layer would be for the base of the trees and another layer for the tops of trees. And if you had 3 degrees of height, you'd add yet another layer if there's a risk of two sprites on the "top" layer overlapping.

Although for some people, implementing your own PPU might be easier.

 

[OblivionSkull21]

Just jumping back in because this statement bugged me when I first read it.

You don't need a new layer for every tree, you need a new layer for every depth and to break the trees up into multiple pieces. That's a minimum of 2 layers. One layer would be for the base of the trees and another layer for the tops of trees. And if you had 3 degrees of height, you'd add yet another layer if there's a risk of two sprites on the "top" layer overlapping.

Although for some people, implementing your own PPU might be easier.

That method could work, though it’s still a little tedious. Ill wait to see if they fix the issue at all in an update first.

What’s a PPU?

 

[TheouAegis]

picture processing unit. LOL It's dedicated graphics hardware on some old consoles. You just dump a bunch of sprite and tile data into it and then it spits the data back out as graphics in whatever order you specified. So instead of letting GM handle all your graphics on its own, you'd have a graphics controller object into which you'd feed sprite and tile data and then it would draw everything during its Draw event. lol It's more work, but you'd have a lot more control.

 

[Kyrieru]

When I looked I ended up using this.
https://forum.yoyogames.com/index.p...-depth-sorting-system-replaces-depth-y.62705/

It sorts by Y, but you can modify it to take X or a manual depth value into account.
You have to have a draw object that draws everything.

Honestly you may have to do something like this eventually anyway since draw order becomes really tedious once you start working with effects and stuff.
With this, you can group things by type and make sure they always draw in the right order.

 

[OblivionSkull21]

Got a few final words from yoyo on the issue:

"As you said, we do not guarantee the draw order of instances. This is due to the nature of batching graphics for rendering. This is not something we are likely to be able to change without causing inefficiencies and slow down."

This really sucks, and I understand that the draw order is not guaranteed, but yet every time I launch the game it produces the same outcome... the instances are drawn in reverse upon returning to the room. If the draw order wasn't guaranteed, then wouldn't the instances be drawn completely random each time?

I've been looking all over the place about how GameMaker handles/maintains persistent rooms and how it reads the texture pages upon returning to persistent rooms to see if I could figure out some fix, but I haven't found anything...

 

[Nocturne]

This really sucks, and I understand that the draw order is not guaranteed, but yet every time I launch the game it produces the same outcome... the instances are drawn in reverse upon returning to the room. If the draw order wasn't guaranteed, then wouldn't the instances be drawn completely random each time?

No. When they say it's not guaranteed, what they mean is that at any moment a change to the render pipeline could change the order in which things are drawn, AND that on different platforms (and even computers/devices within the same platform) draw order may also differ (not to mention the situation you describe between going from one room to another). Basically, while it may LOOK like consistent behaviour now, that doesn't mean it will stay consistent. Draw order is undocumented behaviour, and so anything that you do that utilises the current behaviour may be changed without notice... hence "not guaranteed". This is why we have explicit draw/begin/end/pre/post events, explicit layers, and explicit depth values, so you don't have to reply on any implicit behaviour.