Dynamix Font Format v4-v5
Format type | Font |
---|---|
Max glyph count | 255 |
Minimum glyph size (pixels) | 0×0 |
Maximum glyph size (pixels) | 255×255 |
Access mode | Indexed |
Metadata? | None |
Bitmap glyphs? | Yes |
Vector glyphs? | No |
Compressed glyphs? | Yes |
Hidden data? | Yes |
Games | Red Baron (v4)
Rise of the Dragon (v4)
Heart of China (v4)
Betrayal at Krondor (v4 and v5)
Stellar 7 (v4)
Front Page Sports Football (v4 and v5)
Front Page Sports Football Pro (v4 and v5) |
The Dynamix v4 font is a 1-bpp indexed font, with the file header specifying the global height for all symbols and the amount of symbols. Like its predecessor, the Dynamix v2/v3 font, it is optimized by only saving the used range of symbols. New features added after v3 include compression support and separate width values for all symbols.
The v5 font is identical, except that it stores 8-bit data instead of 1-bit data. It is distinguished with a different version byte in the header.
Format
The font is embedded in a "FNT" chunk of the typical Dynamix chunk format: a 3-character ID string, followed by a ':', followed by the chunk size in UINT32LE format, in which the highest bit is reserved for a flag indicating whether the chunk embeds chunks inside itself (which this "FNT" one does not), followed by the chunk data. The following descriptions cover the data format inside the FNT chunk, so any offsets are relative to the start of the chunk data, behind this header.
File header
Offset | Data type | Name | Description |
---|---|---|---|
0x00 | UINT8 | Version | Version indicator. 0xFF for the one bit per pixel version, 0xFD for the eight bit per pixel version. |
0x01 | UINT8 | FontWidth | Maximum width of the font in pixels. |
0x02 | UINT8 | FontHeight | Height of the font in pixels. |
0x03 | UINT8 | BaseLine | This appears to indicate the Y-offset of the base line of the font. It generally corresponds to the most commonly used lowest pixel Y-position in the symbols, but can be different if the font has a dropped shadow, which is a common feature in v5 fonts. |
0x04 | UINT8 | StartSymbol | First symbol code in the font file. |
0x05 | UINT8 | NrOfSymbols | Number of symbols in the font file. Since this is a byte, the font is limited to a maximum of only 255 symbols, and not the full 256. However, since C-style strings end with byte 0x00, index 0 is technically useless, and can be skipped to get the full real range. |
0x06 | UINT16LE | SymbolDataSize | Size of the (uncompressed) symbol data block. |
0x08 | UINT8 | CompressionMethod | ID of the used compression algorithm. See below. |
0x09 | UINT32LE | UncompressedSize | Size of the buffer needed to uncompress the data. This should always match SymbolDataSize. |
Compression
The following compression types are supported by the format:
- 0x00: Uncompressed
- 0x01: Code-based RLE with 1-byte codes. If the highest bit in a code is set, this indicates a Repeat command. The remaining 7 bits specify the amount to copy or repeat.
- 0x02: LZW. The actual LZW implementation is an adaptive LZW with expanding dictionary size. Decompression code for it is available in a set of MIDI tools released by user tikalat on the VOGONS forum.
- 0x03: Huffman compression. Decompression code is available in the aforementioned MIDI tools. Note that Huffman was only introduced in later games, so using Huffman-compressed fonts may not work on some earlier games.
Symbol data
This header is followed by the symbol data block, compressed in one of the three known compression methods. After the symbol data is uncompressed, it starts with the offsets and widths data:
Data type | Name | Description |
---|---|---|
UINT16LE[NrOfSymbols] | offsets | Offsets of the data for each symbol, relative to the start of the uncompressed block. |
UINT8[NrOfSymbols] | widths | Width of the individual symbols, in pixels. |
Behind this, the font file symbols data can be found, using the offset from offsets
, the width from widths
, and the global FontHeight
. The formula to convert the width to the stride (the actual byte length of a line of pixels) is ((width * BitsPerPixel) + 7) / 8
.
Since this data is referenced through an index, the same optimisation technique used in the Westwood Studios v3 font could be applied to it; when multiple symbols have identical image data, the data could be stored only once, and the index positions for these symbols can then point to the same data. This technique is not used by any of the original font files, but the games accept it without issues, since they just follow the references in the index. The Westwood Font Editor allows saving the fonts with this optimisation.
Tools
The following tools are able to work with files in this format.
Name | Platform | View images in this format? | Convert/export to another file/format? | Import from another file/format? | Access hidden data? | Edit metadata? | Notes |
---|---|---|---|---|---|---|---|
Westwood Font Editor | Windows | Yes | Yes | Yes | No | N/A | Can read the LZW and Huffman compression types, but can't write them. |
- All file formats
- All font formats
- Bitmap fonts
- Compressed fonts
- Sparse fonts
- Indexed fonts
- Red Baron
- Rise of the Dragon
- Heart of China
- The Adventures of Willy Beamish
- Betrayal at Krondor
- A-10 Tank Killer v1.5
- Stellar 7
- Nova 9: The Return of Gir Draxon
- The Incredible Machine
- Sid & Al's Incredible Toons
- Front Page Sports Football
- Front Page Sports Football Pro
- Sierra/Dynamix File Formats