• Hey Guest! Ever feel like entering a Game Jam, but the time limit is always too much pressure? We get it... You lead a hectic life and dedicating 3 whole days to make a game just doesn't work for you! So, why not enter the GMC SLOW JAM? Take your time! Kick back and make your game over 4 months! Interested? Then just click here!

SOLVED Sprite draw order depending on y variable?

N

Nebularts

Guest
Hello I'm doing a top down rpg and while the characters' collisions are 16x16, the sprites are 16x24
Basically this means that characters or objects should appear layered in front of the ones above and behind the ones below at all times, but I don't know how to do that because objects seem to be drawn acording to the creation order in the room

Is there a way to have the draw order depend on the x and y of the objects, so that when an objects moves down on the screen it will be drawn on top for example?

Thanks
 

obscene

Member
I would be curious if there is a comparison (or to run one myself) to see if all the grid sorting, reading and 'with...event_perform' calls would be faster if dealing with a lot of instances (and particle systems). My project runs like garbage as it is so a performance boost would be welcome, but I just can't see it.
 
Last edited:

obscene

Member
I've tested thoroughly. Tens of thousands of instances. GMS2 can easily handle depth=-y. The difference between drawing instances at a single depth vs a few thousand unique depths is tiny. Certainly tinier than sorting a ds_grid of ten thousand instances and manually drawing them. I don't get why there are so many discussions/videos on the subject of doing it differently than depth=-y. It's fine. It's easy. Do it.
 
N

Nebularts

Guest
Ok I used "depth = -(y/16)+100"

I divided the possible y output by 16 since my game works with tiles, and seems reasonable enough so that the depth numbers aren't too big.

This is the only thing that has done exactly what I need but I am not closing the case just yet, I'll take a look at it tomorrow
 
N

Nebularts

Guest
Update, the depth = -y indeed gives problems that aren't worth trying to solve. I went back to the other method, the one TsukaYuriko said.

Turns out I was forgetting to make all the children inherit the create event and now it works! Thank you.
 
Top