newt I understand how to sort the z-order, I also understand how to change an object's z-order based on their Y. I'm not doing this in my case because the z-order is affected by a z-axis as well as a y-axis.
alextro My objects all have different widths and heights and my game isn't isometric, although your formula is quite clean, I really wish it'd work for me :(
R0J0hound I've tried your sorting algorithm designed for my perspective, and while it works in the capx you sent, it seems to function incorrectly when I try to implement it myself. Since it works for you, there is evidently something I am doing wrong.
"SOLID_SPRITES_Family" would be equivalent to "Sprite" in your example, and "SOLID_SPRITECOMPARATOR_Family" would be equivalent to "other" in your example.
The main issue that arose was that some objects just wouldn't sort correctly, and would be placed under ones they should be over. The other issue was that sorting wouldn't occur unless the collision boxes actually overlapped.
In my game the collision boxes do not cover the full sprite due to how the collision works with incorporating the z-axis. I thought this was potentially the problem, so when testing I made the collision boxes cover the entire sprite like in your example, which didn't fix it.
I thought potentially it was because the origin point was not at the very bottom of a sprite like in your example. I moved it to the bottom, which did not fix it.
You may notice that my sorting method is not a 1:1 copy of yours, this is because the z-axis is more positive the higher up an object is in my game. In your example, the z-axis is more negative the higher up an object is. To fix this, I just made the references to the z-level in the algorithm flip (instead of -sprite.z it'd be +sprite.z, I doubt these changes are the cause but I thought they were worth mentioning).
In the portion where you set dy, using yy, I just do the yy calculation there. I don't think that would affect anything besides performance. I also add z to y instead since z is positive in my case.
I didn't have an sy value prior to implementing your system, so I added it and set it accordingly for the sprites I was testing with.
Just so it is easy to understand the difference in variable names, yy is just y+z (in your case it was set to y-z, but I can't do that), z is z (but positive), sy is length, and sz is trueHeight.
The alternate family has the same sprites as the main, and all its variables are properly synced with the main. SCz is equivalent to z, SCtrueHeight is equivalent to trueHeight, etc.
Any idea what I've done wrong? Once again, if I've explained poorly and you need clarification please let me know. I really appreciate how helpful you've been.