How Does One Paint Isometry?

The usual drawing order is
1
2 3
4 5 6
7 8
9

But then tile 5 will overlap sprite moving between cells 2 and 3

And you can't draw underlying tiles before the sprites, otherwise large sprites would mess the higher level tiles. Typical tile cubes in games like X-Com and Magic & Mayhem are 32x32x16 (allows modelling nice curved terrain), while sprites are several times higher to maintain proportions

this problem was solved six million years ago
http://shaunlebron.com/IsometricBlocks/ (TRIGGER WARNING: javashit)
http://gamedev.stackexchange.com/questions/44966/isometric-drawing-order-with-larger-than-single-tile-images-drawing-order-algo
http://en.wikipedia.org/wiki/Painter%27s_algorithm

>>1
Just draw whatever is further away first. If the sprite is tall enough to block a higher level tile, draw the high tiles first. Otherwise, if the sprite is short and below the higher tiles, then draw the sprite first.

>>2

Z-sorting won't work, because zbuffer data is unavailable and tiles before the sprite lower Z, otherwise the sprite would occlude tiles floating in front of it.

Games like Diablo and X-com solve the problem by drawing floor tiles before the wall tiles. But my world format doesn't discern wall tiles from floor tiles, because 1-pixel high floor tiles look ugly.

>>3

That would s little complex to write and that much CPU power used for checks could be turned into larger world sample rates (i.e. 8x8x4 instead of 32x32x16).

To demonstrate the problem:
http://postimg.org/image/mo12r8fj3/

>>6
It is a funny one. Maybe you can just sort all drawn objects by distance to the camera. In isometricness, the camera is infinitely far away from the scene. Project coordinates onto the line parallel to the camera's direction. And use that number to determine drawing order. I think that would work.

>>7

sort all drawn objects by distance to the camera

that is the same painter algorithm, which "can fail in some cases, including cyclic overlap or piercing polygons."

>>8
But you don't have any polygons. Just sprites. It should work. It would work for voxels.

>>9

sprite is a poligon

>>10
sprites don't self intersect or cyclically overlap.

>>11
A group of sprites does.

The only simple solution for http://postimg.org/image/mo12r8fj3/ I see is cutting the leg off, they drawing it together with overlapping tile. I.e. a dummy object for the cutted leg, blitting part of sprite.

>>12
Painter's algorithm still works with the right ordering. Here is one.
http://postimg.org/image/c6671yx0r/

god fucking damn it, it took me at least an hour to post this.

>>13
You've totally failed. How do you determine drawing order of roof, so that 10 won't overlap some sprite standing on cube 6 or 7? And some sprite placed in a corner between 3 cubes would be overlapped by 7 cubes. Moreover, you haven't noticed that there are wall cubes behind the sprite - just above 4 and 5, but below roof cubes. What would be their drawing order? If we draw them after the sprite, they will overlap it.

>>14

You've totally failed.

Rude!

How do you determine drawing order of roof, so that 10 won't overlap some sprite standing on cube 6 or 7?

If there was a sprite there, it would have gone into the sort. Given two aligned rectangular prisms, you want to determine which could be in front of the other. Just take the coordinates of the bounding box and project onto the line parallel to the camera's direction. The camera is pointed in (1,1-1) or something like that? Normalize it if you want to, and just dot product that with coordinates and compare the values you get. It'll tell you the depth, up to a scalar if you don't normalize, which matter for getting the ordering. Do it to the coordinates of the vertices on the bounding boxes for the sprites.

The wall cubes are 7.5

You are being mean so I will not continue discussing this. Good day.

s/which matter/which don't matter

>>15

Rude!

Sorry ;_;