[Added] GlobalKerning support for FONTDEFS

[Xaser]

There's a lot of cool localization stuff in the works, but as mentioned by Graf here, old-style binary font lumps (i.e. FON1/FON2) don't mix well with the new system.

Though FON2 ought to have been long-obsoleted by FONTDEFS, There's still one thing that FON2 can do that FONTDEFS can't: set GlobalKerning. This is often used to merge the 1-pixel border between letters for Doom-style font graphics (i.e. set it to -1) to do things like make DBIGFONT look like how the text is formatted on Doom's CWILV graphics. A "KERNING" specifier for FONTDEFS would close that feature-gap and let all of us kick FON2 to the curb for good.

Because someone's inevitably going to suggest full per-character kerning: please reserve that topic for another thread. This is just about exposing support for the feature that already exists, which is independently useful as a "border collapse" feature.

[Enjay]

Though FON2 ought to have been long-obsoleted by FONTDEFS...and let all of us kick FON2 to the curb for good.

I'm not so sure. To me, FON2 being a single lump (generated from a single source image) makes it very convenient to work with and store in a WAD or PK3 versus a tiny separate image for each character. I know the generating tool (imagetool) really could do with a revamp, and the most reliable input format being PCX isn't ideal either, but I quite like the basic idea of the compiled fonts.

[Graf Zahl]

FON1/2 is a problem because it is a binary format created with an obsolete tool. That alone makes it a very unappealing thing.
And binary formats in general flat out suck. I'd rather add the option to add a config lump in with the collection of glyphs in a directory where such things can be optionally set.

Even for the console font the current system is not good, it'd be a lot better if the source graphic could be used directly, and be extended to contain more characters / or more character pages - whatever works better.

[Rachael]

Honestly for the console font, I'd rather the glyphs be split. Adding international characters is a lot easier when you don't have to worry about recompiling the whole graphic. That also makes it easier to change it, too, for custom games.

[Undead]

Splitting the glyphs for both types of formats would be immensely convenient for future translators and other people working with those formats, but I hope the format won’t be removed outright, as that will break a lot of old creations such as these fonts on Realm667.

[Rachael]

Removing the old format is highly unlikely. It'd break too many mods, and mod compatibility has always been a major goal of the GZDoom engine.

That being said, if Graf does decide to add flexibility to the system such as allowing individual glyphs for the console font, you can be pretty sure the old format will be deprecated (not maintained or supported anymore) at the very least.

Like Windows, GZDoom comes with a lot of compatibility glue to make sure old shit still works.

[Jimmy]

Echoing Enjay's sentiment. I kind of hate ImageTool myself, but all the same a compiled lump is IMHO preferable in many ways to having multiple separate glyphs. There's definitely a better way to go about it than FON2 does, of course, so I wouldn't rule it out as an option.

Undead alerted me to the recent localisation changes and how FON2 might be being "done away with". Now, deprecate the FON2 format by all means, but please don't remove it, god no. I have hundreds, possibly thousands of hours' work on custom binary font lumps that would become obsolete and unusable instantly.

[Rachael]

Please see my post just preceding your's. There seems to be a bit of unnecessary fear going around about this.

[Graf Zahl]

Honestly for the console font, I'd rather the glyphs be split. Adding international characters is a lot easier when you don't have to worry about recompiling the whole graphic. That also makes it easier to change it, too, for custom games.

I think with the console font the best option would be character pages as images, i.e. one page for 0x000-0x0ff, one page for 0x100-0x1ff and so on, to reduce the clutter.

[Graf Zahl]

Please see my post just preceding your's. There seems to be a bit of unnecessary fear going around about this.

To all those who are concerned, ask yourselves one question: When was the last time a feature was actually REMOVED?

[Jimmy]

I was only just alerted to the extent of the changes to the font system and didn't have the full details. Sorry. Carry on.

[Undead]

This was added in GZDoom with this commit

I guess the thread can be closed.

[Kinsie]

To all those who are concerned, ask yourselves one question: When was the last time a feature was actually REMOVED?

July 2018.
September 2016.
Probably one or two between those two dates.

Sure they came back, but only after a lot of foot-stamping and raised voices.

[Graf Zahl]

July 2018.
September 2016.
Probably one or two between those two dates.

And yet, we are now saddled with some broken feature (flat sprites) that probably will never get repaired. That first version you linked to was even more broken.
As for the screen resolution thing, sometimes you have to choose between staying behind and moving with the times. Once code reaches a stage where it becomes unworkable even the nicest feature will have to be scrutinized, especially if they aren't modding features.

[Nash]

Holy crap Kinsie, still not letting it go?

I'm going to say it it straight, as the person who started the initial effort to bring GLOOME's flat sprites into GZDoom: the true motivation was I wanted to render models with texture alpha for those floor blood "decals" but models used to ignore texture alpha. This finally got fixed several years later, but let me tell you - if the model texture alpha bug didn't even exist in the first place, I would not have considered porting flat sprites into GZDoom at all.

Graf is 100% right - that flat sprite implementation incomplete, and is polluting the sprite code. While I don't agree to flat out deleting it, and I CAN see other uses for flat sprite rendering besides my own use case, it is unfortunate that the feature was very, VERY poorly coded and TBH it's just a matter of time before it gets too much in the way of some future, currently-unseen expansion that it might have to be deprecated for real...

Also, offtopic?