views:

3268

answers:

3

What is the correct way to draw isometric tiles in a 2D game?

I've read references (such as this one) that suggest the tiles be rendered in a way that will zig-zag each column in the 2D array representation of the map. I imagine that they should be drawn more in a diamond fashion, where what gets drawn to the screen relates more closely to what the 2D array would look like, just rotated a little.

Are there advantages or disadvantages to either method?

+30  A: 
coobird
you even drew pictures. That's effort.
zaratustra
Cheers coobird. I'm using the diamond approach for the current game I'm developing and it's working a treat. Thanks again.
Benny Hallett
Glad to hear things are working out :)Good luck!
coobird
+1  A: 

Either way gets the job done. I assume that by zigzag you mean something like this: (numbers are order of rendering)

..  ..  01  ..  ..
  ..  06  02  ..
..  11  07  03  ..
  16  12  08  04
21  17  13  09  05
  22  18  14  10
..  23  19  15  ..
  ..  24  20  ..
..  ..  25  ..  ..

And by diamond you mean:

..  ..  ..  ..  ..
  01  02  03  04
..  05  06  07  ..
  08  09  10  11
..  12  13  14  ..
  15  16  17  18
..  19  20  21  ..
  22  23  24  25
..  ..  ..  ..  ..

The first method needs more tiles rendered so that the full screen is drawn, but you can easily make a boundary check and skip any tiles fully off-screen. Both methods will require some number crunching to find out what is the location of tile 01. In the end, both methods are roughly equal in terms of math required for a certain level of efficiency.

zaratustra
I actually meant the other way around. The diamond shape (which leaves the edges of the map smooth) and the zig-zag method, leaving the edges spikey
Benny Hallett
+2  A: 

There's not much difference between the two approaches. If you look, both have a computational complexity that grows linearly with the number of tiles. The square arrangement leaves y unchanged per row (assuming you go line-by-line, left-to-right, top-to-bottom), so there is slightly less computation per tile, but that complexity is dwarfed by any per pixel operations you may want to do. These days, per pixel operations can be done by graphics processing units using a high-level shader language (it makes sense to do 2d games with 3d hardware these days) as specialized hardware will outperform software rendering.

If you are doing animation and going old school (no 3d hardware) you'll want to use two buffers and draw to the second buffer and then, when done rendering the the frame, flip. If you write your code in a modular way, e.g.:

Draw Frame
    Draw Map
    Update Sprites
    Draw UI
    Draw Pointer

Start with a "best and quick effort" first, using best practices like encapsulation and design patterns that abstract the method (e.g. zig-zag or diamond) - a great chance to use the strategy pattern. You can figure out where your bottleneck is by timing each action and then going back and optimizing. After your code tells you where the problems are, then change the implementation.

Edmond Meinfelder