Dune 2000 Font

From ModdingWiki
Jump to navigation Jump to search
Dune 2000 Font
There is no image of a font in this format — upload one!
Format typeFont
Max glyph count255 + space (width only)
Minimum glyph size (pixels)0×0
Maximum glyph size (pixels)2147483647×2147483647 (space symbol: 255×0)
Access modeSequential
Bitmap glyphs?Yes
Vector glyphs?No
Compressed glyphs?No
Hidden data?No

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 mechanisms 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.

File format

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.


Offset Data type Name Description
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 displaying 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.
0x05 UINT8 Unused05 Unused (0x00)
0x06 UINT8 Unused06 Unused (0x00)
0x07 UINT8 Unused07 Unused (0x00)
0x08 UINT32LE[0x100] DataOffsets Leftover memory dump. Ignore. This space might be used by the game to store the address for each symbol after loading the font into memory.

Image data

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.

Offset Data type Name Description
0x00 INT32LE SymbolWidth Symbol width.
0x04 INT32LE SymbolHeight Symbol height.
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 0×0 pixels entry 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 start symbol and 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 PlatformView images in this format? Convert/export to another file/format? Import from another file/format? Access hidden data? Edit metadata? Notes
Westwood Font Editor WindowsYesYesYesN/AN/A
Engie File Converter WindowsYesYesYesN/AN/A Was added to Engie to allow creation of font sheets.