I believe Starcraft actually did use rectangular tiles, they just 'faked' the isometric perspective by using larger 'meta-tiles', which are aggregates of smaller tiles that can hold a more complicated tile configuration than a single rectangular tile holds. IIRC, the actual tile size in Starcraft was very tiny, and all the real work was done with these larger meta-tiles. This is an extension of the tile-based idea, as is the method used by games such as Dungeon Siege as previously mentioned. A tile can be as simple or as complicated as you need or want it to be, and aggregates of tiles (meta-tiles) can themselves be viewed as tiles and manipulated accordingly.
Typically, 2D isometrics utilize diamond-shaped tiles. Each tile is held in a rectangular bitmap (usually with a tile ratio of 2:1, ie 128x64) but the effective area of the tile is diamond shaped. You can see my isometric tiles tutorial here for some examples on how to construct isometric tiles if you are curious.
Diablo and many others did what you suggest, modelling their characters in 3D then rendering to a series of BMPs (I actually use Targa format, since Blender will render to that image format, with alpha channel support for transparency) for import to the game. However, this is not using 3D in your game; it's simply using 2D sprites, just like any other standard 2D game. The only difference is that the sprites were created with a 3D modelling package, rather than drawn by hand. The sprites will still be drawn using 2D techniques, and there will still be the limitations imposed by using 2D sprites. That is, for an isometric perspective, each character and object needs to be pre-rendered to bitmap file sequences in all of the possible directions the character or object can face. Typically, you render in 8, 16 or 32 possible facing directions (though, for symmetrical characters, some of these directions can be mirrored).
Truly 3D characters will store the characters as 3D meshes, to be given to the 3D hardware as sequences of textured polygons. The viewpoint camera is tweaked to match the parameters implied by the isometric perspective, so that the models are drawn in the correct location. The necessity of pre-rendering different facing directions is removed (thus vastly reducing the amount of memory needed to store a character), since rotation of the character is performed simply by applying rotation to the character's orientation matrix. The 3D hardware performs the rotation, and it is not necessary to limit to 8, 16 or 32 facing directions.
Tiling engines
Does anyone know what sort of spatial hierarchy system Dungeon Siege used? I would imagine something like quad-trees or oct-trees would have worked well. It's quite a heavily CPU-bound game though; it chugs on my Celeron 766 with GF4, whereas NWN is mighty smooth (although NWN is more of a "room"-based engine and you only have a party of two).
cheers
sam
cheers
sam
Wow! Thanks for the great info guys! I'll check out that tutorial as well.
Here is an algorithm that I made during Chem class. Its not final, and needs some work, but does it look more or less ok? Or have I completly missed the boat? ;)
http://www.members.shaw.ca/BradenC/1.jpg
http://www.members.shaw.ca/BradenC/2.jpg
Also, how do you have objects that are larger than one tile?
Cheers
Chris
Here is an algorithm that I made during Chem class. Its not final, and needs some work, but does it look more or less ok? Or have I completly missed the boat? ;)
http://www.members.shaw.ca/BradenC/1.jpg
http://www.members.shaw.ca/BradenC/2.jpg
Also, how do you have objects that are larger than one tile?
Cheers
Chris
Those are some pretty large images. [grin] Tell you what... why don't you go ahead and make a small test application to see if it works?
If you read through the archives of the Isometric forum, you'll see exactly how tricky objects larger than a tile can be, especially when it comes to drawing them. Typically, an object is 'owned' by a tile, but since it overlaps tile boundaries it is possible that it can be on a tile that doesn't own it, and thus isn't incorporated into the drawing order of the overlapped tile. Strange draw-order problems can result. Also, if the tile that 'owns' a large object happens to lie off the screen and outside of the view area, but a tile that it overlaps is onscreen, then the object will not be correctly drawn and will suddenly appear in a very ugly fashion if the owner tile comes in view.
To help with some of these problems, I allow objects to be 'owned' by more than one tile. If an object overlaps a tile, a pointer to that object is inserted into the tile's contents list. Since an object may be owned by more than one tile, I can not now simply draw all of the Contents lists for every tile in the view. Instead, what I have to do is iterate all of the Contents lists, and insert objects to draw into another list. If an object is already in the list, it is not inserted again. It is a little slower this way due to list management, but it prevents some of the wierd problems of partially offscreen objects appearing and disappearing inappropriately. I can sort the draw list from back to front so that iterating the list will draw the objects in order from back to front with correct overlap. Or, at least, mostly correct overlap. There are still going to be tricky overlap issues between some objects; browse the Isometric forum for some possible solutions to such problems.
This is one of the attractions that true 3D offers. The Z-buffer automagically eliminates all of the wierd intrinsic draw-order problems that plague traditional 2D isometric engines.
If you read through the archives of the Isometric forum, you'll see exactly how tricky objects larger than a tile can be, especially when it comes to drawing them. Typically, an object is 'owned' by a tile, but since it overlaps tile boundaries it is possible that it can be on a tile that doesn't own it, and thus isn't incorporated into the drawing order of the overlapped tile. Strange draw-order problems can result. Also, if the tile that 'owns' a large object happens to lie off the screen and outside of the view area, but a tile that it overlaps is onscreen, then the object will not be correctly drawn and will suddenly appear in a very ugly fashion if the owner tile comes in view.
To help with some of these problems, I allow objects to be 'owned' by more than one tile. If an object overlaps a tile, a pointer to that object is inserted into the tile's contents list. Since an object may be owned by more than one tile, I can not now simply draw all of the Contents lists for every tile in the view. Instead, what I have to do is iterate all of the Contents lists, and insert objects to draw into another list. If an object is already in the list, it is not inserted again. It is a little slower this way due to list management, but it prevents some of the wierd problems of partially offscreen objects appearing and disappearing inappropriately. I can sort the draw list from back to front so that iterating the list will draw the objects in order from back to front with correct overlap. Or, at least, mostly correct overlap. There are still going to be tricky overlap issues between some objects; browse the Isometric forum for some possible solutions to such problems.
This is one of the attractions that true 3D offers. The Z-buffer automagically eliminates all of the wierd intrinsic draw-order problems that plague traditional 2D isometric engines.
Ya they are....Sorry, I forgot to resize them! I'm trying the test app, but am having a few issues with that, which I'm working on atm. I think that I will have to find a new way to deal with objects than the way I had previously planned... Thanks for the great info, I appreciate it a lot. I will probably be back, with commments and/or erros! ;)
Chris
Chris
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement