- Offset Size Type Meaning
- Header:
- 0x0000 4 int Number of glyphs in file. Designated as num below
- Caution: Some glyphs may be absent.
- 0x0004 4 int Font height in pixels
- 0x0008 4 int Distance between two neighbored glyphs in pixels.
- 0x000C 4 FontInfo* Pointer to symbol descriptions array
- 0x0010 4 unsigned char* Pointer to symbol images array
- Caution: These two fields are not defined in actual file and are filled in memory.
- Symbol description array:
- 0x0014 4 int Width of glyph 0
- 0x0018 4 int Position of glyph 0
- 0x001! 4 int Width of glyph 1
- 0x0020 4 int Position of glyph 1
- ... ... ... ...
- 0x0014 + 8 * num 1 unsigned char Glyph image data
Show whole topic
Sep 29, 2008 8:07 am
Sep 29, 2008 8:07 am
Subject: Re: max file formats
Here are the details in english:
max.res file basis and image formats:
The basic scheme is map header, followed by two maps - passage map and resource map.
Then, four records about four respective players.
That ends the static part of the file, starting a dynamic part.
In the dynamic part there are objects, identified by a word-sized object id, the format is somewhat cryptic in terms of generation, but quite straight-forward in reading.
At the start of dynamic part is a set of unit parameters descriptions for 4 players, one by one, averagely 32 bytes per unit - 2 for object id, 30 for info. If id is 0 or a repeat, then the record (30 bytes part) is empty.
After descriptions there goes unit positions and dynamics table, in similar format of object id followed by info. There are also size-looking bytes in the middle of the stream whose origin i don't understand yet, but they are detectable. The units dynamics are in no way fixed format, and still have blind spots.
After unit dynamics there goes some rather cryptic piece, having something to do with units, or maybe storage, then goes the scan maps and event log&statistics, latter undecoded completely.
I can give you the approximate schemes for the static part - the header and maps are 100% clear, the player infos have blind spots in less important parts, but dynamic part algorithms are better to be left for until they will be more certain.
Quote by shaktazuki:
Right, the program there seems to work nicely, althrough the result is less than i expected - just a bitmap font?I did find .FON file info - here: http://www.teamx.ru/rus/bd/fon_format.shtml , but it is in russian and therefore not very understandable to me - I would love an english translation of that and the RES file format, if you would.
Here are the details in english:
DownloadSource code (Text):
I hope the code fills the rest.max.res file basis and image formats:
DownloadSource code (Text):
...More to come later...- max.res
- Header:
- Offset Length Description
- 0 4 `RES0` - File ID
- 4 4 Directory offset
- 8 4 Directory length
- Directory consists of a sequence of file elements:
- Offset Length Description
- 0 8 ASCII File name trimmed by 0's
- 8 4 File start offset
- 12 4 File size
- --------------------------
- Simple palette graphics file
- (max.res:\a_*; max.res:\p_*; max.res:\e_*; max.res:\endgame*; etc)
- Header:
- Offset Length Description
- 0 4 Undefined, commonly 0
- 4 2 Image width in pixels
- 6 2 Image height in pixels
- 8 768 Image pallette
- Followed by compressed data in form:
- SWORD - byte count
- If negative, repeat next byte WORD times
- If positive, copy next WORD of bytes
Quote by shaktazuki:
I also am interested in whatever you know about the savegame file format. I was hex editing a DTA file today and noticed that it had at least two separate map save states - I could tell because the data section lengths were 112*112, and 2*112*112 - I assume one is for resources, and the other for units, but I don't know.
Quote by Sal:
It's an order of magnitude more complex than that.looks better in the doc file ...
http://www.zshare.net/download/19605201885d7382/
The basic scheme is map header, followed by two maps - passage map and resource map.
Then, four records about four respective players.
That ends the static part of the file, starting a dynamic part.
In the dynamic part there are objects, identified by a word-sized object id, the format is somewhat cryptic in terms of generation, but quite straight-forward in reading.
At the start of dynamic part is a set of unit parameters descriptions for 4 players, one by one, averagely 32 bytes per unit - 2 for object id, 30 for info. If id is 0 or a repeat, then the record (30 bytes part) is empty.
After descriptions there goes unit positions and dynamics table, in similar format of object id followed by info. There are also size-looking bytes in the middle of the stream whose origin i don't understand yet, but they are detectable. The units dynamics are in no way fixed format, and still have blind spots.
After unit dynamics there goes some rather cryptic piece, having something to do with units, or maybe storage, then goes the scan maps and event log&statistics, latter undecoded completely.
I can give you the approximate schemes for the static part - the header and maps are 100% clear, the player infos have blind spots in less important parts, but dynamic part algorithms are better to be left for until they will be more certain.
Artyom Litvinovich