# Depth sorting - almost solved

### » Mon Mar 29, 2010 2:54 pm

TL;DR = in most cases it wouldn't work

I don't think layers for elevations would work from what I understand.
For example, if the player is in front of two stacked boxes and jumps, on his way up, at one point he would have to change layers. Where would this change happen? in this case, most likely as soon as he jumps. That should look fine, but what if the player is standing -behind- the two stacked boxes? The change between layers would have to happen as soon as the player's bottom '3d' side cleared the top '3d' side of the box on the bottom of the stack, otherwise, as soon as he jumped, he would appear in front of the bottom box, even though he should be behind.

And in both cases, if there was another sprite nearby on the first elevation layer overlapping the player in a certain way (depending on which scenario), the layer swap would screw up the sorting.

The best way I've found for figuring out how one sprite should behave in relation to another is to use this kind of zone diagram I drew up:

This is how another object should behave if any part of it is in any of the following zones: (the zones are infinitely long obviously)

[Blue] = In front, regardless of height
[Red] = Behind, regardless of height
[Green] = In front
[Orange] = Behind
[None] = doesn't really affect sort order but -can- be ordered by (screen Y + height from ground) if you really have to

Green and Orange override Blue and Red

Naturally, you'd have to define front and back X edges, front and back Y edges and bottom and top edges all in variables for each object. When I say X and Y here, I mean as isometric X and Y, not screen co-ordinates
With clever coding, since you've defined the '3d' bounding box, you could probably figure out a way to sort them regardless of size.

I know this is a pretty long winded answer to your question, I mostly put this here as a resource for anyone else looking for insight into figuring out how to go about sorting, or maybe it will give someone an awesome idea on how to solve it!
B
3
S
2
G
5
Posts: 351
Reputation: 2,377

### » Wed Jul 13, 2011 11:17 am

[QUOTE=Arcticus] Here's my little Isometric attempt

[url:11ydc89g]http://dl.dropbox.com/u/1289341/IsoDemo.cap[/url:11ydc89g]

I've got some collisions going but they're not 100%

I stole your movement code <!-- s:D --><!-- s:D --> So you can steal my collision code <!-- s:wink: --><!-- s:wink: -->
Coincidently, everything else wasn't copied, just happened to be incredibly similar to yours, even down to the tinting[/QUOTE]

Hi,

the collision and z-sorthing: not work well. There is someone error in the code.
B
7
S
1
G
1
Posts: 16
Reputation: 759

### » Wed Jul 13, 2011 11:57 am

the most recent post was over a year ago
Spriter Dev
B
103
S
22
G
12
Posts: 3,282
Reputation: 17,145

Previous