Interleaved tile rendering in t2dTileMap

This resource is outdated and will not be updated any further as I have started a brand new iso pack from scratch.

You can read more here

~neo

in the beginning...

One of the first things I did when I got T2D was to play with ideas for isometric tiles, etc.
I won't bore you with all the other things I tried but skip to the first (and then last) idea:

I've extended t2dTileMap and t2dTileLayer to provide built-in interleaved offsetting. I chose to do it by
deriving 2 classes nxIsoTileMap and nxIsoTileLayer from their respective T2D counterparts and only overriding
the specific methods that deal with rendering and picking of tiles. Although this could be integrated quite easily into
t2dTileLayer I preferred to do it this way as it is a lot cleaner and we don't have to keep patching the source
each time we update from cvs. It also makes it super easy to intergrate, simply drop the source files in your project
and add a lil something to the tile editor GUI and you're in the game.

If you're not too clear on what all this means lemme throw some pics at ya:


A normal grid with isometric tiles looks like this:

[note: will add images later, in the meantime enjoy the ascii version ;p]

/\/\/\/\   ___ row 0
\/\/\/\/
/\/\/\/\   ___ row 1
\/\/\/\/

But what we want is to offset each alternate row of tiles so it fits snugly in between the row above and the row below,
which you can fake with two overlapping layers with tiles in alternate positions:

/\/\/\/\    ___ row 0
\/\/\/\/\   ___ row 1
 \/\/\/\/

If you step through the layout of the tiles you'll find the following:

We start as normal with row 0: X = 0, Y = 0
We tile that row as usual by adding TileWidth to X each time
For the next row, we want to interleave the tiles so we first
offset X by half a TileWidth, and we increment Y by TileHeight / 2,
then just tile the row again by adding TileWidth to X
Rinse and repeat.

for( all tiles in Y )
   {
       if( Y % 2 ) // is this an odd row?
           offsetX = TileWidth / 2
       else
           offsetX = 0

       for( all tiles in X )
       {
             draw tile at XY

             X += TileWidth
       }

       Y += TileHeight / 2
   }

Note that we ONLY offset the output coords... basically we are mapping the normal tile grid to an
interleaved output grid. Also this really has nothing to do with the isometric part of the deal
beyond allowing interleaving tiles, you can choose what view angle you want by choosing
the appropriate tile height and width ratio.

So the only render code that really had to change was the part where we incremented the output X and Y coords.
Oh yes, and the grid overlay drawing which I also changed, I wont go into the details of that just yet but I'll post
a piccy of it in the tile editor to show u what I mean as soon as I get time to put it up.

As it stands at the moment to use it you do this:

%map = new nxIsoTileMap(){ scenegraph = t2dScene; }

%layer = %map.createTileLayer( "16 16 32 16" );

Everything else works exactly the same from there on ;p

Next I tackled the pickTile() part which is basically just mapping the world coords to the correct position on
our new interleaved grid layout which I'll wax lyrically about later.

Other things I will be tackling is of course the all important depth-sorting issues for rendering things correctly.

I plan on posting a little demo app once its ready which will hopefully help anyone trying to do isometric stuff in
T2D.

Just goes to show you can do anything in T2D ;p

For now here's some pics to give you an idea:

In the beginning:


And then there was stuff:


And he said let there be height:


Hide that pesky grid:


As you can see I've added arbitrary height to the tile renderer, which allows
you to have things like tall walls and towers, etc. This basically just lets us draw
"up" from the tile base.

Gotta love experimenting with arb stuff heheh...

update 2005-08-25:

Back from another holiday and before I get stuck in again I'll explain a bit about the tile picking.

Here's an excerpt from the comments I have in the source:

*	Due to the interleaved nature of the the tessellation we cant just pick
//		a specific tile by using a simple formula. What we do know however is that
//		every alternate tile falls withing the rectangular grid. So first we pick
//		the rectangular grid area the point is in, then find out if it hit the actual
//		"diamond" in the "center" of that grid tile. If not it has to fall in one of the
//		four quadrants topleft,topright,bottomleft or bottomright of the diamond. We find
//		that by offsetting the local origin to the center of the tile and simply testing
//		which side of the center "diamond" edges the point falls by comparing against the
//		slope of that edge using one of the standard forms of the line equation:
//
//		Y = MX + C
//
//		where:
//			M	=	slope (Y/X)
//			X	=	X value of pick point to plug in
//			C	=	Y intercept (where line crosses Y)
//		 
//		|a/\b|	
//		|/  \|
//		|\  /|
//		|c\/d|
//
//    So if our point fell in a we'd pick the tile to the top left of this rectangular grid tile, etc, etc.

I created a little flash app to test and implement my theory and you can have a squiz at it here

Love using flash for prototyping stuff quickly and it was rather easy to integrate into C++ thereafter.

Next on my list is sorting out the artifacts I get in the editor when moving the layer, layer independent sorting, etc.

I had an idea for an lazy way to solve the depth sorting issue, i.e. don't sort at all.
Instead of drawing each layer one after another, we interleave the drawing so we draw one row from each iso layer (as well as sprite layers). This should automagically hide objects by overdraw.
After looking at the way the scenegraph works I realized that we cant really do that as each object gets asked to do its rendering and thats that. I wouldn't want to start hacking at that level just for the iso stuff though (it would be tacky ;),
so I thought perhaps create a container object that houses all the isolayers, which could then forward the render calls and split them
up per row or whatever I finally decide on. I've also started thinking that iso layers (being view dependent) might benefit from
not being derived from normal tile layers (or even scene objects) at all as we don't need to rotate them or apply physics to them,
etc. Hmmm. Perhaps an t2dISOSceneGraph ;p Let's see what my trusty code rifle brings down then ;p

Will keep you posted.

[update 2006-04-04]

I've updated the code for 1.1. but will only upload once I go over everything.

[/update]

~neo