in reply to OT: Tile maps

Here's a simple way to do it:

Chunk your world into fairly big blocks, call 'em "areas". Each area has a tile palette of 256 (or however many) tiles. (This way, you get a simple form of compression: each area probably has fairly similar graphics, and you only have to keep a few of your tiles in memory at once.) Store nine areas in memory at once: the one your player's in, and the eight adjacent areas.

On disk, store your areas the obvious way, as well as a map of which areas go where. When your player gets crosses the boundary of his current area, move him to the next one, shift which areas are which (bottom-left, centre, etc), and load the new areas when you have time.

This makes it easy to add areas to the world, gives you seamless transitions, lets you do all kinds of crazy image-processing stuff on the areas later if you so desire, and it's pretty simple to implement.

--
F o x t r o t U n i f o r m
Found a typo in this node? /msg me
The hell with paco, vote for Erudil!

Replies are listed 'Best First'.
Re: Re: (OT) Tile maps
by BUU (Prior) on Feb 14, 2003 at 05:45 UTC
    That sounds like a very practical way to implement this. I have a few questions however:
    1. What about those fun little border cases, where the character is say, right in the middle of 4 different 'areas'?
    2. Are the areas actually stored as giant jpgs or what not, or just a reference saying 'these 3 thingies make up an area'?
    3. "as well as a map of which areas go where" How the bloody heck do I do this?!
[reply]
        What about those fun little border cases, where the character is say, right in the middle of 4 different 'areas'?

      Well, you have access to the areas, so you can draw the intersections fairly easily. If you have something like:

      1111222222
1111222222
3333*44444 <- player is *
3333444444
3333444444

      [download]

      it's just a matter of drawing the eight tiles for area 1, the ten tiles for area 2, and so on, with the right offsets. And since the areas are stored as arrays of tile indices (which, in OpenGL, are probably just texture names), rendering them is bloody easy (quads come to mind).

        Are the areas actually stored as giant jpgs or what not, or just a reference saying 'these 3 thingies make up an area'?

      I'd thought of the areas as n by n arrays of OpenGL texture names. Every time you have to draw them, you translate to the area's origin, then just iterate through the array: if a cell's visible, draw a quad with that texture.

        "as well as a map of which areas go where" How the bloody heck do I do this?!

      Well, you could use XML... ;-)

      Seriously, it's probably easiest to have some notion of a grid, with one particular area associated with each coordinate. (This lets you reuse stuff, too: sort of like the tile grid for areas writ large.) So, you might have a text file that looks like:

      0,0:plains.buu
0,1:plains.buu
0,2:rocks.buu
0,3:city_foobar.buu
...

      [download]

      Probably best to manipulate it with some sort of purpose-built tool (Perl/Tk springs to mind) rather than by hand, but you could create, say, a 4x4 test world by hand pretty easily.

      You might find FlipCode and GameDev.net helpful, especially the fora.

      --
      F o x t r o t U n i f o r m
      Found a typo in this node? /msg me
      The hell with paco, vote for Erudil!

[reply]
[d/l]
[select]

In Section Meditations