January 23, 2020, 10:13:26 AM

Username
Password

Pages: [1]   Go Down
Print
Author Topic: Looking for info on DO .FNT font file format  (Read 437 times)
0 Members and 1 Guest are viewing this topic.
jon
Giant Scorpion
*
Offline Offline

Posts: 9


View Profile
« on: December 24, 2019, 03:28:09 AM »

Hi everyone, does anyone have any information on what format the DO fonts are encoded in? I'd like to be able to decode them I so I can render them in my program.

For example, there is a font named F_BOOKBD.FNT.

Old Windows fonts are apparently named as such but through a hex inspector the DO fonts seem to start with the string "FONT" whereas that's not mentioned in the Windows .FNT spec so I don't think they are the same.

Thanks Smiley
Logged
olly
Global Spokesperson
*
Offline Offline

Posts: 1959



View Profile
« Reply #1 on: December 25, 2019, 06:11:29 PM »

Cool, will investigate the fonts.
Logged

and back in Nuln, the ageing Graf Berhardt smiled his secret smile of pride whenever he heard the latest tales of his eldest son's ever growing chain of glorious victories -(sothr manual)
jon
Giant Scorpion
*
Offline Offline

Posts: 9


View Profile
« Reply #2 on: December 26, 2019, 04:44:30 AM »

Sounds great thanks olly. Looking forward to hearing your findings.
Logged
Ghabry
Developer
*
Offline Offline

Posts: 1020



View Profile
« Reply #3 on: December 26, 2019, 09:58:09 PM »

No idea how the Fon format looks but assuming it is a normal pixel font it should consist of the following attributes:
Is it a monospace font (all glyphs have same width?) in that case there is probably a glyph width/height in the header. When not monospace there must be the width per glyph somewhere.
A single glyph is likely encoded as a bitfield: Bit set - Pixel, Bit not set - Blank. Additionally I would expect a 8bit alignment (e.g. when the glyph width is 12 then you have 8 bit, 4 bit and 4 0-bit), then the next row (2 bytes) follows, etc.
I just tried this but in the visual output (black box for 1, nothing for 0) I see noting that represents text :/
Logged

aqrit
Developer
*
Offline Offline

Posts: 74



View Profile WWW
« Reply #4 on: December 26, 2019, 10:05:32 PM »

It should be easy to reverse the width/height stuff (found by Ghabry, I assume)

Code:
typedef int (*getTextWidth_t)(void* font, const char* text);
typedef int (*getFontHeight_t)(void* font);

getTextWidth_t getTextWidth_orig = (getTextWidth_t)0x481930;
getFontHeight_t getFontHeight_orig = (getFontHeight_t)0x4819D0;

Logged
olly
Global Spokesperson
*
Offline Offline

Posts: 1959



View Profile
« Reply #5 on: December 26, 2019, 11:45:34 PM »

Here's the Shadow of the Horned Rat font, while the investigation continues

https://www.dropbox.com/s/40fbeld80ecg69p/SOTHR%20Fonts.zip?dl=0

Logged

and back in Nuln, the ageing Graf Berhardt smiled his secret smile of pride whenever he heard the latest tales of his eldest son's ever growing chain of glorious victories -(sothr manual)
jon
Giant Scorpion
*
Offline Offline

Posts: 9


View Profile
« Reply #6 on: December 29, 2019, 10:42:11 AM »

Thanks all. Looking forward to any findings you have—I've been continuing my own research and trying to work it out over the past few days but no luck yet. I'll keep trying though.
Logged
jon
Giant Scorpion
*
Offline Offline

Posts: 9


View Profile
« Reply #7 on: January 05, 2020, 01:58:08 AM »

