I figured that using Text Objects outright would make for the simplest HUD, but I can’t get them to play nicely. Regardless of what font I use, frame(s) I make, Extrusion I set, or alignment I specify, the in-game text renders as flat bitmap with poor fidelity; left-aligned in one long line.
Am I not setting something correctly? Are Text Objects just not usable within BGE? I’m at a loss for what to do.
Grab a current build off of GraphicAll.org for some better support for text objects, in particular, new line characters in text. As for text, generally, you wouldn’t have (or want) actually extruded, 3-D text, so 2D flat text is fine for most purposes. It would be nice for you to be able to designate either left, right, or middle-aligned text, but currently, that isn’t supported (I think).
EDIT: If you want 3D text, you’ll have to convert the text to a mesh to keep its 3D appearance (though you won’t be able to adjust the text it displays). If you want to alter the 2D text in-game, you can use the object’s Text property to assign text to it.
Oh, a quick dir() showed me how to manipulate the text in-game! That’s a wonderful little device.
I was messing with Extrusion just to see if anything I did had an effect on the real-time rendering, really. Absolutely no change I made, not even to the Material, was visible in execution. I only want is plain old 2D text, for now, as one might imagine. ^^;
FontObjects don’t use their material settings. To change their text color change their object color. And as SolarLune mentioned, there have been some recent improvements to FontObjects added to Trunk recently (although many of the font options still don’t work).
How powerful is the font-texture method, compared to Text Objects?
Bitmap text objects (the old method) allows a little more control, as you can design your own font easily and save it, though it requires an external program (FTBlender) for you to make new font images. You can just create one texture and design your own font on top of it, though. Also, the bitmap-texture method should allow you to swap out fonts at any time you want via the bge.texture module’s image loading capabiltiies, though I’m not sure about that.
Text Objects are easier to set up, though, and bitmap-texture fonts are just that - textures, so they can be fuzzy unless you disable mipmapping. Built-in text objects are always clear.
My concern is that, for however nice Text Objects may mean to look, they don’t function; at least not in r43085, the latest 32-bit build. I’ll try to write my HUD in such a way that changing out rendering-tactics in the future won’t be a big deal. 
The current status is partly work in progress, and partly finished.
The original reason for support Font objects (aka Blender Text Objects) is to allow for unicode display (e.g. Japanese). With bitmap fonts this is close to impossible.
What is working now: ttf support; multiline support.
What is not working: text alignment; glitches (there a patch for that, basically there is some Z problems sometimes); relative font paths (a bug in BLF); match 3dview text;
I think the glitch is top priority followed by font paths. I would like to have the bge text matching the size of blender text, but that may be too hard to implement.
I’m about to do a commit for exposing the “Text” property to the interface (i.e. allow you to change the text with Logic Bricks). It would be great to hear your thoughts on it.
That seems like it would help a lot of people, and I was frustrated when I attempted that (first thing I tried) in vain. Implementing a layer that would monitor the Properties seems like it may be a slightly bigger pain than it initially appears to be, but the long-term flexibility it affords may be worth the trouble.
Implementing a layer that would monitor the Properties seems like it may be a slightly bigger pain than it initially appears to be, but the long-term flexibility it affords may be worth the trouble
Can you explain that again? I don’t think I got it.
Right now, Text Objects are manipulated with a built-in variable simply called ‘text’. Having it so it can be overridden by dictionary-like entry “Text” may be problematic, and changing the internal structure of the Text Object to rely solely on that form may be a bad political move; on top of possibly causing errors in other areas of code.
This was partially what the Python change from 2.49 to 2.5 was about, I believe. Basically, you can’t overwrite (or have errors from overwriting) variables now, as all object properties are accessed with obj.property while user-defined variables are accessed with obj[‘property’]. In other words, textobj[‘text’] would never overwrite textobj.text.
Can you try any build after rev.43156 ?
Fonts with relative path and packed fonts now work well.
Also the [“Text”] patch was committed and it works as follows:
the original content of the Text object (what you see in the 3dview) is the initial value for the [“Text”] property.
if you change [“Text”] the property will behave as any other gameproperty (so you must respect its type, e.g. an integer property will be -1 if you try to pass a string to it).
if you ever set the object.text (not [“Text”]) to any value you are converting your Text into a string type. From that moment on, even the original [“Text”] will only behave as String (if you try to add values through Logic Bricks you will get 1+1 = 11).
It’s a good time for feedback, we are still in time to change, roll back some of those changes.
(for fresh official builds always check http://builder.blender.org/download/ )
We are actually breaking this rule a little bit here (consciously). If you have a [“Text”] property this will be used to display texts by the Text Object (if you open old files that had [“Text”] properties a warning will tell you that you show look at that).
If you change ob.text you are actually changing [“Text”] ‘internally’ (converting it to string though).
Thoughts?
Only on worry, according to docs, game property strings have a short max length - I hope that don’t apply when we us the obj.text attribute.
Else it looks good.