Openra: FNT font format support

[Mailaender]

The original games include their own fonts. See http://xhp.xwis.net/documents/ccfonts.txt for the file format. There are even editors for them: http://forums.cncnz.com/topic/8223-ra2yr-font-editor-released/

[Mailaender]

The Westwood Font Editor created by @Nyerguds might be a good source of inspiration.

[Nyerguds]

Well, I got c# code for converting the fonts to 8-bit paletted .Net images. Though they don't include Y-offset; the editor does that in UI. But the font class also contains code for expanding the image and shifting image data in all directions, so it'd just be a couple of lines of code to add it.

And it's released under WTFPL, so, go nuts with it.

Oh, and it supports D2K, too :)

[Nyerguds]

The editor has gotten a true preview function, meaning the font class actually has a function to generate text (as well as the full separate characters, including Y offset) as image now.

[chrisforbes]

What do we intend to use this for in the game? It seems a poor replacement for anywhere player names or chat may show up, as those need a much wider range of characters.

[pchote]

TS and D2K (to a lesser extent) used these fonts for ingame decorations ("Primary" building label, production icon labels, etc). The argument is that we should generate these using the original assets instead of making and shipping our own.

[Nyerguds]

Do note, the original D2K fonts have been found to contain some errors. In "FONTCOL.FNT", the double quote, hash sign and underscore symbols have errors, as well as the lowercase letter 'q'. Though since neither the colour fade nor the backdrop in that font seem to actually ever be used in the game, as far as I know, the font seems functionally identical to "FONT.FNT", which doesn't have these errors.

[Mailaender]

What do _we_ intend to use this for in the game?

Not just us. Nowadays we build OpenRA for the modding community and they are used to their tools and file formats. It would help make the migration to a modern and free engine easier for them.

I also thought about simply using http://www.dafont.com/de/c-c-red-alert-inet.font but it is legal trouble as it was copied from the original copyrighted FNT and then again with another copyright added on top of that (for the retrace) from @N3tRunn3r so essentially worseless for us.

This is related to https://github.com/OpenRA/OpenRA/issues/8264 but not really a blocker. There are more severe cases of IP trouble in this repository. See also https://bugzilla.redhat.com/show_bug.cgi?id=1159091#c16

[Nyerguds]

Some notes on Dune 2000:

• The .FPL file is a color palette, according to Siberian_GRemlin's info, but it doesn't seem to actually contain any useful colours. The existing fonts (both in TS and Dune 2000 in fact) only ever reference the first 16 colours anyway, and if Siberian_GRemlin's info is to be followed, that produces nothing but a bunch of identical blacks and identical blues in that file.
• There is an additional file called FONT.BIN, which is basically a remapping table for transforming text saved in Windows-1252 character encoding to the order of characters used in the actual Dune 2000 font files. My font editor contains a custom text encoding class to support this, which has the original FONT.BIN array stored internally. If you give characters to the encoding class, the resulting bytes you get will be the indices to use on the font. Give it font indices, and it'll return the corresponding characters. You will need this to use the Dune 2000 fonts, or at least to reorder their symbols to a more common encoding. Note that this system means that a character on the font is completely inaccessible if it doesn't get mapped in that remap table. The original FONT.BIN table maps all unsupported characters to the space character.

The goal for the Dune 2000 character reordering seems to be for optimization purposes, since all special characters were lined up without gaps in between, the stored data of the font starts behind the space character instead of at character #0, and the space character itself (0x20) is only stored as pixel width in the header. Any space between characters (which is included in the actual images in the WW fonts) is also just a header value in Dune 2000. My classes compensate for that, though; the additional width is added on load (and detected and trimmed off on save). However, seems that this optimizing effort was never really followed through; all characters behind the special ones are _still_ added anyway, even wrapping around to include all those below the space too, up to the full 255 characters (as I said, the space is not included as character), and on top of that, about a kilobyte of pure junk is dumped into the file's header. So yeah, somebody had some nice optimization ideas there, and somebody (else, probably) screwed that up big time somewhere along the way.

[Mailaender]

I made some progress on this https://github.com/Mailaender/OpenRA/tree/fnt The integration is hacky at the moment and I don't know how to apply the remap. Somehow the coloring is opaque and monochromatic.

[Nyerguds]

Just a side note; I wrote up full specs of all the font formats, including the D2K font, and the full Unicode range RA2 font, here:

http://www.shikadi.net/moddingwiki/Category:Westwood_Studios_File_Formats

The RA2 one is in the list as "BitFont" (specifically, "Westwood Unicode BitFont Format"), which was its internal name according to the Assembly Armada guys.

[pchote]

SpriteFont expects the IFont implementation to return an 8bit opacity map, which is coloured dynamically on the GPU using the vertex colours. This isn't going to be compatible with formats that define their own colours.

[Nyerguds]

You'll have to define per font which colour indices to keep and which to drop, I guess, and generate an opacity map based on that. Seems fonts ironically got less versatile from the 4-bit days.

Silly thought: can you overlay the same text in multiple fonts to generate text in mixed colours? Like, work in "font batches" instead of single fonts when drawing text?

[pchote]

The problem here is that SpriteFont was optimized for performance around rasterized vector fonts and ironically is no longer suitable for actual sprite based fonts.

The best direction would be to rename SpriteFont to something like VectorFont, introduce a new SpriteFont that doesn't do any vertex coloring magic, and update the font definition plumbing to allow the font type to be specified along side the file path.

[Mailaender]

Replacing DrawSpriteWithTint with DrawSprite by itself has no effect.