I’m going to be working on a tile engine soon (2D) and am just
currently working on the parser. Got that working well last night. Next
step is to get it tiling (Using SDL of course).
Here are my plans with tons of holes in it, because I have never done
this before, and don’t have anything set in stone yet.
I just plan on creating a class called TILE,
Problem 1: Be careful not to put frequently used virtual members it that
class. Too much of that on the once-per-tile level can quickly impact
total performance.
(BTW, you should probably name it tile_t, CTile or something as "TILE"
looks like a #define rather than a type… Either way, be concistent
throughout your code! It helps. 
and while I’m reading the
file, I will just call a constructor which defines the tile. Then I
will add it to my linked list.
Problem 2: A linked list is probably fine for a lot of tasks, but for
real time rendering, you’ll probably need some secondary structure to
look tiles up. (Unless you’re using a small map and/or huge tiles, you’ll
have to extract and render only the tiles currently visible - just
plowing throught the whole map won’t work.)
For simple, single layer maps, a 2D array is usually the easiest and best
way to go. For maps with multiple layers, mixed size tiles, detail
sprites etc, you can either extend the basic 2D array approach into a
zone based map (hook a linked list of tiles and sprites to each "tile"
location on the map), or you can switch to some multidimensional tree
structure.
First line in my file format is the name of the tileset file I’m using.
tileset.bmp
And the rest of the file is where I load tiles, events, etc…
So it’s actually not just a plain map file, but a complete “level
definition”…?
So inside my file I define a tile like so:
tile:
0
0
32
32
Format is not set in stone, but the 1st and 2nd numbers are the x,y
locations on the screen 3rd and 4th are the x,y locations in the
tileset.bmp file.
IMHO - as there doesn’t seem to be a way of specifying tile size - it’s
much more convenient to address tiles using tile indices rather than
explicit tile coordinates. (I usually hack up some code that
automatically chops up an input image into a linear array of tiles. See
Kobo Deluxe for an example.)
As to the “screen coordinates” (I’d rather think about them as “map
coordinates”), are they in pixels or tiles? (If they’re in pixels, I can
see the point in your format. If not, I think a simple, traditional array
of tile indices would be sufficient.)
[…]
This should all be taking place inside the WORLD class which has
functions like LoadMap();
And I will have a linked list containing all the tiles so I can do
various stuff to it, like remove it, check values, or something of the
such.
Then I can have a draw function inside the tile class, things are
endless after that. Of course I have never done this before, but this
is my idea as of late.
Sounds like a reasonable design idea. The only parts I’m in doubt about
are the internal structure of the loaded map data, and the map file
format. Your design would work, but you’ll have to add some info to
avoid performance issues with large maps. I don’t quite get why you want
"tile palette" coordinates in the map data - but it would work all
right. (In fact, XKobo/Kobo Deluxe used to address tiles and sprites like
that, until I integrated it with the tile/sprite loader from Project
Spitfire.)
//David Olofson — Programmer, Reologica Instruments AB
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Tuesday 29 January 2002 02:42, Bryan Arant wrote:
]-----------------------------------------