The idea is to eliminate repetition. Best example would be Super Mario Bros. Now, the first level is made up of maybe 12 different tiles (blocks, bricks, sky, bush, a few for pipes, question blocks, etc.). Now, instead if a 2D array of bitmaps, now you have a 2D array of ints, and each int represents a tile. Now when you draw the screen, wherever the map has a 2, you put a brick tile, where there's a 3, you put bricks, etc. So instead of one big bitmap with the whole level and lots of blocks, you just have one bitmap of blocks, and you blit it wherever you need it.

Hang on; I may have a simple demo here somewhere (you'd think there'd be a tilemap demo in allegro/examples ...)

Ah, here's the beginning of a Pixelate tutorial I was going to do once (may yet finish it one day). Incomplete, but shows the basics. I wish spellcaster's site was still up; that had good info ...

Tilemaps

I see a lot of tilemap format tutorials out there (and so will you, because I have a bunch of resources for you at the end). We won't be discussing that here. Well, not initially anyway. Everyone has a way to implement tilemaps, and one person's way may not work for another. I'm going to show you the concepts and theory behind tilemaps, so you can understand how they work. Then, I'll show you my way of coding it. Then, a few other ways I've seen it done which work well. Finally, some links to sites where you can learn more about tilemap structure and techniques, and I can assure you there's no shortage of those. In this manner, I hope that you won't merely accomplish the simple task of getting graphics to display in a grid on your screen (child's play), but to be able to write your own classes, file formats, structures, drawing techniques, personal preferences, etc. so wherever you go, you'll introduce yourself with a bow and a "Greetings .... I am .... (insert your name here) .... grand mas-tah tilemap codah .... this keyboard and mouse .... are a-deadly a-weapahns ....".

Tilemaps are very simple to code, and my only assumption here is that you know arrays and for loops. This tutorial is platform independant; the code examples I give are in Allegro, but that's because it's a pretty self-explanitory library of functions, and I'm sure you can port these examples to any platform with a minimum of fuss. I code C++, but I don't use anything fancy, so this is essentially C code.

Why use tilemaps?

Hmm, good question. Tilemaps are used for video game background, right? Why go through all this bother to design a class and stuff when we can just use one great big image? One blit and your done. Works for Resident Evil, works for Final Fantay VIII. Heck, it works for Abe's Exodus, and it's a platform game! Sure, that may seem easier to implement. But games like Final Fantasy have areas only two screens wide and high (at best). And Abe and RE don't scroll at all! Yet Super Mario Bros., a game some 15 or 20 years old, has areas that scroll for something like 40 screens? How'd they do that? All in the magic of tilemaps. And as we'll see, tilemaps do more than hold mere image data.

Remember when I said we'd look at how to implement tilemaps after we discuss theory? I lied; we need an implementation so I can demonstrate the theory. Keep in mind I'm organizing data like this to make it easier for you to learn; we'll look at infinitly better implementations later. First, we need to store our tiles. What's a tile? A square (or rectangular, depending on your tastes) bitmap, many of which are used to draw a background or environment. Every tile used for a particular background should be the same width and height so they fit together easily. The dimensions could be anything, but some sizes are easier to use than others. Common practice is to pick sizes that divide evenly into typical screen resolutions, and better yet, powers of 2. 8x8, 16x16, 32x32, 64x64, 20x15 and 40x30 are all perfectly fine. 8x8 is probably a bit small for most games, and 16x16 is nice for old NES games, but probably unsuitable for today's high resolution games. I generally use 32x32 myself. Anyway, for our discussion here, it doesn't matter what the size of the tiles are, only that they all have the same size.

