OMSI Fonts

OMSI does not use standard computer fonts, instead using a proprietary bitmap font format.

OMSI Fonts are defined within font config files (.oft) which must be located directly within /Fonts/—you cannot put them in a subfolder! These config files contain two keywords: [newfont]—which defines the parameters that are common across the whole font; and [char]—which defines an individual character within a font. Fonts are referenced by their internal name, not by the name of the file they are defined in.

In addition to the font config file, the pixel data of the font is defined with two bitmap images which must be 24-bit uncompressed bitmaps. The first image supplies the three colour channels for the characters (which the user can opt to ignore and instead use a block colour of their choosing); the second image supplies the alpha channel for the characters (which should define the glyphs on its own if the font is to be used in block colour mode).

Each character is a rectangle within these images that is copied into a text- or script-texture when the single-byte character it is mapped to occurs in the input string (which is just a sequence of single-byte values)—if a byte in the input string doesn't map to any character in the font then the first character in the font is used. Text-textures also support newlines with the @ character (no vertical space is added between the rectangles so you will need to include the gap between lines within the font's height). You don't have to include a gap between characters within the characters' width—spacing columns will be skipped between each rectangle, although additional columns can be skipped when using the font with a script-texture.

Because the characters are copied into a destination texture the source images are never displayed which means you don't have to worry about their dimensions being power-of-two, or about texture bleed. You should still consider optimising their size as they are required to be uncompressed bitmaps—it is quite allowable for rectangles to overlap, and fonts that will always be used with a block colour can use the alpha image as their colour image to avoid loading another image into memory.

A final note to consider is that of character encoding—I recommend the use of Windows-1252 (which, as far as I'm aware, is the encoding of the default font config files) to avoid issues with characters being mapped incorrectly. This issue is only likely to be applicable to fonts containing non-ASCII characters, the creators of which should also be aware that OMSI fonts and strings are limited to single-byte encodings.