Has anyone got a good solution for dual overlaping in x,y,z sorting? problem: The "Good" scenario is impossible to achive without breaking the boxes in some way.. I can't see how this can be solved. How did the classic game Syndicate handle this, or Marble Madness? ... argh [Edited by - O-san on April 19, 2007 9:45:14 AM]

Another idea instead of sorting; Use a z-buffer to determine the visibility of a pixel. But I can't see how that would be possible with hand drawn graphics which contain no depth data to begin with. It would be very hard to draw that data for each object by hand in a seperate image.

Those games you mentioned probably break the blocks in some way. I wouldn't be at all surprised to learn that they don't support 'big' tiles at all, and that they would create those big blocks using several normal sized tiles that happen to look right when lined up.

This might help...or maybe not.

In the days before Z-buffers on 3D graphics cards, back in those dark days of DOS software 3D game engines. It wasn't uncommon for developers to create any number of "draw order" lists for rendering concave 3D game objects. the engine would use such lists to draw polygons in different orders depending upon the viewing angle. This would allow the object to more or less look correct (useing the "painters algorithm") rather then the more time consumeing read/compare/write process of software Z-buffering at the time.

So purhapse such a "draw order" list could be used? In the very least maybe have it identify only the problem areas of the map, and change render ordering accordingly.

Won't work. No matter what order you draw in, the painters algorithm cannot draw these blocks correctly.

Thanks for the replies. Now I'm leaning towards breaking down all large objects into smaller ones. The graphics will become painstakingly tedious but I think it will be the most robust method. I've looked at LORM but as far as I can see it isn't applicable for different heights. I came up with this idéa for sorting objects instead, does it look like it could work?



The bundled blue boxes creates a large object in mid air. The small green box has the wrong drawing order (2) and should be sorted first in the list. To correct this I loop through all objects and see if they cast a "shadow" (red wire box) that contains any objects that has higher z-order than the shadow-caster. If the "shadow" contains sush an object I swap them. In this case the small green box has a larger z-order value and would therefore be swaped. I know it doesn't solve the breaking of objects, I will just have to break those objects by hand when required. My worry is that this method is too slow to be used when many objects are involved.

What's stopping you from just drawing back to front?

I was wondering that myself. Unless you're using especially wide objects (i.e., they overlap several tiles), drawing left-right, back-front automatically handles z-order problems. That's rather the point of using an isometric renderer! Any ordinary back-front renderer would have drawn your blocks properly on the first pass. With wide objects, you can still break them into smaller ones, but you won't have to slice them up as rigorously as you have implied.

Are you rendering your ground and object layers in separate passes? If not, you should consider it. You can draw the ground as rectangles to pick up some speed from the extra render pass. That way you'll never encounter any overlap problems with the ground, and you can focus on object sorting if necessary.

EDIT: Correction, I see the bottom block is the one that would have been overlapped by the tall one using a typical back-front renderer. So, you will have to break that one down, but the fat block should still be okay.

Hmm okay, maybe I'm over-thinking this [smile] I haven't got around to work on the renderer yet. I'm thinking of starting to work on it today. So far I've made a win32 classwrapper and sorted out the resource handling.

Quote:Original post by Tom
Are you rendering your ground and object layers in separate passes? If not, you should consider it.

I'm a little bit against the idea of seperating my map into diffirent passes. I want it to be as modular as possible. I want to be able to have different sized ground blocks. But I haven't made a decision yet, maybe i'm just being too picky.

About the actual blocks/boxed-shaped-tiles.. I did a rough design of my tilelist last night and I thought it would be smart to have them layedout as a linked list. That way I could insert characters/npcs to the list and have them at the right position relative to the world objects. For example box1 behind and box2 infront of the player would look like:

<box1><box1->mPrev=whatever><box1->mNext=player><player><player->mPrev=box1><player->mNext=box2><box2><box2->mPrev=player><box2->mNext=whatever>

And they would be drawn in the right order. But today I've started to think that it might not be such a good idea. It will be much more difficult actually sort the list.

Anyway, thanks for all the replies! I will try them out.