MAP Format (Dark Legions)
The strategic maps for Dark Legions are uncompressed and always store the maximal amount of data possible, thus they take up exactly 16,012 bytes each. They are stored in the MAPS subdirectory and use the extension .MAP. There are also some .AMP files which use this format, but they appear to be leftover development cruft that was not removed before the game's release and appear not to be read or needed by the game.
New .MAP files can simply be added to the MAPS directory and the game will read them without the need for other adjustments. It is of course possible that the map menu has a maximum array size and could experience errors if this number of files is exceeded; this should be researched.
|0x0008||100x100 array of UINT8||Tile array (column-major)|
|0x2718||UINT32LE||Valid object count|
|0x271C||Array of 1000 objects||See below|
Since the tile array is column-major, the first 100 bytes of the tile array define the top left to bottom left of the map (including void space padding as needed if the effective map size is smaller than the maximum allotted space).
The tileset used by these maps is stored in the SKTILE??.GIF files as ordinary .GIF images (GIF87a version). Each of these files is a 7x7 collection of 44x28 tiles. The tile values correspond to graphics in a row-major manner, with the files arrayed vertically as it were, so that tile 0x07 corresponds to the tile at position x0, y1 in SKTILE01.GIF, 0x31 corresponds to x0, y0 in SKTILE02.GIF, etc.
Every object is defined by three properties:
The first "object" in the object list is not a scenery object. The data it contains varies from map to map, but its purpose (if any) is not yet clear - possibly setting the initial boundaries of players' territory?
Object types 0x00 to 0x05 are trees, 0x06 to 0x0B are rocks, and 0x0C to 0x10 are burnt trees. 0x11 and above can also be used; they use non-scenery sprites (such as unit sprites) but behave as if they were scenery objects, so may confuse players if used.
The scenery sprites are stored in ALLFB.DAC, starting at sprite number 90 (zero-inclusive) and continuing in the same order as the map object type values. It appears that object type values that would go past the end of ALLFB.DAC's sprite set wrap around to the beginning of the set instead of causing an error.