GlobalKerning support for FONTDEFS

[Graf Zahl]

The flat and wall sprite feature would have been ok if there hadn't been some pressure to make it work with full 3-axis rotations. A true flat sprite (i.e. perfectly horizontal) could just induce a split of render content like a 3D floor, as could a perfectly vertical wall sprite be treated like a translucent wall. But with pitching and rolling in the picture - forget about it! It gets far, far too complex for that.

The same applied to billboarding. Initially the entire sprite code was simple and easy to handle, but over time several people with an insufficient grasp on the implications added feature upon feature upon feature, resulting in the monstrosity the sprite code has become. And now it is to late to revert because several mods would just break.

[Kinsie]

Holy crap Kinsie, still not letting it go?

When people express concern that a feature may be removed, and the engine developers ask when the last time a feature was removed was, and multiple instances in recent memory can be pointed out of commonly-used features getting removed and hastily replaced with buggy gap-fillers, it's reasonable for the initial concerns to not be quashed and in fact to be greatly increased. (Or in short: Yeah, FON2's gettin' dumped. Hard.)

[Nash]

So? FON2 is annoying to work with anyway, relying on extremely old tools whose creators aren't even around to maintain anymore.

Besides, they're not being removed. They're just being deprecated. Feel free to use FON2 if you want, but what's being developed and expanded upon currently is a much, MUCH better font system.

[Enjay]

So? FON2 is annoying to work with anyway, relying on extremely old tools whose creators aren't even around to maintain anymore.

I think the first part of that is just opinion. Personally, I find working with FON2 source images and then plugging them into a compiling tool far more convenient than either working with a whole bunch of separate images or a single image that I have to then chop up myself.

But the compiling tool is indeed well out of date.

I'm not arguing to stop deprecation or anything, and the new system does sound far more flexible generally, I just find the idea of a single consolidated lump or source image far more convenient (and much tidier) than a whole bunch of separate ones.

[Nash]

I can understand the appeal of having the entire font in one image, sure. One can write a script for, say, Photoshop, or maybe ImageMagick (IIRC it has scripting capabilities) to cut out all of the individual glyphs into singular PNGs, and even name the resulting files to be Unicode-compliant. :)

I have written some automation using a Javascript-like language in Photoshop, it's honestly a not-bad language to get tedious tasks done. It's not far off from ACS or ZScript. And even if one weren't scripting-inclined, Photoshop has Actions you can record; Actions require no scripting.

Automation is everything!

[dpJudas]

My biggest concern with the "image file per glyph" solution is the massive amount of files required (possibly thousands of system file open kernel calls per font, unless its packed in a zip or smt).

Ideally I'd say it should use an OpenType font with CBDT tables (rgba bitmap glyphs), although I have no idea if there's good authoring tools for that. At least it would be a standardized font solution rather than homebrew. I can understand if Graf doesn't exactly feel like implementing such a solution, though.

[Graf Zahl]

Have you ever seen a Doom mod that doesn't pack its assets into a resource file?

[dpJudas]

All those currently under development, I'd assume. At least I personally did not pack things into a resource when I was testing things myself.

[Kostov]

As a feature suggestion, this topic has long since run its course—can we move the discussion here?

[Graf Zahl]

All those currently under development, I'd assume. At least I personally did not pack things into a resource when I was testing things myself.

Nobody releases them that way, though.

[Kinsie]

My biggest concern with the "image file per glyph" solution is the massive amount of files required (possibly thousands of system file open kernel calls per font, unless its packed in a zip or smt).

Including a WAD in a PK3 has been repeatedly argued against and considered bad practice for well-documented reasons (memory etc.) and I'm not even sure you can have a ZIP/PK3 inside of a PK3.

[phantombeta]

and I'm not even sure you can have a ZIP/PK3 inside of a PK3.

AFAIK you can if you give it the WAD extension.

[Graf Zahl]

I wonder why you would want such a thing. It normally won't do what you intend.

[Gez]

I'm not arguing to stop deprecation or anything, and the new system does sound far more flexible generally, I just find the idea of a single consolidated lump or source image far more convenient (and much tidier) than a whole bunch of separate ones.

Technically, isn't it possible to have a single texture atlas image, and then split it into separate characters through a TEXTURES lump? Or does the font manager only works with separate graphics?

[Major Cooke]

I tried doing that once with a set of sprite flames once. Learned the hard way that was a bad idea. Upon trying to show those sprites inside the game caused tremendous drops in performance when starting to cache them.