🔒 Locked

Depth sorting

Started by _Flecko Jun 9, 2006 at 11:51 PM 2 replies 2.8k views

Original Post

Jun 9, 2006 at 11:51 PM

I'm working on an isometric game where the tiles are squares, and having a hard time figuring out how to depth-sort objects. Have a look: http://mail.rochester.edu/~mabernet/isometric.swf (use arrow keys to move the red box, space to jump). At the moment, it sorts from front to back, then top to bottom where there are ties. If you jump on the low wall to the right and move towards the back, you'll see the problem: the wall gets displayed over the box, even though it ought to be the other way around. The problem is that since the box's front-back coordinate is at that point less than the wall's, it gets sorted behind. What's the proper way of computing depth in a situation like this? Is there any linear ordering of objects based on their coordinates that gives what should be in front of what? [Edited by - _Flecko on June 10, 2006 12:09:28 AM]

Wyrframe

327

Wyrframe

Jun 10, 2006 at 1:53 AM

From the looks of that sample, just sort from front to back based on the Y-coordinate of the bottom of each object. Is that what you're doing, or have I misinterpreted the problem?

_Flecko

Author

_Flecko

Jun 10, 2006 at 11:45 AM

That was more or less what I was doing. However, after a good deal of strugglin, I realized why I'm having so much trouble making it work: because it is -impossible- to do it the way I was trying to :)

There is no linear order on the depth of whole objects - cubes, faces, etc. That is, if you're treating objects like a cube as a single unit, you can't find a strict order to draw objects in. If my scanner was set up I'd show you proof; basically if you assume there is a linear ordering, you construct a situation where you have two objects a and b where it is simultaneously true that a is in front of b and that b is in front of a, which contradicts that such an ordering could exist.

So, now I gotta find a different way to do it.

[Edited by - _Flecko on June 10, 2006 5:45:19 PM]

Wyrframe

327

Wyrframe

Jun 12, 2006 at 12:11 AM

Well, of course such situations exist. That's why you, as the designer, connive yourself up some clever way of preventing the situation. It seemed to me in the example that the collision bounding boxes of those objects were at and for a ways above the base of the object. This prevents an object from suddenly "popping" ahead or behind the other one, which makes it so you never get a situation where it matters.

Think oldschool RPGs. A player appears in front of the trunk of a tree, but behind its branches. This is done by having the branches always drawn "in front" of the player, and by making it so you can't walk through the trunk, only either behind it or in front of it.

Considering your boxes; you can jump on top of them. I assume that you have an X,Y, and psuedo-vertical-Z coordinate for objects, and that this XYZ position represents the center-front-bottom of the object. Are you sorting them by world Y, or by screen Y? You should be sorting by world position. For ties, you sub-sort by world Z, like you're doing now.

      _____     /   /|    /___/ |    |   | /    |_._|/

The "." is where the object is sorted by; at the X center, Y front, Z bottom of the object.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.