Subject: Re: max file formats
Quote by shaktazuki: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.
Right, the program there seems to work nicely, althrough the result is less than i expected - just a bitmap font?
Here are the details in english:
DownloadSource code (Text):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
I hope the code fills the rest.
max.res file basis and image formats:
DownloadSource code (Text):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
...More to come later...
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.
It's an order of magnitude more complex than that.
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
Start
Forum
Members
About
FAQ
Downloads
Development
Links
License
Search
Important Tools
Misc. links Active topics... Newsfeeds (RSS, ...)
Log in
Printer friendly version