Jump to content
  • Advertisement
Sign in to follow this  
DirkDaring

Problem with Isometric Stairs

This topic is 4391 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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]

Share this post


Link to post
Share on other sites
Advertisement
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]

Share this post


Link to post
Share on other sites
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]

Share this post


Link to post
Share on other sites
I think I see a problem. Since you are treating the stair case as just regular movement with that added z component, the player is shifted to the next square the moment he leaves that base diamond, correct? The problem with this is that the stairs aren't diamond shaped! The player shouldn't be moved to the next square until he passes out of the larger star graphic's area. You'll definitly need to treat stairs differently then other momevment to account for the larger size of the stair tile.

Share this post


Link to post
Share on other sites
Or, well, using the Z; if you're drawing with the Z accuratly, it should be working. It looks like you arent - or you aren't taking the Z of the tile he's moving onto into account.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
And yet he should be able to draw the character when he draws the tile he's standing on, and have it look fine. Which makes me suspect he's not handling the z properly. When the character is standing at the top edge of that stair tile, his z should make him get drawn much higher.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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...

Share this post


Link to post
Share on other sites
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].

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!