Use mainui's truetype font rendering for on screen text

[54ac]

This adds hud_truetype and hud_truetype_size cvars which allow for rendering CenterPrint text using mainui's truetype stack since currently the text looks horrendous in higher resolutions, especially with gl_nearest. Tested on Windows. Equivalent PR in mainui_cpp repo.

I'm not particularly proficient in C so let me know if there are any obvious pitfalls or possible improvements.

Comparison:

[a1batross]

It shouldn't go through mainui. Engine by itself should provide, not consume.

I have branch with font rendering completely in the engine. But it's far from completion, and thus is private.

[54ac]

Thanks for your comment. What would be the alternative, moving truetype font rendering to the engine and then mainui would consume from that?

[a1batross]

Truetype renderer must be completely in engine. Making mainui the consumer must be a separate task.

In my branch only console font renderer is hooked to the truetype renderer and it only pre-renderers latin symbols, without adding up unknown glyphs.

[54ac]

Looks good. I might look into how viable a lift and shift would be when I have some time.

[mittorn]

Hooking engine fonts with UI is something i already suggested years ago, but was rejected. And nobody implemented fully yet in-engine or loadable font renderer, while wrapping mainui's renderer is minor task, that making it "just work" I still not understand why mainui font renderer cannot be used by engine. This is how it's implemented in goldsource (engine rendering font with vgui, i.e UI font renderer). Is there any clean reason why Xash3D cannot work same way (unless we implement fully gpu accelerated font rendering in ref, like some webgl font renderers) It's also possible to keep tiny ascii-only bitmap font fallback for missing ui case.

[a1batross]

Because engine, again, doesn't consume. The only reason I added this in menu because back then I also wanted to provide better text rendering in original Xash3D also, and... original Xash3D is no more, right now it's a temporary solution. As for accelerated font rendering, to me that seems like unneeded complexity. An overkill for a relatively small engine.

[54ac]

I've been steadily tinkering with this mostly on the weekends and it seems to be working pretty well so far. Mostly simply copied from mainui, though I had to do some random guesswork to get the characters to render right so there are probably some possible optimizations there.

[54ac]

@a1batross got back to this after some time, I assume there's oversights/missed optimizations due to my inexperience with C/C++ but seems to be working fine (font rendering moved to engine, console/centerprint rendered with TTF). Any further suggestions/issues you can see?

[a1batross]

I still disagree with the font renderering being driven by game-developer-facing DLL. It's cool to reuse code, but the dependency must be flipped as it's engine who provides.

[54ac]

That's basically what happens now in this PR, the engine now handles everything and exposes ttf_funcs_t, TTF_GetFuncs. I guess one more refactor would be to get rid of miniutl from the engine. Then in the mainui PR I can refactor it to be the consumer.