• Hello [name]! Thanks for joining the GMC. Before making any posts in the Tech Support forum, can we suggest you read the forum rules? These are simple guidelines that we ask you to follow so that you can get the best help possible for your issue.

Discussion Built-In Z-Buffer Depth-Sorting In GameMaker Studio 2?

matharoo

Tutorial Guy
YYG Staff
Since depth = -y is somewhat obsolete now, do you think whether it's a good idea for YYG to make a built-in z-testing-based depth system?

For example: the one Ariak made on the YYG blog. It is a great technique, and works well, but it has its limitations, like not being able to use image_alpha and the sprite height being limited to 255. If GameMaker had a similar & built-in method for depth sorting that just worked, it would be really great.

So, my question is: is this something you'd want? Or is it just better to make your own depth system?

While the depth systems made using priority lists / DS lists / DS grids are fine, it's just better if it is controlled by the actual z-buffer. While building your own shader-based depth system is a viable option, it is much better if it is implemented into GameMaker so that it is easy to set up, even for beginners. It sounds like something essential (and primitive, from a user's perspective) that GMS2 should have, but all we can do is perform different sorts of "hacks" to make the depth work.
 

GMWolf

aka fel666
For example: the one Ariak made on the YYG blog. It is a great technique, and works well, but it has its limitations, like not being able to use image_alpha and the sprite height being limited to 255. If GameMaker had a similar & built-in method for depth sorting that just worked, it would be really great.
Use Z tilting, but dont use the alpha technique.

Just Vertex buffers.
YOU CAN ANIMATE AND MOVE VERTEX BUFFERS (sorta)!
move your vertex buffers by applying the matrix you need.
Animate them by using multiple VBs, one per frame.
Alternatively, you can ensure that your animations are packed as a strip, and give a texture coordinate offset to a shader, if multiple VB's scare you that much.
 

hippyman

Member
https://www.dropbox.com/s/ms3imvhmgxm3q78/DepthSorting.yyz?dl=0

This is how I handle doing depth sorting. It's obviously more code than just "depth = -y" but it's not much more than that.

Basically you have a parent object with the depth sorting code. It uses the normal image angle, scale, blend and alpha with no issues or weird hacks. The only added variable is the z variable since you can't just use depth without GM doing it's own thing behind the scenes.
 

GMWolf

aka fel666
https://www.dropbox.com/s/ms3imvhmgxm3q78/DepthSorting.yyz?dl=0

This is how I handle doing depth sorting. It's obviously more code than just "depth = -y" but it's not much more than that.

Basically you have a parent object with the depth sorting code. It uses the normal image angle, scale, blend and alpha with no issues or weird hacks. The only added variable is the z variable since you can't just use depth without GM doing it's own thing behind the scenes.
but does it handle objects that span multiple depths?
For instance, you may have two rocks, both at the same depth.
A tree grows behind the lower rock, so the trunk must appear below it.
However, the top of the tree must appear ABOVE the other rock.
rocks and trees.png
 

hippyman

Member
but does it handle objects that span multiple depths?
For instance, you may have two rocks, both at the same depth.
A tree grows behind the lower rock, so the trunk must appear below it.
However, the top of the tree must appear ABOVE the other rock.
This will work exactly how the old depth system worked. So if two rocks have the same depth, they'll draw in the same spot with the last one drawn on top I believe. I haven't done a ton of testing personally.

I think I have an idea on what you mean but could you make a quick crude visual aid to better explain what you mean?

Basically with this, it draws from the lowest z value to the highest z value.


After seeing the image.

Why would you make the rocks have the same depth? The whole purpose of this is to mimic the old "depth = -y" solution which won't have that problem because the rocks with different y positions will have different depths.

UPDATE: I did just do some testing and found an issue with this solution and I'm not sure the cause of it.

https://www.dropbox.com/s/ms3imvhmgxm3q78/DepthSorting.yyz?dl=0

Not sure if the old link works so here is the updated example. If you get in between the tree and the wall there's a weird alpha issue where the transparent parts of the player sprite are cutting through the tree and I have no idea why.


I also just read that blog post and I get what you're saying now.
 
Last edited:

GMWolf

aka fel666
Why would you make the rocks have the same depth? The whole purpose of this is to mimic the old "depth = -y" solution which won't have that problem because the rocks with different y positions will have different depths.
yeah, I was reading the z tilting example so much I got stuck in the wrong frame of mind.

I usually just dpeth sort my stuff, or use depth testing too.
But for some reason, after reading the z tilting thing I completely blanked and forgot that the rocks should be depthed based on height too.
 

csanyk

Member
I developed this in 1.4, but intend to port it to 2.x at some point, once I have a better understanding of how to work with Layers. I still do 99% of my GMS dev in 1.4, because it's what I'm familiar with.

I have imported it into GMS2, and it works, although whether it's optimal or not, I wouldn't say -- probably not, yet.

https://marketplace.yoyogames.com/assets/5932/z3d-engine
 

GMWolf

aka fel666
Another option is just to work in 3D, with an isometric projection and billboards.
save yourself a lot of work that way.
 

Nocturne

Friendly Tyrant
Forum Staff
Admin
Moderator
Depending on the type of game, you could also just use the layer system... For example, with my game skein which is on a grid, when I was testing porting it to GMS2, I simply made a new layer for every 8 pixels in height - so (room_height div 8) layers - then assigned their ID's to an array. Then when moving an instance it was simply layer = array[y div 8] for setting the layer/depth. This was really fast and simple to set up, although it's only applicable to specific types of game... (I use 8 because the grid was 8x8 pixels, but for any other size grid it'll work the same)
 

hippyman

Member
Depending on the type of game, you could also just use the layer system... For example, with my game skein which is on a grid, when I was testing porting it to GMS2, I simply made a new layer for every 8 pixels in height - so (room_height div 8) layers - then assigned their ID's to an array. Then when moving an instance it was simply layer = array[y div 8] for setting the layer/depth. This was really fast and simple to set up, although it's only applicable to specific types of game... (I use 8 because the grid was 8x8 pixels, but for any other size grid it'll work the same)
This is honestly probably the simplest and most efficient way of doing this and actually utilizing what the engine has to offer.
 

JeffJ

Member
Okay, I would like to clarify something that I'm still not 100% sure on.

Is the good old "depth-y" slower in GMS2 due to the new layer system, or is it the same as in GMS1?

Because if it's the same, then what's the problem?

And if it isn't, then can someone explain why a decision was made to make a specific type of game really hard to make efficiently, and what was gained in return?

This is actually important to me because, although my current project is sideview, I plan on doing a typical Zelda-esque view for my next project.
 

matharoo

Tutorial Guy
YYG Staff
Is the good old "depth-y" slower in GMS2 due to the new layer system, or is it the same as in GMS1?
It's not as efficient. Since GMS2 works with layers, each depth value creates a new layer. This messes up the layer sorting done in the room. I don't think it's that slow though - it works well too.
 

Nocturne

Friendly Tyrant
Forum Staff
Admin
Moderator
Is the good old "depth-y" slower in GMS2 due to the new layer system, or is it the same as in GMS1?
I haven't done any benchmarking, BUT on a straight import of Skein into GMS2 I get pretty much the same FPS when running it as I do with GMS1.4. And this is using depth = -bboxbottom and all the compatibility scripts and stuff. So, no, I don't think that it affects performance too much.
 

Miradur

Member
That's exactly what I don't understand. GM organises the layers internally via lists or similar and the tiles
must also be organised in a similar way.
Then why can't you access the type of display with the corresponding commands?
No question, of course you can program anything, but the task of a good game engine, in my opinion,
is the implementation of difficult topics, with simple commands.
Let us hope that this will be taken into account in future updates (keyword: tile collision, depth sorting, etc.).

Miradur
 

JeffJ

Member
I haven't done any benchmarking, BUT on a straight import of Skein into GMS2 I get pretty much the same FPS when running it as I do with GMS1.4. And this is using depth = -bboxbottom and all the compatibility scripts and stuff. So, no, I don't think that it affects performance too much.
So am I understanding you correctly that it is at about the same level of (in)efficiency as it was doing the same thing in GMS1?

If that's the case, then that sounds really good. But then why all this talk of doing it in literally any other way?

I'm really just trying to get a good understanding of the differences on how you would handle such a perspective in GMS1 and GMS2 - if any - and the reasons for it. If one is significantly slower than the other due to the internal changes etc.. As this is a rather fundamental thing that I feel is quite important to have a thorough understanding of in advance.
 

Nocturne

Friendly Tyrant
Forum Staff
Admin
Moderator
If that's the case, then that sounds really good. But then why all this talk of doing it in literally any other way?
Okay, well, it's about using the new features and having a clearer design in the game code... GMS creates a "managed layer" when you set the depth manually, and you can't access this layer nor use it in any other way. If you have a LOT of instances doing this at once, then I imagine that this WILL impact on performance, and it's also not the way the new system is designed to be used. The main reason for using another method is simply to have complete control over the rendering and not depend on the (opaque) internal workings of the engine. If I get some time later I think I'll benchmark this actually and see just how much (if any) difference there is performance-wise using depth...
 

Hyomoto

Member
I use a managed version and I agree with @Nocturne in that the new GMS2 engine is meant to give you more control over how things are handled internally. I'm not sure if I showed you the engine I'm working on, but that's sort of the backbone of it. The truth of it sort of ends up being that you can give someone tools, but they still need to know how to use them. It doesn't matter how good of an engine I make, or a solution Yoyo crafts, or anyone really, if you don't know what to do with it. The whole depth = -y thing was a hacky workaround for users who don't really understand the minutiae of rendering. Sure, it's easy but is it good?

I liken it a bit to something like draw_button, it's useful if you know absolutely nothing about coding but it's dead weight as soon as you have any understanding of how to draw sprites or even just shape primitives. I agree with members like @FrostyCat and @YellowAfterlife, what GMS2 should really focus on is letting people do more with the integrating assets into the IDE, and giving us tools to make more powerful assets, thus opening up the asset store for other users to create these exact solutions. It would be far more economical and useful to everyone than Yoyo trying to build a one-size-fits-all solution.
 

MarceloP

Member
From my understanding of layers, they're internal structures that keep references of the called "elements" inside them. They simply apply an depth offset on those elements that didn't have their depth manually changed, in which case removes them from the layer and puts then in the so called "managed layer".

One important thing to notice is that you can use now a mixture of layers and y-based depth, that may be the whole point of layers (with GUI, editing room and simplicity to organization and control over elements).

On the other hand, to tell you the truth, my first example on GM2 was the simplest thing I could think of. It may sound pretty stupid, but the main idea was to put all things as tiles and "separate" things as "top part" and "bottom part" in different layers. In the middle I'd put an instance layer and then I'd build my map. The player would always go under the "top part" of my assets and over the "bottom part" of them. On the instance layer I'd also create the collision boxes, very much like RPG Maker does internally.

I don't know if it will be useful for someone, but here's a ss of it...
https://imgur.com/a/eRgCrwF
 

Miradur

Member
That sounds like me, but it makes it even more complicated, so that experienced programmers can sell more solutions for it.
An Game engine that offers a command for every little thing should do this for complicated things, even more so.
If it's so easy, why doesn't YoYo provide tutorials that explain the topic correctly?

Or can I just not find one?

Miradur
 
Top