MKy basice problem deals with object tiles that should be blitted either before or after a charcter sprite based on footlocation in on a 2D map giving a 3D look. I have explained my problem more on this site: http://www.nobispro.com/question/ Please help me!!

You might want to store your characters and objects in a list sorted by z-value (or more likely, y-value in your example). Whenever that value changes (ie. the character or object moves), ''bubble'' that character as far up or down the list as needed to preserve the sort order. Then you can just loop through the list, drawing from back to front. If you store objects and characters in separate loops, one way of doing this would involve deciding which to draw at each step, and moving to the next member of the correct list. Alternatively, merge the two lists together before looping through the master list.

Hi,

I had exactly the same problem with my 2D engine. The way I sorted it was to set my map data up with each cell (tile location) on the map containing data for the lowermost tile (ground tile... will always be solid (no colourkey) and everything would be blitted above this), and 5 overlay tiles, which may or may not be partially transparent. In most areas on the map, only one or two of the overlay tiles would be used, and in large chunks of it, only the ground tile would be used.

In my case, my tiles were 32*32 pixels, and each overlay tile in each cell on the map had a height associated with it.

Now then, when I come to drawing my screen, I throw ALL my drawing operations into a linked list, sorting each entry by the associated height value. So, all the ground tiles will go in with a height of 0, because everything gets drawn over them, the overlay tiles go in with a height=MapY + Overlay Height, all the objects, monsters and other bits and bobs get sent to the list with a Height=MapY + Any height modifiers. Then just add your status bar and other bits and pieces with a height value greater than anything that could be in your game (in my case I had a 200*200 map, so 200*32=6400.. so 8000 should place a draw operation over any of the game gfx).

Now just step through your ordered list and draw each element to the screen. It worked for me.

Hope that helps.

--== Rapier ==--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Save the whales, feed the hungry, free the mallocs!

There is one solution that involves the setup before-hand.
I use right now two types of background tile(terrain + path tiles) that I define as always being behind everything.
now there are two types of collision:
1) character to character
It''s best to display your tiles row by row down the screen and for your characters, you might want to store their position(or a pointer(4 bytes) to their character info) in the TileInfo[][] as well as in the linked list of characters. There is a certain amount of overhead in keeping track of the pointers in the TileInfo[][] array but it''s good to have that info when you''re doing path-finding.
2) object to object
In the TileInfo[][] array, you might want to have two bytes one for the object behind the character in the tile and one for an object before a character in an tile space. If there''s only one object per tile then everything is simplified.
if everything is jumbled everywhere, it''s best that, when you _load_ the objects you have, you sort them by y position on a linked-list. They''re bound to be static - not moving - and when your characters move you should be able quickly to take them off the sorted list and reinsert them(best method would be to start with the the characters position on the list and work up or down depending on the whether the character move in a positive y direction or negative y direction(
if character->ynew > character->yold)
{
MoveDownList(pCharacter);
else
MoveUpList(pCharacter);
}

I don''t think I have given direct exact answers here but I''ve given some options you can choose among. It''s going to depend on your tilespace and the trade-offs you can make

ZoomBoy
A 2D RPG with skills, weapons, and adventure.
See my character editor,
Tile editor
and diary at
my web-site

Ah, I''ve asked this question before. All you do is have a y-buffer that stores all of the y-positions, so you blit the low ones first, then the player, then the higher ones.



altair
altair734@yahoo.com
biggins.mit.edu/altair734

Depth is more often referred to as the z axis + I think Kylotan already mentioned that in the second post on this thread.

============================
Daniel Netz, Sentinel Design
"I'm not stupid, I'm from Sweden" - Unknown

I really think that the addition of a "z-buffer" negates the game being called "2D". What defines a 2D game anymore? Is it just a static camera? A birds-eye-view? Is it the absence of matrix math and lighting? If you are going to keep track of sprites in 3 dimensions, why call it a 2D game?

I think it is still described as a 2D game because graphics are still stored and drawn in two dimensions. In fact, some people argue that current 3D games and graphics cards are really 2D, because they simply transform coordinates in 3D to 2D and display them. In any case, there are very few recent ''2D'' games out there which do not give a perception of depth of some description - does this make them 3D too?

Regards

Starfall

Z-buffering is just automatic enforcement of the basic painter''s rule: closest objects drawn last in any given spot. Last I checked, paintings weren''t considered to be 3d. Why should the algorithm used to display an image change it''s nature?

Exactly. My height data is only for the benefit of my painters algorithm. The game itself is 2D.

--== Rapier ==--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Save the whales, feed the hungry, free the mallocs!