Hi everyone... Once again I''ve having a dilema with my iso-engine. Currently, I''m storing the positions of all objects that appear on the map as positions of 32 spaces on tiles, not the tile numbers themselves. For instance, the position (256,256) would really be the top-left position on tile (7,7). This way I can have an object be anywhere on the map, not just in the center of a tile. So for a map that has 128x128 tiles, the positions range from (0,0) to (4095,4095). Get it? But the question is: How can I order all of my objects so that they''re blitted in the correct order? I''m not storing the objects in the tile structure, so I can''t just blit the object when I''m blitting the tile itself. It doesn''t know that the object is on the tile, so I can''t blit it then, and that''s messing up the z-ordering. I was thinking of keeping a linked list in the tile structure to keep track of all objects that lie somewhere on that tile. Finding the tile an object resides on is easy: just divide the x & y coords by 32. When the object moves onto that tile, I''d find where in the linked list the object would have to go to get blitted in the correct order for that tile. The major problem is that linked lists are slow. And when an object moves from one tile to a different one, I''d have to change 2 different sets of linked lists. So that would require two linked list changes per object that moves. Too slow!!! Can anyone help me on this? Thank you, because I really need a good idea on this... ColdfireV

If I am right your problem is that the "units" (moving objects) are not Z-ordered (or something like that) correct.
Let me asume that when you have only background tiles (ie grass,sand,dirt in one word "flat tiles") the blts of units are correct (for blts top to bottom).
Let me also asume that your problem is when overground tiles
gets in your way.
Ok then, if all my asumption are correct do this:
1)Create a ZBuffer for your "view" surface in system memory and set it to zero.
2)Blt your background tiles
3)Blt your overground tiles once in "view" surface and once in the Zbuffer but this time for each non-transparent pixel of the overground bitmap set the z value of the tile (here the z value is the row/y value of your map) and each transparent pixel set 0
Do steps 2&3 only when is needed!!
4)Blt your "units" with respect to your ZBuffer

ps.
1) Back & Over Tiles don''t change every frame so don''t update them.
2) When you scroll, you change only as small area of your "view" surface and zbuffer so update that area only

I don''t know if that is good for your engine but i''m glad that are good for my engine ;-)

you can e-mail me if you want at xdinos@hotmail.com

Hope I helped you.

Thanks for the advice... I''m not sure I understand your method entirely, but I get the gist of it. The problem that would arise for me is that I''d have a large array of size [SCREEN_WIDTH][SCREEN_HEIGHT]. Right? Maybe not... But however big it is, I''d have moving objects for each frame, so I''d have to update the array every frame. I don''t know if that''d be any faster than linked lists. Because I''d be updating the z-order in the offscreen buffer every frame, which would be might expensive. Thank you anyway, but unless I know exactly what your idea is, I don''t think I could implement it correctly to get the speed neccessary.


ColdfireV

Sorry, but... linked lists are not that slow. All you are probably doing is a couple of pointer changes, or at most allocating a little more memory for a list node. You will not even be accessing the lists all that often... most tiles will always have an empty list, I''d expect. And each time an object moves, it doesn''t necessarily move onto a new tile, since you are using a higher co-ordinate resolution than that. I think you are overestimating the speed of linked lists here. Since this is a simple application you''d probably just want 2 new variables, NextOnTile and PrevOnTile, and use a doubly-linked list (which is quicker to remove things from) with a few macros to add/insert/delete nodes from the list.

Thanks Kylotan... I didn''t really think about that: that most tiles won''t even have something on them. Or more than that, is that most tiles won''t even contain more than 1 object on top of it. Linked lists I guess are the way to go here. If anyone else can come up with an idea, then that''d be great, because then we can all read about it.


ColdfireV