Now go look at your Super Mario Bros. See the tiles? The entire game is comprised of tiles. Brick tiles. Block tiles. Question block tiles. Pipes. Clouds. The infamous flagpole. Any part of the background is a tile, all layed out in a grid. In fact, any given level is only made up of 20 or so tiles. And that's a major advantage of tiles; you can build a world with a handful of small tiles, which uses far less memory than one big background image. This also means you can make more levels, not just more efficient ones. Big graphics take up storage space as well as RAM. And finally, it takes a lot less time to make good looking tiles than it does to make good looking screen-sized bitmaps.

Code time

So, how to hold our tile data?

BITMAP*   tiles[20];

This is an array of 20 pointers-to-BITMAP. A BITMAP (no, I'm not shouting) is an Allegro structure for holding graphic image data. If your using some other graphics library, don't leave yet. This translates to any library easily enough; just substitute your own structure for BITMAP. Now then, this is our first tilemap essential, we need an array of structures which hold information on individual tiles. This needn't be done this way; there are other ways we'll see later. But this is probably the easiest to understand. Now we need to fill that array with something. Images, preferably. Yes, that will do nicely. We'll load a bunch of individual images into these slots:

tiles[0] = load_bmp("skytile.bmp",   NULL);
tiles[1] = load_bmp("cloudtile.bmp", NULL);
tiles[2] = load_bmp("grasstile.bmp", NULL);
tiles[3] = load_bmp("bricktile.bmp", NULL);
tiles[4] = load_bmp("blocktile.bmp", NULL);
..... /* etc. */

Those of you at home who wish to play along can draw 20 quick, small bitmaps named whatever you want and load them into the 20 elements of tiles[]. Don't bother being Picasso here; the sky tile is blue, the cloud tile is a white blur on blue, the grass is a green shape on a blue background (you may not be Picasso, but you can have a Blue period, right?).... just throw some pics together. And make however many you need; it doesn't have to be 20. For those of you new to Allegro, load_bmp() loads a bitmap (duh) given the filename of the image. NULL would be palette information when dealing with 8-bit color, but I'm a 16-bit kinda guy, so I don't use it. See Allegro's documentation for proper use of this function and any others I bring up.

And that's it. We have our image data. But how do we get it onscreen? And better yet, how do we map out the locations of our tiles onscreen (now you know why it's called a tilemap). First question second, second question first. We need a layout for our tilemap, so the computer knows what tile goes where. This is the second essential of tilemaps; we stored the individual tile information, now we need to store the tile layout. Time for another array, this time a 2 dimensional one:

int map[5][10] = {
   {0, 0, 1, 0, 0, 0, 0, 1, 0, 0},
   {0, 0, 0, 0, 1, 0, 0, 3, 0, 0},
   {1, 0, 3, 0, 0, 0, 3, 3, 1, 0},
   {2, 0, 3, 2, 2, 3, 3, 3, 2, 2},
   {4, 4, 4, 4, 4, 4, 4, 4, 4, 4}
}

Obviously we can have bigger tilemaps than that, but we'll use 5x10 as an example. Now look back at how I loaded my bitmaps. tiles[0] is a sky tile, right? So everywhere there's a 0 in map[][], there will be sky in the background. 1 will be a cloud, 2 will be grass, etc. From the look of map[][], this is a sky with some clouds, a floor made of blocks with some grass, a small stack of bricks and a brick staircase. Simple. The number in the layout corresponds to the element of tiles[] that goes there.

So, we have our images, and we know where they go. Better yet, the computer knows. But how do we get the computer to draw it correctly onscreen? Easiest thing in the world, m'lad:

for (int y = 0; y < 5; y++)
   for (int x = 0; x < 10; x++)
         blit(tiles[ map[ y ][ x ] ], screen,  0, 0, x * 32, y * 32, 32, 32);

Now that's pretty loaded for 3 lines of code, so let's step through it. The first two lines are pretty self explanitory; we want to access all elements of map[][], and the best way to do that is to cycle through it with 2 for loops. blit() is pretty loaded. For those of you who are total newbies, the term blit means to draw a bitmap onto something. Here, we blit to the screen, and if we're going to continue, I best spell out for you what blit() does. Here's the prototype, straight from Allegro's documentation:

