The MAZZTer
Death Star
Joined: 25 Sep 2003
|
 Posted: Jul 18, 2009 20:59 Post subject: Inaccuracies in DF SPECS |
    |
|
I discovered some inaccuracies in the DF Specs while coding my image/palette formats library:
First of all since the document is a bit old, keep in mind ints are 16-bit numbers. This isn't an error as such since if you compile C code for a 16-bit platform ints will be 16-bits in size. However we use 32-bit or 64-bit computers nowadays so it could be confusing to programmers who are used to working with 32-bit ints.
Also VB coders should note that C longs (used in DF SPECS) are not the same as VB longs. C longs are 32-bit while VB longs are 64-bit (the C equivilant is longlong).
BM files:
The "BM Multiple" article has some unlabelled fields in the first header, giving the impression they are unused. However, these fields are usually filled in, probably with the values from the first image.
FNT files:
There is a "DataSize" field which the specs say is the length of the data following the header. In fact, this field seems to be always 0x202 regardless of the length of the data.
DELT files:
The RLE compression section is a bit difficult to understand and took me a while to figure out. While the RLE compression of BMs and FMEs uses the Most Significant Bit of the count byte to indicate whether the following bytes are compressed or not, DELTs use the Least Significant Bit.
For example, here is the example from "BM Compressed" modifed for DELTs:
| Code: | while(we haven't decoded the number of pixels indicated in sizeandtype)
{
if(buffer[address] & 1)
the FOLLOWING n / 2 bytes are direct values
else
the FOLLOWING byte is a color byte to repeat n / 2 times
} |
In addition, you should not look for the EOF while reading DELT_Lines to determine if you've read all the lines. Instead, when you read the next SizeAndType, if the Size is 0 (IE SizeAndType is 0 or 1) then you've reached the end of the file and can stop. Similarly, you should output a short int 0 when you have finished writing all your DELT_Lines to a file.
[Edit: FONT Files:
The documents say there are only two FONT resources in Dark Forces: font6 and font8. That's not true. These two are in STANDARD.LFD but there is another font8 in MENU.LFD which is different in file size and content.
Last is NOT the last character! It is the NUMBER of characters in the FONT resource!
u1 is indeed the number of bits per character line. It appears to always be a multiple of 8, possibly because of the difficulty of reading/writing individual bits as opposed to standard byte-aligned data.
The standard/font8 font has 0x10 (16) defined for it and so you must read two bytes per line. (One character is 9 pixels wide... character 126 is a TM symbol. In the menu/font8 font it is a less-wide ^ character and now everything fits inside a byte.)]
[Edit 2: WAX files:
It looks like SEQUENCE pointers possibly aren't absolute file positions like the others. The SEQ structure shows 4 unknown longs, but in practice these seem to be data from previous structures! (Though I did use user-created WAXs in my investigations.) For reading files in you may want to increment all SEQUENCE pointers by 0x10 and skip those fields entirely. For writing files you may also want to write out a pointer that's 0x10 less than the actual data and write a SEQUENCE without the 4 longs. But I will look at some official WAXs first to see if this is valid.]
[Edit 3: DEFAULT.WAX has a Version of 0x00000100 which does not match other files. The file format appears the same (will investigate further).]
[Edit 4: The version in the specs as well as the one above are only valid when reading individual bytes, or when reading using a Big Endian architecture. However all values are stored Little Endian so the proper value when reading versions as long int is:
0x00011000
and for DEFAULT.WAX:
0x00010000
These seem to be 1.1 and 1.0 version numbers.]
[Edit 5: WAX version 1.0 seems to be identical to 1.1. ]
_________________
http://www.mzzt.net/ | I am a respectable admin with a respectable sig. |
|
