   Isomteric ground of different heights
  I'm currently trying to make an isomteric game with ground of varying heights. I have taken a look at the gamedev articles, and while some have been invaluable to other aspects, none have said how to do this. While reading "Mouse Maps for Isometric Height Maps" I saw a picture of all the different types of possible terrain. After looking at this picture some more, I noticed that the 16th image is completely missing. I then took a look at the images for some similiarly-done programs and noticed that they, too, where missing this image. So my question is, why don't you use any picture there and how do I know whether or not to use that?I currently have a system in which each tile has four corners, each of which can be either 1 or 0, representing whether or it is above the tile or on it.Hmm... I didn't word that real well, but hopefully you guys can understand what I mean. Thanks in advance.-Ezbez   
  Why not render in 3D and use bump maps?   ;  thats not what he wants to do. hes talking about drawing his terrain at different hegihts not any kind of lighting thing.   ;  Yeah, the AP is correct. While you probably could do 3D with bump maps for a similiar effect, I currently don't know OpenGL or DirectX.Oh, and a link to the image might help:http://images.gamedev.net/features/programming/mm4ihm/IsoMap_Tiles.gif   ;  It's not the 16th, it's the 15th.  :)On puzzling over the image I realised it was dealing with the corners in binary.  The top corner was 1, the right 2, bottom 4, and left 8.  The pictures in sequence were the corners raised, as per the binary value.  The 0th square was normal.  The 1st had the top raised, the 2nd had the right, the 3rd had the top and right... 4th had the bottom, 5th had the top and bottom, ect.  When it got to the 15th, all of the corners were "raised", which meant that the tile was exactly the same as the 0th, or "everything on the same level" tile.  This would be different if your map allowed for four-point holes, but in all my gaming experience I have never seen this.Now, I would love someone to explain the next few images after 15.  The 16th bit is for twice the height of the top corner, perhaps...?   ;  I would store the height as a separate piece of data about the square, and offset the image up by N pixels times height when drawing it. Thus, you don't need to create more than 16 different tiles -- as long as you have the rule that no neighboring tiles may differ in height by more than one.;  @TokThe images after the 15th(sorry about saying the 16th, I have problems counting ;) ) are for when, as you said, one corner is 'two up.' These are necessary for drawing a mountain that is at least two high up. Their bottom edges fit in with the one corner one high, all the rest 0 high. Um, well its a little hard to describe, but hopefully you understand.Thanks for the explanation!   ;  You were originally correct, it was the 16th image- I was trying to make a binary joke, by starting my image counting with the "0th" image.  Programmer humor.  Ha, ha. :pQuote:These are necessary for drawing a mountain that is at least two high up. Their bottom edges fit in with the one corner one high, all the rest 0 high.Ah, so no tile corner can be more than 1 high than the corner next to it.  If the top tile is two levels higher than the bottom, the left and right are "stretched" to height 1 by default.  Yes, I understand- I've enjoyed a lot of heightmap isometric games in the past.  (Rollercoaster tycoon, Sim City, and C&C Red Alert spring to mind)As for the implementation of this type of map, I must admit I've never tried it, but it sure sounds fun!  My first thought is to store the map as a three dimensional array with length, width, and two layers- one for terrain index values, the other for a height.  That height value would then be for the top left corner of the tile in a plain topdown map, or the left corner in the standard "TL = North" skewed isometric map.  For a simple map with only one terrain type, I would then run through all the tile information, comparing the height of a tile with that of its neighbors to determine which image to use, and store this as the terrain index.  During gametime the height info would be used to draw tiles and units at the correct coordinates.   