Every call to writing a 32-bit integer increases the file size by 4 bytes. So your file size will be w * h * 4 (assuming you write one integer per cell). I'm not sure where you are storing the dimensions right now, but a file size of 16 "blocks" (i.e., one block = 4 bytes in this example) could be 4x4 or 8x2 or 16x1, etc. That is, you cannot deduce the width and height by only the total size.

Regardless of that, I would generally store the dimensions at the beginning.

Thanks alot, That's definately enough for me to get this working. I guess If someone where to use it. I'd include a readme to tell them exactly how the files are made and how to access the information. So the first two blocks identifying the width/height wouldn't be much of an issue.

ident is a unique string (in this case, TMAP), that can be used to identify that a file being read is of the correct type. width and height are pretty self-explanatory. The number of tiles doesn't really need to be stored, since it can be easily calculated from the width and height, but I like to store it anyway. To increase the flexibility of the format, I store the number of bytes per tile. If a map has simple needs, a single char per tile may do, for complicated maps with layers, and many different tiles, each record could take up several bytes. tile_data_length will be equal to num_tiles * bytes_per_tile but I again store it for use later. tile_data_offset stores the location in the file where the tile data starts. This means we can add any amount of extra comments or data between the header and the tile data if we want to later.

You can check the sizes as you load it like this (test map using one byte per tile):

Thanks Lenny, That looks very useful. Right now though the program isn't going to know in advance what sizes of files to expect. It's just for loading any file that was created by the same program. That looks like a solid system though. And once I start making maps I intend to use I'll probly come back and snag this code.

I could have just mis-understood something, but it seems to me like that sort of system is used after you've made a file, to make certain you're loading the correct data from it.

Something else I always add to my map header is a version number. So if you modify your map data in the future, you can update the version number so that old maps that were made using the old structure aren't loaded. You could also easily create a converter to convert your maps from the old version to the new one (something I done a couple times with my Deluxe Pacman game). So basically I had the header + version number as the first two pieces of data.