Depth sorting - almost solved

well if you don't have depth then you don't really have 3D data of any sort, and you can't measure distance in anything more than a single axis (sort by y).

But I have X, Y and a fake Z axis. Every object has variables that determine it's top and bottom edge which determines it's height, the width is already there, I was just sayin my objects don't have a depth variable. When I say depth I meant, for example, the distance between the front bottom edge to the rear bottom edge. I don't have that variable cause I didn't see a huge need for it as I have invisible colliders underneath everything anyway.

I think your fake Z axis is the same as Madster's depth, unless I am mistaken.

Here's an updated link (well actually it's the same one with updated cap )

http://dl.dropbox.com/u/1289341/REALTEST.cap

I've got little diamond sprites representing the Y co-ordinate where each object SHOULD be sorted. I've used the same maths in a for each ordered loop that sorts all the objects. In my eyes, the math works out and it SHOULD work but dammit, it ain't. here's the sorting event in case you need it:

+ System: For each Layers ordered by ((Layers.Bottom - (Layers.Value('ZHeight') - Layers.Value('ZHeightBottom'))) + Layers.Value('ZHeight')) + Layers.Value('ZHeight') Ascending

-> Layers: Send to front

I'll attempt to translate that into english, basically, assuming each object is a '3 dimensional' cube, it takes the front-bottom edge of the sprite, finds the front-top edge of the sprite, adds the distance from the top to ground level, then adds that value again. Basically, I made a 2d side on version of this and it works perfectly.

This does not work and i believe it should, i am THIS close to solving this lol! but I need some help plz

Ok so I realised some of that code was redundant

The new current sorting loop is this:

+ System: For each Layers ordered by Layers.Bottom + Layers.Value('ZHeightBottom') + Layers.Value('ZHeight') Ascending

-> Layers: Send to front

I updated the link and cleaned up some code

Now this SHOULD work!!!! (Ironically, it's a better implementation of the code one of the devs originally gave me months ago that I thought wouldn't work)

I've put little diamonds attached to each sprite that shows 'where' in the sorting each object is, and by looking at it, you know it should work but for some weird reason its not

Why do the diamond sprites line up exactly right but the sorting doesn't, when its the EXACT same code?!!?

I cleaned it up a little further now, I made a little debug mode where you can see what's going on if you hold down C, just so its not so messy to look at.

Anyway, small breakthrough. It would seem, no matter HOW i organise the box objects, they seem to get sorted CORRECTLY!!!! Yet anything else in the same family does not, in fact, in the case of the player jumping whilst behind a box, he will appear behind it on the way up, and in front of it on the way down?!

Which leads me to believe that it could possibly be something wrong with the way families are handled in 'for each (ordered)' loops. Any opinions devs?

TLDR version: The boxes are sorting perfectly, other things in the same family aren't. Possible family bug?

what's the link?

Given how complex this sorting is getting, the bug is probably in your own code... of course, unless you can isolate a strange picking behavior with families.

I can't believe I'm posting this but maybe it's because you're sorting your height by whole numbers? You could try floats. Or having your height variables be multiples of however many pixels it is from one object's Y to the one above it. Er, does that make sense? I can't tell, I haven't had my coffee. Let me draw a picture:

<img src="http://i46.tinypic.com/mvqo2v.png">

Okay, the green box is on top of the red box. In regular 2d space they are 16px apart. So maybe their height variables should be multiples of 16. The red one's height value would be 16, and the green one would be 32, etc. That way you could easily calculate the player's height by it's base height + the distance in y it's jump is. Having fine increments of height like that might keep the player from "popping" to the front or the rear when it reaches the next height increment. Just a thought, I haven't tested it. And I'm not going to for the sake of my sanity

Here's the link

http://dl.dropbox.com/u/1289341/REALTEST.cap

It's the same link as the older ones, i just keep updating it.

deadeye, thanks for the effort and welcome back to this terrible problem I'm also making all the heights multiples of 32 and what you described it's pretty much what I'm already doing.

And since the boxes seemed to be sorting fine, I tried out what would happen if I could control one, just too see how well the sorting works. and it's still not 100% perfect, there's still a little bit of clipping when i jumped directly behind a box, so I'll need to tweak the formula a little. In terms of level layout though, the way it is, it looks pretty good.

I still think its probably a family thing that's making it so other objects don't sort

I'd just like to inform you all that ...... I SOLVED IT!!!!!!

I've still gotta tweak a few things mathematically till its as accurate as I would like, but it works EFFING BRILLIANTLY

Edit: However I have not been able to fix the family 'bug' when trying to sort a family of different objects

Please. Please... please post how you did it.

I am saying please but what I really mean is "for the love of God and all that is holy I will twist off your head and throw it into the sun if you don't"

So... please?

Anyway, I'm sure any family picking issue can be solved with lucid's S plugin, since you can do the family picking trick with that too, only without families.

I'd just like to inform you all that ...... I SOLVED IT!!!!!!

linky? the one you posted just before gives me HTTP 500

Haha Deadeye

Here's the updated link guys

http://dl.dropbox.com/u/1289341/REALTEST.cap

I realised the problem was that the sorting marker diamonds were moving down the Y axis as fast as the player was moving up the 'Z' axis. But in the perspective I'm using, the Y axis is 'squashed', so all I had to do was, instead of adding the ZHeight variable to the Y co-ordinate, I also had to multiply that ZHeight variable by the ratio of how much the Y axis is getting squashed if you get what I mean.

I still don't HAVE the accurate ratio yet, gonna ring up my mathy brother, i've just put a little hack-fix in at the moment, but it still works fine.

Oh also Deadeye could you explain how lucid's S plugin would hopefully fix this family thing? I actually think it's a problem in construct

*sigh*

Okay, so I guess my next question is... how do you do this in regular isometric?

Just the sorting algorithm is really all I'm interested in.

Is it this:

Layers.Bottom + Layers.Value('ZHeightBottom') + Layers.Value('ZHeight') - (Layers.Value('ZHeight') * 0.53125)[/code:1ew6wbfz]

Only instead of [b]* 0.53125[/b] at the end, you would have [b]+ Layers.Y[/b]?  I don't know if I'm reading your post right.

I'm not too sure, I'm gonna try and knock up a quick isometric demo and see if I can apply the same or similar code to it. In pixel art isometric though, instead of 0.53125, you would probably just use 0.5

I also realised, I'm referencing from Layer.Bottom, it still works if you use Layer.Y there, in fact it doesn't seem to matter where I reference from, as long as EVERYTHING references from the same spot on the sprite