Dart Zaidyer
Faithful Project Janitor, retired
Overseer
Joined: 21 Jul 2002
Posts: 2572
Location: Free Country USA
|
Posted: Thu Jul 31, 2008 1:01 am Post subject: Specs of the Damasca Map format
|
|
  |
|
Diaftau was kind enough to provide the following explanation of the Damasca map format. This information ought to be useful for anyone capable of writing a map reader or importer for a new engine.
| Quote: | The best reference for the format would be to look at the map loader's source code, which is in:
damasca\src\app\Document\File\ChunkedMap.cs and
damasca\src\app\Document\File\ChunkedInputFile.cs
But anyway, here's a quick overview of the file format as I can see it now:
The default for map files was that they were compressed with 7z (if the file extension is .dampz that's the case, if it's .damp they're uncompressed). So the first step is to get the file decompressed. Unfortunately the compression header seems a bit non-standard so it may be simplest to save it in the editor as a .damp file to get a map decompressed, or take a look at:
damasca\src\app\Document\File\ChunkedMap7z.cs and
damasca\src\app\Document\File\SevenZipUtil.cs (in particular Damasca.Document.File.SevenZipUtil.DecompressFile which sets up the decoder properties)
Once decompressed, the map format itself however is straightforward. Note that all types are little-endian.
From the top:
byte[8] - ASCII encoded file type. Must be "CHNKMAP\0"
int32 - Version number. Currently 2.
From here there's a list of chunks, upto the end of the file. Each chunk is formatted like:
int32 - Tag id
int32 - Length of chunk data in bytes (length)
byte[] - Blob of data of 'length' bytes.
The list of chunks that are currently supported are:
Header (id 1)
Tileset Table (id 2)
Layer Header (id 3)
Layer Tile Block (id 4)
The header chunk must be the first chunk in the file.
Header
-------
For file versions less than 2:
int32 : Width and height of the map in pixels
For file versions greater than or equal to 2:
int32: Width of the map in pixels
int32: Height of the map in pixels
Tileset Table
-------------
The tileset table is a mapping between int16 tileset ids used in the layers and global tileset names (as they appear on disk).
int32 : Number of tilesets
Then for each tileset:
int16: Tileset id (reference in layer tile blocks)
int32: Length of the tileset name in bytes
byte[]: Tileset name, encoded in UTF-8. We probably didn't have any tilesets that used any characters outside of the ASCII range, so treating as an ASCII string will probably work out ok.
Layer Header
--------------
Always preceeds a layer tile block associated with the layer.
int32: Length of the layer name in bytes
byte[]: Layer name, encoded in UTF-8. As before, you will probably be able to get away with treating it as ASCII. (Although I recommend supporting UTF-8).
byte: Flag indicating whether the layer is visible or not. 0 if it is hidden, else it is visible
int32: Width of a tile on the layer, in pixels
int32: Height of a tile on the layer, in pixels
Layer tile block
---------------
Finally, the actual tile data!
int32: The index of the layer - starting from 0 (used to find it's associated header).
int32: The width of the layer in tiles (typically will be equal to the map width / layer's tile width)
int32: The height of the layer in tiles (typically will be equal to the map height / layer's tile height)
Each tile is stored as a tileset id (as specified in the tileset table) and a tile id (of a particular tile in the tileset). To improve compression, these are stored separately, so all the tileset ids first, then all the tile ids. Which leads to:
For each tile (layer width * layer height):
int16: The tileset id of the tile, as seen in the tileset table, or 0xffff for an invalid tileset (likely an empty tile - the tile id should also be 0xffff in this case).
For each tile again:
int16: The tile id of the tile, or 0xffff if it's empty.
Keep parsing chunks until the end of file is reached.
And from what I can see that should be it!
The other piece of the puzzle are the tilesets, but they're stored as xml, so I'm sure you've got them figured out already.
Does that help?
Olly. |
_________________
Remember: Friends don't let moons eat monkeys. |
|