void blit(BITMAP *source, 
          BITMAP *dest, 
          int source_x, 
          int source_y,
          int dest_x, 
          int dest_y, 
          int width, 
          int height);

OK, the first parameter is the image we want to draw. For our purposes, obviously we want to draw a tile. Look at the for loops again, we pass tiles[ map[ y ][ x ] ] as the first parameter. map[ y ][ x ] gets us the number of the tile we want, and we give it directly to tiles[]. So that's how we use map[][] to figure out what image in tiles[] we draw, and because the for loops go through map[][] in it's entirety, we draw every tile in map[][]. The second parameter is where the image is going. Here, we draw to the screen. The next two parameters are the coordinates that we want to start drawing from our tile. We're drawing the whole tile, so we pass 0, 0, which is the upper-left corner. The next part is interesting; the coordinates where we start drawing to. This is important; the tiles should be evenly spaced, matching up at the edges. But it's not hard; we just multiply the width of the tile by x and the height of the tile by y (note that x and y change every loop). So the first tile would be drawn at x * 32 = 0, then x * 32 = 32, x * 32 = 64, 96, 128, 160 ..... perfectly spaced! The final two parameters are the width and height we want to draw; again we want the whole tile to be drawn, so we just pass the width and height of the tiles. Here, I'm assuming the tiles are 32x32; change all the 32's in blit() to suit your tile's dimensions.

So that's it for drawing. We use two for loops to access every element in map[][], using that element to determine what image in tiles[] to draw. And we use the loop variables to determine where on the screen to draw the tiles.

long post~:P

what happen if a big block is 5 tile widthx5 tile height,how it place to a 'tile'? need to split it?

It would make a good pixelate article, where are the links you promised at the beginning of it>?

I think I understand tilemaps slightly better now, meow

the evil that is gamedev....
havent been there is months...

A program about US history? That should take all of five minutes!

Now, my constructive comments - many people who are not stuck with 1980's style tilemap hardware don't used fixed size tiles. Quadtrees are an obvious example, but they have limitations for this purpose. A very simple alteration you can make without having to think too hard is to include a 'skip' count in your tiles. Assuming you are moving left to right, after each tile is drawn you then don't draw for as many tiles as the skip count says. For a standard tile map, the skip count would always be 0.

If you wanted to include a tile that was actually sized nxm tiles, you'd link its bitmap to the top left tile it covers, and leave a skip count of n-1, then for m-1 rows below, you'd fill in an n skip count on the preceeding tile.

I hope this makes sense . . .

I agree, Nintendo's hardware designers are stuck in the 1980s when it comes to 2d hardware. Obviously systems that demonstrate good designs, such as the Amiga & Lynx passed them by.

Obviously you can get some quantity of overlap using this quick hack, but higher tiles will always appear below lower ones, and ones further to the left will always appear below those further to the right. However, it is just a quick hack for people who insist on sticking to tilemaps but want a bit of extended flexibility in terms of large tiles - its perfectly adequate if you aren't going to have overlap.

Something I forgot to mention - it is also useful to give the tiles that are ordinarily skipped on the line where a large bitmap is drawn a negative skip value, pointing to the tile before them that actually holds a bitmap. That way you can regain what you are meant to be drawing even after reducing the tile set to those visible at the current screen offset. Of course, on lines that have a skip because of a large tile on a previous line, just use positive offsets to the next graphical tile.

Here is the mistake :

  BITMAP *Tiles[4];  // Create an array of bitmaps to hold the tiles 

   for( int a=0; a<4; a++)  // Load all the tiles into the array
   { 
      blit( (BITMAP*)Images[a].dat, Tiles[a], 0, 0, 0, 0, TILE_W, TILE_H);  // blit the tiles into the correct space
   }

You haven't allocated any memory to 'Tiles'. The simple solution would be to do instead this :

  BITMAP *Tiles[4];  // Create an array of bitmaps to hold the tiles 

   for( int a=0; a<4; a++)  // Load all the tiles into the array
   { 
      tiles[a] = create_bitmap(TILE_W, TILE_H);
      blit( (BITMAP*)Images[a].dat, Tiles[a], 0, 0, 0, 0, TILE_W, TILE_H);  // blit the tiles into the correct space
   }

But I suspect you are copying from the datafile to different bitmaps so as you can use hardware acceleration where available? In which case you want to look at gfx_capabilities and possibly use one of create_video_bitmap or create_system_bitmap.

I'd thought of that (I was going to call it RLE tilemaps ) and also of multisized tiles, but it seems more trouble than it's worth. I mean, I want to be able to access these things for collision detection and maybe their "types" (if it's ice, you slide, etc.) plus if it's a big map and I'm off on the right side, it's a pain to go through the whole lookup to find where to start blitting. There's probably some advantage that justifies not taking the simple 2D array approach, but it works, it's easy, it's fast, so screw it.

There are plenty of advantages. For example, one time I experimented with a game idea where the entire level was deformable - it would stretch and depress based on where you distributed weight. I had some good ideas of where to take such a game, but as with most things, just didn't bother. Anyway, thats just one 2d platform type game which would almost certainly not be helped by me suddenly deciding I wanted to use a tile map.

I personally would opt for a 2d polygonal representation regardless of the project, there is just so much more interactivity you can include that way, with procedurally placed vertices, making the positions of various things functions of other things, and so on.

Yes, but if you push it a little further: every tile should be a multiple of the smallest possible tile, the 1x1 tile. At this point, you have arbitrary sized tiles

Yes, but you're also very slow, as each pixel is being drawn with a blit call. A tilemap, at that point, becomes a palatted image.

Then you must be stuck in a routine world of samey games.

Probably just once. But then I'd only do any thing just once. This is a cause and effect style question. Are there lots of 2d tilemap/static scrollers nowadays (i.e. since it stopped being a hardware necessity for programmers of limited systems) because every programmer has a supremely limited imagination, or because there are so many tutorials?

Actually, seeing the number of identikit RPGs on here, it might just as well be the former as the latter.

The SNES is hardware of the 80's, but lets not quibble. My point is that if you look at a well designed 2d powerhouse machine, such as the Atari Lynx, and a badly designed one such as the GameBoy Advance, you quickly see the difference.

On the Atari Lynx, you load a particular register with the address of your frame buffer, then you build a linked list of some sprites in memory (anywhere in memory, this is not a sprite list in the Nintendo sense), and you ask the hardware to draw those sprites with the provided scaling parameters. It draws them to your frame buffer and returns. Then maybe you send some more. Eventually you stop and flip buffers (double, triple or as many as you like), and if you limit yourself to the possibilities of tilemaps, then you certainly manage it all between one vsync period and the next. Or, if you liked, you could write to the frame buffer directly.

On the GameBoy Advance, you either get no help with the display at all, in a frame buffer mode, or you get hard wired tilemap modes, which can only be used for that purpose, and for which there is a single static sprite list in memory, but with restrictions such as no more than 8 sprites per scanline, and sprites are always drawn in reverse list order. The 8 that are drawn are the first to be found in the list. Luckily the GBA gets away with it by having a really excellent CPU which can very much 'do the business' in the frame buffer mode, but the actual 2d hardware is a pathetic joke. If you don't believe me, notice the way people say the 2d is about the same as the SNES, but the SNES was designed up until the very last minute to be NES compatible, so is highly based on that hardware, and that hardware was designed to be nothing but super cheap. There isn't a RAM chip in the box.

Notice that the Lynx is still the only handheld that can accelerate polygon drawing, as a result of its sprite functionality being so open. I won't go into the details though, since they aren't really relevant . . .