Spring RTS Engine

So I decided to spend an hour to look into my assertion that a
texture atlas based font system implemented in lua would be
faster then the current Spring font system. Here are the results:

Using 8 x "the quick brown fox jumps over the lazy dog"

No font rendering
360 fps (2.778 ms / frame)

Spring outlined text (size = 12)
185 fps (5.405 ms / frame)

LuaUI texture atlas (size = 12)
311 fps (3.215 ms / frame)

Subtract the no-font case from the two other cases:
spring font = 2.627 ms
luaui font = 0.437 ms

That's about 600% faster.

The texture atlas fonts can also be pre-rendered with outlining
(as was the case with the font I tested with, ProFont). I have not
yet included a dynamic string display list manager, which would
render strings with a single display list call, avoiding all the lua
processing and 'gl' call-outs. I could easily see that halving the
amount of time it takes to render a string.

P.S. The texture atlas font was copied from the BZFlag data pack.
To set it up, all I had to do was pick out the character parameters
from their custom font spec files.

P.P.S. This also means that you'd be able to switch between
multiple fonts with very little effort.

For what it's worth, I also tested the Spring's font rendering
without outlining. It was a slightly different camera setup, but
here are the numbers anyways:

No rendering
358 fps

Spring font (no outline)
297 fps

LuaUI texture atlas rendering
315 fps

Note that the LuaUI rendering is still faster, even though it
has to make a number of lua call-outs for every character
that it renders.

P.S. Oops, forgot to include some vitat stats:
CPU = AMD Athlon(tm) 64 X2 Dual Core Processor 3800+
GPU = Nvidia GeForce 7900 GS

^_^ This should help greatly.

Any chance of outlined fonts on the loading screens? To prevent the whtie text on white explosion syndrome...

Sweet!

I've committed a "LuaUI/fonts.lua" font handler that works reasonalbly well.
It is not yet a full replacement for gl.Text(), as it does not yet handle embedded
color codes, text alignment, or font size queries.

This addition also brought a couple of handy texture features along for the
ride. I've added the 'g' and 'i' options to gl.Texture(). The 'g' flag will convert
an image to greyscale (disabled buildpics? does not work with dds images).
The 'i' flag will invert the color components of an image.

This fonts.lua implementation also supports caching complete strings in
display lists to speed up the rendering, and avoid lua processing. Early
testing shows a noticeable improvement.

Wow, this really sounds great.. I will continue my serious GUI work starting tomorrow.. Would you recommend to update my Text to your fonts.lua (if that is possible; haven't looked at it yet) or will you replace the gl.Text call completely any time soon?

I have to ask:

How the hell are fonts so inefficient?

EDITED (trepan): removed needless profanity

There are 2 big slowdowns in Spring's font code (from what I've seen).

1. Texture switches
Each glyph uses a separate texture.

2. glPushAttrib / glPopAttrib
These state calls are used to compartmentalize the font rendering, but
they're oftentimes wasted, especially when you consider how often
multiple lines of text are rendered together.

MelTrax
If you want to play with it, here's what's currently available: Notes:
1. "fontHandler" is passed to all widgets.
2. There is no "size" parameter
3. Color codes are not interpreted
4. You have to make sure that the state is setup correctly
(ex: gl.AlphaThresh will affect fontHandler rendering, so
you can make it look as ugly as you want )

Available Fonts: (only ProFont is outlined)
LuxiMono_6
LuxiMono_8
LuxiMono_12
LuxiMono_16
LuxiMono_32
ProFont_6
ProFont_8
ProFont_12
ProFont_16
TogaSansBold_6
TogaSansBold_8
TogaSansBold_12
TogaSansBold_16
TogaSansBold_32
TogaSerifBold_12
TogaSerifBold_16
TogaSerifBold_32
VeraMonoBold_6
VeraMonoBold_8
VeraMonoBold_12
VeraMonoBold_16

I ditched the BZFlag format, and wrote a custom font texture and
metrics file generator. The generator can be used as a stand alone
program, and can be called by LuaUI (it's built into the Spring engine).
It will optionally outline the font, with variable width and darkness. I plan
to setup up a split outline option as well (render twice, needed for bright
outlines). The generator can also write the font glyphs with padding,
to make it easier to edit the texture files without screwing up the metrics
(in case you wanted to do your own outlining, setup a colored font, etc...)

Click on the images to view the high resolution PNG versions (~1.4Mbytes).
Note the proper anti-aliasing, and how smaller fonts are more legible then
with the current rendering.





P.S. It'd probably be quite easy to tie it into the default font rendering
setup, but having it available to LuaUI is good enough for me (for now).

P.P.S. The sizes listed are pixel sizes, not point sizes. The console text in the
second picture is the default Spring font rendering (using the trebuchet font).

*is trying to understand* this way uses 1 texture with all the letters on it in a grid for each font/color?

*the quick brown fox jumps over the unfortunate dog.

it's time somebody set the record straight.

http://en.wikipedia.org/wiki/The_quick_ ... e_lazy_dog

It's from a peanuts comic

Great work trepan!

However, a lot of ppl don't use LuA at this time, for it slows other processes and can crash. How's that problem atm?

E: Wow, the fonts and outline looks really great! This would be awesome, and really enhance the GUI experience!

BvDorp:
Asked and answered.
http://spring.clan-sy.com/phpbb/viewtop ... 623#178623

btw is it possible to make he font mod-dependent?

yes

On that note, I'll probably be adding the code for mod-widgets sometime
today or tomorrow. That'll make it easy for mods to provide mod-dependant
widgets, which can interface with mod-dependant LuaRules scripts. The
LuaRules scripts can set custom properties on units which are accessible
to LuaUI (ex: you could add a fuel parameter to all mobile units, and stop
them when they run out; i'd hope you'd also have refueller units...)

P.S. Coding fuel for all units in lua is a waste of resources, and would be
better coded in C++. The point is that the lua scripts are flexible enough to
allow you to fill in some of the missing pieces.

My lovely profanity

It's never needless, you know