Ive created a new bitmapped font using Bitmap Font Builder. Using the texture is no problem, and all of the characters are mapped correctly. My only issue is with the letter spacing. I can’t seem to figure out where this is calculated either. If someone could please point me in the right direction, or let me know if this is even possible with jME.
Here’s an example of what I’ve got so far. To make sure the characters were placed correctly I superimposed my font file on top of the font tga, in photoshop. There isn’t any different in positioning, the only difference between the two font textures is the fact that mine is 1024x1024 and a different font…
I’m currently creating the text using the Text class.
The letter spacing is defined in
LWJGLFont.
LWJGLFont is created within LWJGLRenderer and I don't think you can overwrite it with you own implementation.
LWJGLRenderer draws it with
public void draw(Text t) {
if (font == null) {
font = new LWJGLFont();
}
font.setColor(t.getTextColor());
applyStates(t.states, null);
font.print(this, (int) t.getWorldTranslation().x, (int) t
.getWorldTranslation().y, t.getWorldScale(), t.getText(), 0);
}
The Renderer should probably support adding multiple Font's and then have the Text just contain an id/name to the font it wants to use and resort to the default font if no matching font is found.
I browsed around before looking for variable width bitmap font and found that Slick had an implementation org.newdawn.slick.AngelCodeFont which works with this Font tool.
http://www.angelcode.com/products/bmfont/
Haven't really needed variable width fonts yet.. have just been playing around with other things. But if I needed it I would probably port the Slick code to jME :)
The Text class is really mostly for debugging IMHO… I'd use the text from FengGUI / Swing or maybe Text2D in jmex for anything real.
Text2D doesn't add anything it still uses the hardcoded LWJGLFont in LWJGLRenderer that there is no way to access. Text2D and Font2D doesn't seems like much more than a 2 class wrapper for loading a Texture.
It would require very little job to extend the functionality of the renderer to allow you to render bitmap fonts of different sizes just by adding a way to support more than one Font type(layout). LWJGLFont would axtend a generic Font class so you don't have to lock yourself to lwjgl. Then someone could implement a Font class that allows variable widths and might import bitmap fonts generated by some specific Bitmap font generator.
Suddenly you would have a limitless bitmap font support 
On second thought the way to go would probably be to implement a FontManager somewhat like TextureManager. I could probalby whip something together if there is a chance for it to get included in jme 
Thanks for the replies. I've been busy with holidays/family but have started work on integrating variable width font support into a gui wrapper I've written for jME. Depending on how this goes I'll post the code once it's stable.
If all you need the text for is a few places where it doesn't update much you can use one of the million AWT text quads out there on the net. What they do is that they render the text using a font (any font you have) to an image and then uploads that image to the GFX card. This has the advantage that you can use whatever font is available on the system or packed with your program. Unfortunately it has the disadvantage of using up a lot of AGP/PCI-E bandwidth if you update the text a lot.
Another alternative is to use a glyph-caching mechanism and upload each of the glyphs (think of them as letters) to the GFX card individually. Then they can be reused and any updates to the text does not need to upload new data over the AGP/PCI-E port. Think of this alternative as a way of dynamically generating and uploading the font bitmap from any True Type font.
The only drawback here is that each glyph takes up a Geometry in the system, causing a lot of JNI calls. Using RTT cuts this back down to one node per line of text. Still there's the overhead of doing one RTT call for each change of the text, but it's a lot better than re-uploading the entire text over the AGP /PCI-E since most modern cards can do RTT on-card.
The third way, as you mention, is to use a variable-width aware bitmap font reader. This has the advantage of being very fast at updating the text but the disadvantage of being limited to using only fonts that have been prepared in advance with a bitmap font program. (And as far as I know the current one in jME assumes ortho mode whereas the two previously described systems produce Quads that you can freely manipulate in 3D).
take a look at the new font system (TestBitmapFont) which uses AngelCode BitmapFonts. maybe you have to update, its in jme 2.0 since last week.
Ah ok. Thx.