next »

[adnzzzzZ]

I've been on this problem for days: how to sort objects in a 2.5d game?

Here's basic sorting based on each object's y position:







It works well in general but as you can see in the gif, if you can stand on top of objects then it breaks. This is because if you're standing on the object and you go over its y position, as it happens in the gif, it will get sorted to behind it (because that's what the sort is based on) and look wrong.

Some solutions I've tried include sorting based on the sprite's bottom y position instead of the collision boxes y position, but this also has problems:



Because the table's sprite bottom y position is lower than the boxes', it gets drawn last, which hides the boxes behind the table when it should be above it. Another issue that comes up is when you jump:



Because the y bottom is higher, it gets sorted behind when it totally shouldn't. Using the y bottom doesn't generally work for this reason. Even trying to fix the box situation by taking the z height into account doesn't fix this particular issue presented by this gif.

Another solution I've tried is go back to using the normal y position of the object but then also take z into account. If z is higher than it should be drawn on top. But this presents another problem:



Here since the box is on top of the table its z height is higher than the player's, so its drawn last, but obviously it looks wrong.

... Does anyone know how to fix this problem in a generic and possibly reasonable way? One solution that I think would work would be to divide objects up into multiple pieces, but I'm trying to avoid this unless it's impossible to find something else because it'd make everything a lot more complex.

[clockwrk_routine]

I think I did something like this, have you tried ordering by z + y?
where the higher sum, is drawn last.

[blaavogn]

Can't you make it possible to set an y-offset/bonus-value for an object, that you use when sorting the sprites?

In the example with the table, it looks like you want the table to have an y-value that is perhaps 5 pixels higher, than it actually is. It would mean that you would have to set the value for each kind of object, but it doesn't seem to be much work.

[clockwrk_routine]

@blaavogn y-offset in that case of that table, is kind of the same thing as the height of the table, which is also equal to the players z value when standing on top of it.  so you wouldn't need to add a y-offset value as the table probably has a height value already.  at least I'm pretty sure that's how it works.

on paper it works:

player
y = 10
z = 10

other object
y = 10
z = 0

if player y < 10 and player z = 10, he'll always be drawn above other object.

[blaavogn]

I think our idea is the same. By y-offset I just mean a semi-arbitrary value that makes the numbers add up, so offset might be a bad word. I guess that is what you call z. For the table the value might be equal to the collision box height, but I am not quite sure.

After reading your post again, I think I understand what you mean with z, and it is a bit different. I guess both methods make sense, but if you have the correct z-value you might as well use it

[adnzzzzZ]

I think I did something like this, have you tried ordering by z + y?
where the higher sum, is drawn last.

This doesn't work entirely. For instance, the table's top z value is 10, so all this would do is move the position where it goes from front to behind by 10 pixels down. However, what blaavogn suggested which is in the same line of thought, works.

Can't you make it possible to set an y-offset/bonus-value for an object, that you use when sorting the sprites?

In the example with the table, it looks like you want the table to have an y-value that is perhaps 5 pixels higher, than it actually is. It would mean that you would have to set the value for each kind of object, but it doesn't seem to be much work.

Yup, this solution works absolutely perfectly. You have no idea how grateful I am, thanks a lot!!

And yea, both your solutions are pretty much the same, just instead of using z it's another value that I set based on each sprite.

[jgrams]

Heh. You got an answer that works while I was looking for the link I wanted, but in case this helps someone else...

You have y and z going in the same direction, so I think that helps. In the more general orthographic case (isometric, dimetric, trimetric) you probably need to use a topological sort based on an "in-front-of" test using the separating axis theorem. Shaun LeBron has a great article, using javascript and with excellent illustrations.

It looks a little scary at first, but it's not actually much code once you wrap your head around the idea.

[celtic.sadness]

Explaining (sorry for my bad English translation)

"Rendering" of sprites / tiles 2.5D isometrically (or not) is a little more complicated than the process explained.

You need a more complex algorithm to determine the sorting.

Basicly, algorithm checks/maps (before each scene visualization) all "front, back, top, below" tiles for each tile. Draw only consists in follow "in a recursive mode' that 'mapping'.

An example (demo) of the algorithm result can be seen here:



I am finishing a tutorial here in a few days:
http://isometric-rendering.weebly.com

[kamac]

I think he figured it out after half a year