Dune 2000 Font
The font used in Dune 2000 is an 8-bpp font with individual widths and heights per symbol. It seems to contain a lot of mechanism meant for optimizing, but the final format doesn't seem to use any of them as they were intended, resulting in a contrived format with a needlessly bloated header.
Despite the fact Dune 2000 is officially a Westwood Studios game, this font is not a new version of the Westwood Studios font format. In reality, the game was outsourced, and this format is designed by Intelligent Games, the real creator of the game.
Note that Dune 2000 is not a DOS game. This font format is included on this wiki for the sake of completeness in the scope of documenting all indexed graphics formats in the Westwood Studios games.
The format is a bit of a mess; while it saves the width of the space character instead of its image data, and has a start symbol and a way of compacting the used symbol codes, it has no way to set the amount of used symbols, making all that optimisation completely irrelevant. Instead, it always contains 256 symbols, starting at index 0x21, just after the space character, wrapping around to zero after 0xFF, and going back up to 0x20 after that. This final symbol for index 0x20 should be ignored, and should be replaced by a space character generated from the width in the header. The header is also polluted with a dump of 256 completely irrelevant 32-bit memory addresses, which are probably leftovers of the saving process.
These specifications were originally researched by Roman "Siberian GRemlin" Lotchenov.
|0x00||UINT8||FontLoadedFlag||Always 0x01. Siberian_GRemlin's analysis marked this as "Must be $00", but the actual files contradict that.|
|0x01||UINT8||SpaceWidth||Width of the space character, in pixels. Strangely enough, this is a single byte, while the sizes of the other symbols are defined as 32-bit integers.|
|0x02||UINT8||FirstSymbol||Always 0x21; start after the space. Given the fact the space is specifically saved in the header, is it probably not a good idea to change this, since this may determine which symbol gets generated from the space width instead of from the font's image data.|
|0x03||UINT8||Padding||Amount of pixels to add between each symbol when printing it.|
|0x04||UINT8||FontHeight||Overall font height, in pixels. This also seems to serve as maximum for the symbol heights, but it is unknown if the game enforces that in any way.|
|0x08||UINT32LE[0x100]||DataOffsets||Leftover memory dump. Ignore.|
The image data starts at offset 0x408, and is an array of 256 structs containing the width, height and image data of each symbol. Given the variable size of the images, and the lack of index, this array can only be read sequentially.
|0x08||BYTE[SymbolWidth * SymbolHeight]||SymbolData||Symbol data.|
As noted before, these start at
FirstSymbol (which should be 0x21), and wrap around to 0 after reaching 0xFF. Given the symbol code compacting detailed in the next section, the sanest way to read these is probably indeed to apply the wraparound and order the symbols correctly.
Note that the data contains 256 entries; there is in fact a final entry in there for the space, but it should be a 0x0 block without symbol data. This entry should be ignored, since the real space is only defined by the
SpaceWidth in the header.
Symbol code compacting
An important note when editing this format is that the symbol codes do not correspond to any known text encoding. They are in fact a compacted version of Windows-1252 encoding, which uses an external mapping file to look up the actual index in the font data. These mappings can be found in FONT.BIN, which is located in the game's Data\BIN\ folder.
FONT.BIN is a very simple 0x100-byte remap file. If you want to find, for example, the symbol "é", which has symbol code 0xE9 in the Windows-1252 encoding, you look at the offset 0xE9 in FONT.BIN, and will see that the value there is 0x8D, meaning the "é" character in the font file is on the location indicated by code 0x8D (with the aforementioned wraparound taken into account). Any unsupported symbols in the file are mapped to the space character (0x20). This also means that, to add new symbols into the font, this mapping table needs to be edited, otherwise the newly added symbols will never be used by the game.
In the Westwood Font Editor, the mapping problem is remedied by adding the default FONT.BIN mapping as specific "Dune 2000" choice in the text encodings list. However, to properly edit the fonts and unlock all characters, the whole system could be disabled simply by replacing FONT.BIN by a file with bytes ranging from 0x00 to 0xFF, and rearranging the symbols in the fonts themselves to match normal Windows-1252. Nyerguds released a small pack on his website containing the adapted mapping table and fonts.
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||N/A||N/A|
|Engie File Converter||Windows||Yes||Yes||Yes||No||N/A||Was added to Engie to allow creation of font sheets.|