[LZDoom] Sheet font support

[Marisa the Magician]

This is something GZDoom had for like a year now I think, and now that some of us have figured out on our own how to use it, it's kinda breaking compatibility since LZDoom doesn't support this.

[Graf Zahl]

This may be a bit difficult, because LZDoom is a much older code base. The new font management and the transition to Unicode was one of the things that ultimately killed the vintage build and made the much older LZDoom the legacy port of choice. And it should be clear that the days of LZDoom as a mostly compatible port will inevitably also end in the near future. In any case, the download numbers of LZDoom are far too high that all these people run on old systems, most do it out of choice, not necessity. But without a survey the real need for mods to support this engine is hard to assess, but that's probably the one thing drfrag won't do.

What I can say from looking at the daily download numbers is that after Christmas, the ones for GZDoom increased while the ones for LZDoom slightly declined, it seems obvious that some people ditched their old systems for good.

[drfrag]

Those fonts could not be loaded else the localization feature would be in.That said i transitioned LZDoom to unicode too.
I already started working on the next gen legacy engine some time ago, the ill-fated NZDoom (or NeoZDoom?). It's based on polybackend and was meant to be software only, the idea was to do some kind of ZDoom reboot. Blzut3 decided to keep the LZDoom name and now that most users have Vulkan compatible hardware and it will soon be the default it supports OpenGL too but it's optional at compile time. This is meant to keep supporting 32 bit systems and be an alternative for more exotic features. Of course it has the classic ZDoom UI among other things. It's meant for the near future.
If you want to try: https://github.com/drfrag666/gzdoom/tree/master

[Graf Zahl]

What's the point in that? GZDoom can already use the softpoly backend with DirectX 9.
Assuming that OpenGL 2.x is too slow anyway to use the hardware renderer this should really cover most use cases, except for maybe that last remaining half percent.

So, from the looks of it

Of course it has the classic ZDoom UI among other things.

seems to be the prime reason for its existence and this is definitely a point where I'd consider your port more a problem than an asset, because it actively prevents modders from using the new menu system as intended and they have to compromise for your reluctance to move on here.
Sorry to be blunt, but it had to be said. If you want to preserve 32 bit once it gets retired you can fork at the point when it gets done - but maintaining a deliberately restricted port is not the solution.

[drfrag]

I wanted to do something different. Besides the new menu system is in, the fork is up to date. The modern UI is optional and can be switched at runtime but lowres modes can only be used with the classic UI.

[Rachael]

seems to be the prime reason for its existence and this is definitely a point where I'd consider your port more a problem than an asset, because it actively prevents modders from using the new menu system as intended and they have to compromise for your reluctance to move on here.

Maybe a viable compromise might be to add a gameinfo keyword that GZDoom ignores, that forces this new port to use the modern UI?