Analysis of 2.12 TDM Fonts

[Geep]

The handling of fonts with 512x512 bitmaps, instituted in Refont v 2.4, was found to be inadequate for Mason font. So Refont v 2.5 just released changes that, and the Refont wiki entry is updated. REF files posted earlier for Carleton with v2.4 are deprecated.

Still to do:

Post updated Carelton and Mason REF files

Revise datBounds to use the new REF format

[SeriousToni]

As I'm really curious, would you mind to share how much progress you made / how much is left to do to complete your goal?

[Geep]

For 2.13, this is mainly a march through the fonts, improving my tools and auto-correcting minor problems. Complexities of some fonts has made this harder than anticipated (of course).

If a font already has European accented characters, I'm changing 2 codepoints to ideally introduce 2 new accented characters, or at least park the DAT codepoint entry to the most-correct unaccented character. For 2.13, I plan on wrapping the DAT revisions by end of January, with final work on the Mason and Carleton families.

I need to upgrade datBounds to handle within-DAT scaling, but that could be completed in an early 2.14 timeframe.

For 2.14 and beyond, there is no end to work that could be done to improve font bitmaps. But I plan to think more about possible overhauls of how translation works, which might be more worthwhile.

[Geep]

The revised Carleton and Mason REF files, generated by updated refont v2.5, are now available.

See the included Summary .docx file for details, which itemizes what is superseded from previous releases, and what is not.

[wesp5]

Will this end up in the core game 2.13?

[Geep]

3 hours ago, wesp5 said:

Will this end up in the core game 2.13?

That's my hope. I should also figure out how to review the main menu translations to make sure the 2 codepoint substitutions are properly accommodated.

[Geep]

Added a wiki page about the complicated Carleton fonts, based on notes I've been accumulating.

https://wiki.thedarkmod.com/index.php?title=Carleton_Fonts

[stgatilov]

I'm sorry that I'm so late to the party.

I wonder if it would be better to turn all font images into TGA to avoid recompression artefacts?
The engine loads images as materials, so if we add a material file per every image file, we can as well do forceHighQuality for the fonts and avoid any compression artefacts completely.

UPDATE: Actually, I guess compression artefacts is not a big problem here.
The fonts necessarily have alpha channel, so they use DXT3 compression.

It has DXT1 color blocks which are 100% lossless because the color is full white (at least I hope so), only alpha information is relevant for the fonts.

Also DXT3 has 4-bit per-pixel alpha channel. Basically, the alpha channel is stored at 4-bit precision instead of 8-bit precision, thus offering 16 grades of opacity instead of 256 grades. Something tells me 16 grades is enough. Also, it is pretty obvious what exactly the compressor would do to the raw alpha we push into it: it will just round the value to the nearest 4-bit-representible value.

[Geep]

On 1/11/2025 at 6:21 AM, stgatilov said:

The fonts necessarily have alpha channel, so they use DXT3 compression.

I believe DXT5 compression is what is traditionally recommended. This differs from DXT3 is how alpha is quantized.

 

On 1/11/2025 at 6:21 AM, stgatilov said:

It has DXT1 color blocks which are 100% lossless because the color is full white (at least I hope so), only alpha information is relevant for the fonts.

Full white is generally true. There seem to be some cases with Mason and Carleton family fonts where there is also black or gray involved. I'm thinking at the moment is it's on purpose with Carleton, accidental with Mason. For Carleton, to put a black border around a white character, without having to call on the engine to do so.

[Geep]

With the help of @nbohr1more and @stgatilov, my 2024 font changes were released as a cumulative package Jan. 10 and added to SVN for incorporation into TDM 2.13. Here's a MS Word docx with tables that describes those changes:

2025_Jan_Font_Changes_for TDM_2_13.docx

That docx is also being released as part of a Jan. 16 supplement font file package. For more about that, see this post or

2025_Jan_Cumulative_2024_Font_Source_&_Supplementals.zip

[wesp5]

Geep, as you are the font specialist, can you please take a look at the issue with the fonts which I reported in the 2.13 beta thread? Is this a font problem or just a bad position cutting the lowest line off?

Edited January 17, 2025 by wesp5

[Daft Mugi]

7 minutes ago, wesp5 said:

Geep, as you are the font specialist, can you please take a look at the issue with the fonts which I reported in the 2.13 beta thread? Is this a font problem or just a bad position cutting the lowest line off?

 

[wesp5]

Sorry, but that is not the reason. Clearly some pixel lines are lost in the Download Missions window. It's especially obvious with capital O and B and some other letters.

[Daft Mugi]

1 hour ago, wesp5 said:

Sorry, but that is not the reason. Clearly some pixel lines are lost in the Download Missions window. It's especially obvious with capital O and B and some other letters.

 

I'm not noticing a difference between 2.12 and 2.13 fonts in the download missions list. Can you share comparison screenshots?

Perhaps a separate issue?

[wesp5]

7 hours ago, Daft Mugi said:

I'm not noticing a difference between 2.12 and 2.13 fonts in the download missions list. Can you share comparison screenshots?

Perhaps a separate issue?

I don't have 2.12 installed anymore, but it could well have be visible before, only I never cared or noticed. But I thought now would be the right time to mention it as the font is worked on anyway. For a screenshot of the issues look into the 2.13 beta thread! You are right that tonemapping seems to make it even worse though...

Edited January 18, 2025 by wesp5

[Geep]

Looking at the mission title under 2.12, I think this was already a pre-existing condition. The lower case letters in particular are prone to over-thinning of some of their horizontal strokes. I think the scaling down causes this, and probably made worse by any sharpening applied in 2.13.

The mission title font, defined by MM_TITLE_FONT, resolves to:

font "fonts/carleton_bold" // MM_BOLD_FONT
forecolor [eventually] 0.4,0,0,0.9 // blood red MM_TITLE_COLOR after INVISIBLE
textscale 0.25 // MM_TITLE_FONTSCALE
visible 1
textalign 1

The textscale of 0.25 will select the 24pt font bitmaps to scale from. In that size, carleton_bold has some quirks:

• is not really bold, just a clone of carleton
• uses double-sized 512x512 bitmaps, so the engine has to scale down more than with most other fonts.
• has black borders around the white characters (discussed more in my new wiki "Carleton Fonts" article), which may possibly impact scaling and sharpening algorithms.

Carleton and carleton_bold are at best tolerable quality bitmaps. Eventually, they could be overhauled. But in that longer time frame, maybe revisiting the scaling and/or sharpening algorithms is warranted. Regarding scaling, I bet right now, moving a bitmap letter +/- 2 pixels vertically would change the over-thinning manifestations.

 

 

[wesp5]

11 hours ago, Geep said:

Regarding scaling, I bet right now, moving a bitmap letter +/- 2 pixels vertically would change the over-thinning manifestations.

So can you do that? I believe your updated fonts will be part of 2.13 anyway, right?

[Geep]

My substantial 2.13 updates are mainly for Stone 24pt font. With respect to this latest issue, sorry, I have no quick fix. It would take a massive amount of bitmap editing. Could be addressed for 2.14

[Geep]

Version 1.6 of datBounds is released, to support further work with Mason and Carleton fonts.

Main changes:

• Supports REF files with refont v2.5 headers for 512x512 bitmaps
• Adds options scaling_ok and raw_metrics.
• Fixes shaderName and other issues preventing .tga generation.
• Shows filenames during write.

See the datBounds wiki page for details and links.