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
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).
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.
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 ...
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!
In reply to Re(3): (OT) Tile maps
by FoxtrotUniform
in thread OT: Tile maps
by BUU
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |