Well, you didn't really tell us how you do it, so ... I don't know.

Yeah...but I'm the kind of guy who gets real giddy when some new information clicks. I've been told I was grinning and wringing my hands when I first read about classes and inheritance and polymorphism. (also, I'm a sucker for tiny file sizes, having had dial-up until a few years ago)

By the way, with the storage stuff, I'm getting super-crazy-amazing compression when the binary file gets big. A 5000 tile by 5000 tile map is ~3MB, and is compressed down to 90K when I stick it in a .rar...is that normal with raw binary files?

The old way that I was rendering the tilemap was to check each tile to see if it was within view. I'd done a lot of maps that way, and never noticed an issue. (even though it may seem totally ridiculous now)

But my new way gets ~460fps at 640 by 480 on my old clunker-box!

(also, a 5000 tile by 5000 tile map takes up 512MB of RAM on it's own. Any suggestions on having tiles take up less space?)

[edit] Sorry... 'my new way' = Finding the tile that (cam_x, cam_y) is over (this would be the top left corner of the 'viewport' (or whatever). Then just go through and draw the next n tiles in the vector (where n = SCREEN_W/TILESIZE)... When that row's done, drop down and draw the next one the same way, until the distance down from the first tile = SCREEN_H/TILESIZE.

[edit] Here's the function:

void draw_map(BITMAP *bmp)
{
  short _x = cam_x/TILESIZE;
  short _y = cam_y/TILESIZE;

  if(_y <= 0) _y = 1;
  if(_x <= 0) _x = 1;

  for(short ry = 0 ; ry < SCREEN_H/TILESIZE + TILESIZE ; ry++)
    for(short rx = 0 ; rx < SCREEN_W/TILESIZE + TILESIZE ; rx++)
      vTile[(MAPWIDTH * (_y+ry)) - (MAPWIDTH - (_x+rx)) - 1]->draw(bmp);

}

That '(MAPWIDTH * (_y+ry)) - (MAPWIDTH - (_x+rx))' is the juicy little jewel that I sat and worked out myself...that's the bit that makes me giddy. (that, and finally realizing that all I needed to save for any of my first-layer-tiles was a single char for 'type')

I think that's the 'normal' way of doing it. A lot of the old tilemap hardware (i.e. the NES, Master System, etc) has a video buffer to which you can only store just enough tiles to cover the screen. Then you have to shuffle contents in from your real tilemap as the game progresses to show other bits of the level.

Oh, I didn't mean it like that! I meant that you've independently figured out the fastest method. Which is obviously a very good thing.

Aw maaan...

So I guess what I need to work on at the moment is the size of my map files, and the amount of RAM it takes to store a tile... I'm real happy with storing a single char for each first-layer tile, but that only works because there has to be a tile in every space. In higher-level tiles, I'll have to store the position, too...

For some reason, I was under the impression that a bool was a single bit... My idea for storing position, then, was to have a maximum map size of 500x500 and use two chars for position, rather than two shorts. Then I'd have a bool right after each char, and if it's set to true, add 255 to the char to get the real position...that'd have me storing...3 bytes + 2 bits per tile, rather than 5 bytes...which, I guess, wouldn't help too much, even if I could store a single bit...plus, doesn't the OS round bits up into bytes for storage?

But the RAM usage bothers me more than the file size. ~500MB isn't cool, man...and I'm going to end up having more information in the tile class, too... Is the RAM used equal to the size of all the variables belonging to the object? Or is there more?

I'm going to assume you're talking about my effort to squeeze an extra 14 bits of storage space out of my tiles... Yeah...a little crazy... But like I said, I have a thing for tiny files. That's why I've generally avoided tilemap stuff - they usually require a lot of media to be included with a program. I'd feel terrible releasing anything more hefty than Chrono Trigger (excluding audio...I'd end up releasing a 4MB version with MIDIs, and a 498MB version, with totally uncompressed wavs...I'm a total nutjob).

Yeah, it seems like there was a lot of empty space in the Rockman games... But I'm planning this for use with a console-style RPG.

Yeah, I just recently got UPX, and it's awesome. Killer for someone like me.

I've done a couple little games, and lots and lots of small programs that do a single interesting or useful thing... Kinda writing example code for myself as I learn...

I think the only wall I've got in front of me now is scripting. Totally uncharted territory for me.

On a lighter note: I'm not planning on making a whole game (of this size) by myself... My plan is to develop the 'engine' as much as I can without media (this 'engine' includes external tools, like a map editor, or an NPC editor), and then try and get someone (a couple people?) willing to do sprites/tiles, before I try and make a game - which I see as totally separate from what I'm doing now. In my case, making the game should just involve scripting, a bit of imagination and maybe tweaking the technology, if I do a crap job the first time 'round.

[P.S.]Ha! I thought of a better way to store higher-layer tiles! Since there's no reason to store them in their order on the grid, I can store them by type. For the higher layers I can store tiles like this: type1:xyxyxyxyxyxyxyxyxyxyxyxyxyxyxy, type4:xyxyxyxyxyxyxyxyxyxyxyxyxyxyxyxyxy, etc. Awesome.

I think he referred to layers where there's a lot of blank space. In this case, yes it can take less space. However, good luck checking for collisions. (and editing levels)

Yeah... That does bring up a good point though, Audric...every time I've needed to do something based on the position of the tile, I've taken advantage of the fact that my map is filled left-to-right, and top-to-bottom - and the fact that every slot is filled. I definitely don't think it's a good idea to fill the tile vector up with NULL tiles, either... I've been thinking about writing a function like tile_at(x, y, layer) that would just return the number (to be used with my vector) of the tile at that position on the specified layer. It'd be easy for first layer, but again, slow for any higher layers, unless I fill the empty spaces with filler tiles...

I'm not sure it's going to be that sparse...like...the second layer would be for things like furniture, walls, hills, tree trunks... In a town or village, I could see the higher layers being 30-40% filled.

Doing things that way sounds like it'd work...but then I'd need some separator between tiles, right? That's another char for every tile. That kinda worries me... I guess it'd still be smaller than making whole new layers that're 60% NULL tiles in my vector. Would there be any problems (extra RAM usage?) with having all those different vectors? As many as 1,000,000 per map?

No you don't. No current hardware can render 460 frames per second. In case it's really an old clunker box, the screen's vertical retrace rate is probably set to something in the <100Hz range, so that's the maximum number of frames your game will ever produce, no matter what you do.

About the file compressing so well: That doesn't surprise me too much, considering you probably used a sample map with mostly empty tiles (or at least, large regions with the same value). Since RAR uses some kind of dictionary algorithm, this kind of obviously redundant data compresses extremely well. Just test it on bitmaps: Make one .bmp file that is completely white (or any other color you fancy, say, pink), and another one that is filled with random color noise. Compare the compressed results and you'll see what I mean.

About the general format of your tilemaps: If you REALLY need such large maps, then you should consider using a more complex format (e.g. tilemaps where there are things to happen, leaving empty space between them; or work with "rooms" and portals connecting them), but for anything normal, just use a flat tilemap.

In the map file, a char per tile is enough if your map doesn't contain more than 255 different tiles; if the game features more possible tiles, but you don't use them all, you can use a tile list. This is basically what I'm using, since my actual tiles are polymorphic, and some feature procedural graphics; the file starts with a tile type list, after that comes the tile map which contains indices into the tile type list rather than actual tile values. This approach is also more flexible if you add more tiles later, or change your graphics, since sprites can be referenced by name without wasting much space (you only state the name once, no matter how often you use the tile).