Best approach for Y Sorting

I am starting to work on a game with a 3/4 overhead viewpoint (think Final Fight or Streets of Rage) and I plan to use a lot of active objects for scenery and interactive stuff. I have always had issues in the past with sorting objects properly, especially when the player and moving enemies/objects are constantly changing their Y (depth) positions. Can anyone offer a low overhead solution for managing the sort order of things in a scene?

I have tried using the Layer Object's "Sort Descending Y" in the past, but found out it is a very costly operation to always perform, especially on mobile. Is this something that ForEach loops would be better at handling? I had considered a system where objects are laid out in the scene with preset depth values stored in a var. Then leave large gaps in the depth value ranges to allow for a lot of moving objects to exist inside without mucking up the static scenery's depth arrangement.

I searched around but can't find any good examples or suggestions on best practices. Anyone have any ideas?

Ugh, I typed out a long response and it disappeared. So if it shows back up, excuse me for the double post....

I've done multiple top down engines with lots of Sort By calls and not had any hit on performance (but not on mobile). I'd recommend trying Sort By Alt Val though instead of Y position as it gives you a lot more ability to fine tune how things sort. Choose an Alt value you can use on all of your objects (AA or something far enough down it won't mess up different object types) that will be sorted and add them to a universal group (ex: generic 1). Then on creation or at the start of the frame set their AA value to something like (this may be a bit rough I'm just typing from memory quickly):

YBottom(Active) * Z + (X(Active)/1000.0) where "Z" can be a unique integer used by different object groups to help define specific sorting (Example: background decorations (Z of 5) can be sorted with each other but will always be behind Foreground characters( Z of 10)). I add a small decimal based on X position so that overlapping objects with the same Y position and Z multiplier don't flicker between each other. Moving objects can have these values always updated with ForEach loops if there are multiples). You might be able to adapt this to your own custom ForEach system and not use the Layer object, but no idea how that would improve performance.

Also, what happened to Slayin' 2? I was following the blog posts and then they stopped. Have you moved on or is this some iteration of it? I do recall it was going to have multiple lanes to fight in.

@CuddlyGoose Thanks for the suggestion. I will give it a try and see where it goes. I guess the division by 1000 is defining your max objects per "Z" to 1000? I was always unsure if the sorting in Fusion allowed floats, but hopefully it does.

This is actually for a possible next project after Slayin2. I want to resurrect an old idea I did a while ago when I was just using a Layer Object Decreasing Y sort. I did a game on iOS (Treasure Buster, I think) that originally had an Always -> Sort Decreasing Y and it ended up being a serious bottleneck on mobile, so I had to make a lot of obnoxious sorting rule code instead. Since then, I am always wary of using the Sort by Decreasing Y, but maybe I am too overly cautious.

As for Slayin2, it is being ported to Switch now with a publisher. We are finishing up bug testing so it shouldn't be long before it hits the eshop. You can follow my twitter ( https://twitter.com/pixellicker ) or FDG Entertainment ( https://twitter.com/FDG_Games ) on twitter to get current news. Also, Slayin2 does use unique layers for the 2 planes, so there is very little manual sorting.

The X position being divided by 1000 is a random example, but the idea is to just add a small decimal on after the Y position is multiplied with the Z value you have for each type of object. So if you have 2 objects on the same Y position and they are the same qualifier group they don't flicker back and forth between which one is in front. I never thought about the Sort by Alterable value being different than using alterable values for anything else, so I actually don't know, but it stopped my flickering problem when I started tacking on a tiny extra value. If the X value is too big, you can get objects overlapping in weird ways.

Also just followed you (I'm Gold5Games). I thought I already had followed to be honest.

I actually found this to be very useful: https://community.clickteam.com/threads/58528-Y-Ordering?highlight=order

Hahaha. That is painfully simple and probably has the same issues CuddlyGoose's division by 1000 fixes. But thanks for the link. It is always good to have different ideas on how to approach the problem. :)

@CuddlyGoose : ok, I tried your method and it doesn't seem to work. I am guessing I messed up somewhere int he eventing, but I am creating a grid of objects at runtime with a fastloop and then running the layer obj Sort Decreasing by Alt Var when I press a key. You can see the issue in the image. The sorting is not maintained in the rows, even though the vars are being set with the proper decimals (smaller decimal values to larger values going left to right).

Any idea what is wrong here?

Attachment 28171
Attachment 28172

@mobichan I recreated your example because I can't find any of mine at the moment (probably on a backup in storage) but it appears the X decimal isn't working, but not dividing the X works fine (I must have remembered wrong) in this instance. You can also use a spread value on creation or any other unique modifier to maintain the order they are created in.

But yeah, just add the X value as an integer as is and it works fine in my test.

Sadly, if I go back to integers, then there is an issue where moving horizontally doesn't maintain the proper sort order with the moving player object (the light blue square in my image). Using floats actually did that part correctly, but didn't maintain the order among the purple squares themselves.

Hers is my mfa if you want to take a look.
Attachment 28176

Quote:

---

Originally Posted by mobichan

Sadly, if I go back to integers, then there is an issue where moving horizontally doesn't maintain the proper sort order with the moving player object (the light blue square in my image). Using floats actually did that part correctly, but didn't maintain the order among the purple squares themselves.

Hers is my mfa if you want to take a look.
Attachment 28176

---

Took a quick look. Sorry I'm a bit fuzzy on the details from when I did this, but you can simply increase your sort order values (I made them 50 as a quick test) so the X integer doesn't need to be a tiny float (you can still divide by 10 if you'd like to keep the numbers smaller with less issue for value overlap).

Attachment 28177

@CuddlyGoose That did the trick. Thanks for taking a look. I am still a bit confused by why it now does what it should. Guess this can be added to the long list of "quirks" in Fusion. :/