SOLVED Obey depth order from Draw Begin through Draw End?

CruelBus

Member
In my game, I have a player vehicle that has tread marks and a particle system assigned to it. When placing all world instances in the regular Draw event, the vehicle is responsible for 4 texture swaps and 4 batches, eventhough the vehicle, tread marks and particle sprite are all on the same texture page. When moving the vehicle to the Draw End event, the texture swaps and batches drop to where they "should be," but the vehicle and its associated tread marks draw on top of everything.

That was my attempt to force some kind of draw order, since everything else is behaving correctly.
Is there a way to carry the depth sorting (depth=-y in my case) from the Draw event to the Draw End event or are these events unique to themselves with everything in the Draw event being drawn on top of everything in the Draw Begin event?

ANSWER: Each draw event (Draw Begin, Draw, Draw End) is handled as its own complete "draw." The result is that everything drawn in the Draw Begin event will be on the bottom. everything in the Draw event will be on top of everything in the Draw Begin event, and finally, everything in the Draw End event will be on top of everything in the first two draw events.

Additional info:
The player vehicle's depth uses the depth=-y method, as does every object in the game except for the terrain and tread marks which have fixed depths.
Moving the tread marks to a different texture page would be counterproductive, since each player vehicle has its own dedicated page in order to minimize texture swaps.
The method I am using for the tread marks is to create an array of 60 instances that cycle in a loop as needed and are drawn with the appropriate image_index, x, y, rotation, color and alpha, (all passed from the vehicle object) and are always drawn at the same depth in world.
 
Last edited:

CruelBus

Member
@curato Well, I can't determine when the treads are being drawn as it is right now. When the vehicle is created, its create event creates an array of 60 tread instances that each have their own draw event.

Also, the tread marks are at a fixed depth of 10, whereas the vehicle is at a depth of -y.
 

Rob

Member
Anything you put in the draw_end event will be drawn over anything in the draw/draw begin regardless of depth.

I don't think depth =-y is supposed to be used in GMS2 because of the new layer system. Exactly why not I don't know (eg what problems does it cause?) !

You could use a single object to draw everything, using the y value as the priority, and adding things within the view to a priority queue to then be drawn by a single object. You can guarantee a draw order that way. If you have hundreds/thousands of instances on screen it's not a good way to go about it though.
 

CruelBus

Member
@Rob Hmmm. Is there a way in code to set up the room instance order? Is the order in which instances are created the same order in which they will be processed for drawing? If not, would my draw controller call the draw event of each instance/object? That sounds super messy.

What is the alternative to depth=-y? Constantly call layer_add_instance and have, in my case, 10,000 layer ids in an array?

Right now, I am exclusively using instance_create_depth for everything. Do you think using instance_create_layer for fixed items would be better and maybe help the compiler figure out the best order to draw things in?
 
Last edited:

Rob

Member
You'd do it like this:


You have a priority queue, add any instances within the view to it using their y as priority, and then draw that every step. It could be optimized a lot but the basic version is there.
 

CruelBus

Member
I watched the video and am not sure if I could get that to work with a system that has multiple texture pages without having more swaps than I do right now.
 

Rob

Member
I watched the video and am not sure if I could get that to work with a system that has multiple texture pages without having more swaps than I do right now.
I have to confess I am a noob when it comes to texture page swapping. I've never had to deal with that particular issue. I'm sure somebody else will have some helpful insight though!
 

CruelBus

Member
@Rob Thank you for your help. I might be able to embed the 60 treadmark items within the vehcile instance, and just have it draw the treads... nope, nevermind, they will always be on a different layer than the vehicle is on.
 

CruelBus

Member
What about just making the vehicle draw all the treads, and then draw itself?
The problem with that method is that the tread marks need to be behind some landscape elements, but on top of others, while under everything else. Without divulging too much about the game, there is a surface that the player can be on, and a cliff. The tread marks should draw on the surface, but when the vehicle hangs over the cliff, it should not draw the tread marks on the cliff face. I have a landscape layer system in place that allows for this that sets the treadmarks on top of the surface, but under the cliff face, with the cliff face on top of the surface. Migrating from GMS1.4x to GMS 2.3x has caused this method to perform worse. By worse, I mean that instead of 7 swaps and 10 batches, I am getting 10 swaps and 14 batches, and still running well over 60fps in the background, but only around 200-300 on a Galaxy Note 8. The game will also be getting a lot more intense, processing wise, so recovering the 3 swaps and batches (a 30% improvement) should give me enough comfortable growing room to get just about as crazy as I want and it still perform on some slightly older mobile devices.
 
Last edited:
Top