The investigation continues for me. I posted on another forum just now to see if anyone else has any ideas (https://forum.xentax.com/viewtopic.php?t=21572).

In the meantime, here's my best guess at what each of the fonts are used for:

- F_BOOKBD.FNT (books font, bold?)
- F_BOOKS.FNT (books font, standard text?)
- F_BOOKSR.FNT (books font, red?)
- F_BOOKSW.FNT (books font, white?)
- F_HELP.FNT (?)
- F_MENBG.FNT (menu font, big)
- F_MENBGR.FNT (menu font, big, red)
- F_MENSM.FNT (menu font, small)
- F_MENSMR.FNT (menu font, small, red)
- F_MESS_E.FNT (message font, English? if English, why is there no German?)
- F_MESS_F.FNT (message font, French? if French, why is there no German?)
- F_TITLE.FNT (?)
- F_TOOL.FNT (tooltip font?)

"BOOKS" fonts probably means anything in the game that is text written on parchment or paper (e.g. troop roster, troop catalog, magic item catalog).

For the main menu fonts, when you hover over an item, it goes red, so that's why I believe the ones ending in R are for red fonts. If that's the case, theoretically there would be some sort of colour table or red RGBA colour in the font file. Same story with the books red font—this is probably used for when you're replenishing troops in the troop roster. Note: the game ships with English, French and German variations of some assets, so this is why I'm confused about whether the _E and _F fonts are for English and French, respectively. It may be possible though if either or both of the _E and _F fonts can be combined for German? Probably not really that useful in helping to decode anyway...
Logged
Ghabry
Developer
*
Offline Offline

Posts: 1020



View Profile
« Reply #8 on: January 06, 2020, 10:48:20 PM »

Some partial reversing of the font:
At 0x8 is the width of any glyph and if I didn't miscalculate there is an additional per glyph extra width at 0x9a + 16*charOrdinal.
I guess 0xA is the height.
From 0x50 contains 16 colors (4byte per color). The format is the same as in SPR (RGBA?).

Then my educated guess is that starting from "0x90" is some kind of glyph information block (16 byte per char). When you just scroll down until it starts to look "different" (at 0x1090) and you calculate the distance / 16 it gives: 256. So 256 chars, would make sense.

From 0x1090 I guess you have the pixel data. I suggest to just overwrite stuff after 0x1090 with FF and start the game and see what happens. Cheesy
I would expect that unused glyphs do not require space in the pixel data (The first without CDCDCDCD in MENBG is '). So when you just overwrite like the first 100 byte starting from 0x1090 you should see a change in the apostroph ('). I suggest using F_MENBG.FNT, is the title screen font and simply hexedited e.g. "New Campaign" in EngRel to contain a '.

But I can't find the font rendering routine. ALso this 16 color stuff doesn't make complete sense as there is no value for "draw transparent" here (000000FF).
« Last Edit: January 06, 2020, 10:54:46 PM by Ghabry » Logged

jon
Giant Scorpion
*
Offline Offline

Posts: 9


View Profile
« Reply #9 on: January 06, 2020, 11:31:38 PM »

Awesome Ghabry, I'll give it a go. Thanks so much for helping out.
Logged
jon
Giant Scorpion
*
Offline Offline

Posts: 9


View Profile
« Reply #10 on: January 06, 2020, 11:54:33 PM »

Just a quick thought on:

> ALso this 16 color stuff doesn't make complete sense as there is no value for "draw transparent" here (000000FF).

The first value in the colour table is hex FF 00 FF 00 (RGB 255, 0, 255). This is the same colour that is used in the BMP files in DO (e.g. in PICTURES folder) to represent transparency. So this could be the same story in the font files too.

Also I believe the SPR files were in BGRA order.
Logged
Ghabry
Developer
*
Offline Offline

Posts: 1020



View Profile
« Reply #11 on: January 07, 2020, 01:10:35 AM »

I messed up the offset calculation.
Font height is determined in the header via:
Word @ Offset6 + Word @ Offset 8

Text width is calculated via: For every char in the text do:
Word @ Offset4 in the Header + Width from glyph info block + 1



More stuff just by looking at the file.
In the header:
The 0x1090 I mentioned earlier is in the header at offset 0xC.
Afterwards there are actually two color tables with 16 entries. You can see FF00FF00 twice. I guess one is for either "label disabled" or "label highlighted". Or a historic left over, seems to be two times the same but the code uses the 2nd color table.

Glyph info block:
I forgot that this is little endian byte order so the high byte is to the right.
Looking at this 16 byte per "glyph info" starting at 0x90 again you can see patterns:

Word at offset 12 (starting from 0) must be the offset in the pixel data. This number increments with each non-CD-glyph.

Proof: For MENBG the first value is 0x0 and last value is 0x56E0, with 0x1090 offset this gives 0x6770 which is almost the end of the file.

2 16bit-Values must be width and height. We know the offsets between the glyphs so this can be determined by trial and error:
E.g.:
0 to 10 is 16 width. Candidates are 1, 4, 3 and 8. 4 * 8 gives 32 and we have 4bit per color -> 16.
Same works for the other rows.
Result:
Word at offset 4 width.
Word at offset 8 height.
Word at offset 0 maybe enabled. For a few glyphs it is 2, but usually 0 when CD, otherwise 1.

Doesn't fully work for the last glyph:
There are 272 bytes left to file end but it takes 280. (bug in the file maybe)

That info should be enough to write scripts for handling these files.



Still unclear:
glyph info at offset 2: Maybe a bit field, could be partially determined by just unsetting bits and checking ingame what happens.
glyph info at offset 7: Must be width-related, usually equals width or width-1.
Header at offset A.
« Last Edit: January 07, 2020, 01:33:11 AM by Ghabry » Logged

jon
Giant Scorpion
*
Offline Offline

Posts: 9


View Profile
« Reply #12 on: January 08, 2020, 10:28:35 PM »

Just wanted to drop a quick note here so say thanks Ghabry. Your hard work is paying off and I'm successfully decoding the fonts and able to display them. I'm still working through some of the unknown parts which mostly seem related to glyph layout and positioning so I'm not ready to share anything yet.

I'll post back here with any of my additional findings on the unknown parts, plus a link to my decoder and also (hopefully) a surprise screenshot of my progress putting the .FNT (and other) decoders to use.
Logged
Pages: [1]   Go Up
Print
Jump to: