Hello. I’m having a problem with stairs and occlusion (objects in “front” of the players avatar hide the avatar). For those interested, the game is written in C and uses DirectX, although this should be purely a logic problem for those who want to take a shot at it. The game uses a basic diamond shaped tile system, and works by drawing the tiles from top to bottom, left to right. The avatar is drawn after the appropriate row, so all tiles drawn beforehand appear behind the avatar, and all tile drawn afterwards appear in front of the avatar. Problem is, the stair tiles must be drawn in the same loop (or layer) as wall tiles in order for walls to appropriately occlude the stairs. However, the avatar must (obviously) always be on top of the stairs when climbing them. The most obvious solution would seem to be to draw the avatar on TOP of any wall tile that is occupying the same space as him, however because the game is a smooth scroller, this method fails as soon as the avatar starts moving. The reason is because at some point during the transition from one tile to another (or one row to another), the new rule of occlusion for the next tile or row must apply. I drew this demo map to show just exactly how this works. There is a section of wall that’s lined up in a row so you can see that the lower section of stairs is actually a part of that row, and as the avatar moves up the stairs, the row must be drawn in front of the avatar for the walls (just to the right of the stairs) to properly occlude the avatar. Unfortunately, because the stairs are a part of that row, they too occlude the avatar, which is exactly what we don’t want. My game is kind of similar to Ultima Online, and Ultima handles stairs exactly how I want mine to work, so I know this can be done. I’ve already thought about redoing the entire engine so the tiles are drawn diagonally in a diamond, but beside being a royal pain and potentially inefficient, I’ve foreseen problems with this method too. Any ideas? [Edited by - DirkDaring on July 6, 2006 6:24:41 PM]

I would suggest, but am not sure whether it's best or not, having the player be identified as standing on the basetile and just raising him up. He is on tile x, y. He is at ground level, so z = 0.

When drawing the screen, I would draw each tile and it's object, but have each object also have a 'z' dimension, even though it's a 2d game. So when you get to the tile with the player, you draw the player as ((x * TILE_HIEGHT) + (z * TILE_THICKNESS)) and ((y * TILE_WIDTH) + (z * (TILE_WIDTH / 2))). You still only have two actual dimensions, but it fakes the third, putting the player on the correct tile, and allows for the player to walk under that same tile as well. I.E. you can have three or four layers of floors on a single scene, instead of one layer as well as it allows for the player to walk behind and infront of that wall.

... Sorry if I'm not explaining this too well. I'll try and rephrase it.


Player has three variables, X, Y, and Z.

X is multiplied by the tile height and added to Z multiplied by the tile thickness. Together you get the player's vertical location. Then you get Y and multiply it by the tile width and add to it Z multiplied by half the tile width to get the horizontal location.

An example: You have a 4 by 4 map of tiles, and the player is on 3,2 as shown below.

Player as 'P' _ _ _ _|_|_|_|_||_|_|_|_||_|P|_|_||_|_|_|_|

But he is also on a stair which puts him higher up. So his Z = 1.

If your tiles are 32 by 32 pixels, and 16 pixels high, you take X, which is three, and multiply it with 32 and Y and multiply it by 32 also.

So
X * Tile_Height = 3 * 32 = 96
Y * Tile_Width = 2 * 32 = 64
Z * Tile_Thickness = 1 * 16 = 16
Z * Tile_Width = 1 * (32 / 2) = 16

Player's actual x,y location is 96 + 16, and 64 + 16, respectively. The you draw him, and then continue drawing the reat of the tiles.

Not sure if that is explained better or not, nor am I sure if it's logic is correct. Heh, I'm not too smart when it comes to math.

[Edit:] Fixed a few errors.

[Edited by - Servant of the Lord on July 5, 2006 12:05:01 AM]

Hey! It's cool you came up with the Z idea, I was actually using it. Problem is those damn imagethrust photo's are comming up so small it's hard to see what I'm talking about. But yes, I do use the Z coordinate so although the player is moving more upwards when climbing, the actual player coordinates are treated as if he was just walking to next adjacent tile, which is exactly what we want. When the player reaches the top of the stairs, the Z coordinate is reset to zero, and the X,Y coordinates are adjusted to reflect his new and proper position on the next level. Unfortunatly, the occlusion problem is still there. I'll try to fix those photos soon, but it's getting late.
<EDIT> The photos are fixed!!

[Edited by - DirkDaring on July 6, 2006 6:55:14 PM]

I would draw all the tiles, then draw the character, then redraw the stuff thats supposed to be in front of the character (using the x,y,z-coordinate). This should save a lot of trouble on figuring out if he is in-front/behind stuff before you draw it. You aren't drawing that much in front so the performance should be better this way, even after redrawing some tiles. Plus you can probably (depending on your requirements) stick all your background stuff in a big vertex buffer for very fast rendering.

This is kind of off topic, but those aren't isometric tiles. In fact, that's not even a realistic projection, since the only time all that would ever happen, assuming those boxes are square, is when you're looking directly down, which is obviously not the case due to the perspective. Anyway, just thought I'd point that out. Carry on.

Yeah, those are square tiles... they just happen to be rotated 45 degrees... It looks liek the Y value of the character sprite should be much higher than it is, raising his feet above the tile below it.


"When the player reaches the top of the stairs, the Z coordinate is reset to zero" <-- why zero? Doesn't the Z just raise the Y position on screen? When walking up the stairs, the z coordinate of the next tile shouldn't be 0, that would drop him back down to the ground, behind the tile of stairs he just walked up...

The way I'm doing stairs right now [in my current project, which i am actually taking a break from working on to type this:P] is by not having a stair object at all. Instead I'm just drawing a stair-like thing as a flat tile, and then just rendering the diamond that the tile is on, on a slant. It treats it just like a hill with a different graphic, and the engine is already designed to map things moving around to the height they are at, on a given tile. Drawing stairs [which then of course could technically be drawn on a flat tile] is just as easy as drawing a grass tile.

Just something to think about, a method that was actualy really easy to implement, and works decently well. It makes stairs REALLY easy to mess with, but it looks like it's going to place a few restrictions on where i can and can't put stairs [like for example, i won't be able to have things like cracked stairs, that'll let you see the other tiles behind it, transparent stairs, like scafolding, and things like that].