Bitmap Fonts in GL

Hi,
I'm trying to get nice looking and fast text working in C/openGL/SDL. I have tried my own attempt and managed to get text drawing quickly and painlessly, but the it's monospaced. It doesn't take into account the width of the characters.

I tried GLF with outline fonts and it looked good, the charactor width was fine, although the font wasn't anti-aliased like texture based fonts. The reason I didn't try my hand at making it anti-aliased was simple: my game slowed from 120fps to 30fps when rendering one sentance. Outline fonts are slooooow.

I also tried a few others that I couldn't get working...

So now I'm here. What did you use for your game? Was it fast? Was it easy? (GLF is very easy) Was it pretty? Was it monospaced?

Freetype is my favorite... or Quartz... I swing back and forth on that one. Depends on cross-platformedness desireability I suppose, er sumthin. The whole trick to rendering fast *text* in OpenGL is that you have to take the strategy of getting as many characters on one *texture on quad* at a time as possible. Forget any other method, unless you are looking for special effects. For special effects like fancy (Photoshop) rendered fonts for a few characters at a time for like scores or something, I would definitely use display lists like you'd find at NeHe for basic font rendering. However, for very large, scrolling texts, the phrase that comes to my mind all the time is "Line by line". Rendering a whole paragraph of text as a single texture for each character input by keyboard is faaaar faster than rendering 250 textured quads with a character on each one, even using display lists. A line of characters seems ideal to me for most situations, but I'm still learning the ins and outs of the trade too, so if someone has a better philosophy then I'm all ears (or eyes in this case).

(if the viewer app doesn't work firsthand, just recompile it or run it from Xcode - it has an obvious bug which I forgot to fix: it expects to have a particular tga file on a specific path on launch, and it isn't there )

unknown Wrote:GlyphTool is a lot faster than FreeType. You can also design full color fonts with it check it out

GlyphTool creates *bitmapped* fonts, which I referred to above with my "special effects like fancy (Photoshop) rendered fonts" comment. I developed my own tool, similar to GlyphTool except a bit nicer (yes, with kerning info and everything), for doing that ages ago. GlyphTool is nice, and I'm not trying to knock it, but Freetype is an industrial strength font rendering library. You cannot realistically make the claim that it "is a lot faster than FreeType". As for how your GlyphTool framework renders the finished fonts, I do not know, but it simply cannot be any faster than FreeType since the fastest way to render text is to make one texture of many characters rather than many textures of one character a piece. Regardless of your font rendering method, once the texture is generated in-program for display in OpenGL it'll be just as fast, either way you look at it. If you are using display lists like the simple NeHe code, then I can guarantee it is not the fastest way to do it.

I've checked the speed of my GlyphToolkit against Freetype, I can assure you it is faster, the frames per second was greater performing the same font renedering task with my code and freetype code. GlyphTool creates textures with letters in it and the data required, including kerning values, the frameworks draw textured rect's from that data, which you could put into one texture if you performed similar slow calculations as freetype does.

Before we get into premature optimization, and to bring some perspective into this, did you know that Danlab's Jammin' Racer uses one texture for each character?

My CFont class, which uses one texture+display lists (like NeHe, but with variable width) can render a 20 lines paragraph of text at 100+ FPS on my Rage 128Pro. And my guess is, so can any other basic texture-based font system.

unknown Wrote:I've checked the speed of my GlyphToolkit against Freetype, I can assure you it is faster, the frames per second was greater performing the same font renedering task with my code and freetype code. GlyphTool creates textures with letters in it and the data required, including kerning values, the frameworks draw textured rect's from that data, which you could put into one texture if you performed similar slow calculations as freetype does.

Okay, let me try this again. GlyphToolkit and FreeType do not do the same thing. You cannot compare speeds. Only the end result is the same - that is, either way you wind up using OpenGL to rasterize glyph images onto the screen. How that is done behind the scenes and the techniques you use with OpenGL make a huge difference. Your speed test "assurance" is bogus because you clearly do not know how to properly use FreeType. Proper usage might mean you render the text block, or string, only once to a texture, when the text block is created, and thereafter *only when the text needs updating*, not every frame. Plus you can set up a glyph caching method for faster *rendering* (as opposed to the rasterizing operation, which again, is done by using a textured quad(s) in OpenGL). Plus you can break multiple lines of text into their own quads - maybe a couple dozen for a full screen of text. This all means that a block of one character, or ten thousand characters, render at exactly the same speed - as fast as a single textured quad -- because that is exactly what it is, assuming you didn't break it up into multiple lines --. The only inefficiency is when the text block texture needs to be updated, which normally is not very often, and in practice is usually not noticable, even if you're typing into a console and update it at 60 wpm (you might find that hard to believe, but I challenge you to try it yourself, I know I personally did not believe it myself at first). So in the end there is absolutely no possible way that you can do it faster than that. The more characters you have rendered to one texture at a time, the faster the rasterization, it doesn't matter whether it's GlyphToolkit or FreeType. If you use FreeType to render a string to a texture every frame you will kill the performance and GlyphToolkit will look like it's the faster of the two by far, which as I've pointed out is a flawed assessment. For simple stuff like scores and other small strings of text, I do the display list technique because I can put fancy pre-rendered fonts together just like GlyphTool does. Everybody knows how to do that. Some of us even include some hackish kerning info. It really shouldn't even be called kerning info though; see below.

Another side-note, doing correct kerning is actually quite tricky to do. You can't just take the spacing between glyphs as they are arranged in an alphabet and call it good. They have different kerning values depending upon which characters they are next to. This may also include vertical offset. In reality it's complicated to do, and FreeType takes care of that. A good place to learn about those details and more is in the FreeType manual. And Quartz even handles layout, which FreeType does not, so there's another argument in favor of Quartz if you plan on staying Mac only.

Not when your father is a typographer and teaches you exactly what you need to do to get kerning right.

AnotherJake Wrote:This may also include vertical offset.

Yes, and there was vertical offset in the terminal based version of GlyphTool, which this Cocoa app is a GUI frontend kindly made my Nick.

AnotherJake Wrote:The only inefficiency is when the text block texture needs to be updated, which normally is not very often

I tend to want to update or change text very often in game, like having scores displayed, level information come up or random tips in game. I developed my tool with this in mind.
My test was to render a page of text in an opengl window and have the right hand margin moving inwards, this was incredibly slow with freetype, so I developed my own improved solution.

AnotherJake Wrote:Plus you can set up a glyph caching method for faster *rendering*

This I did not know about at the time, and by the sounds of things would give approximatly the same speed as GlyphTool, after the job of rasterising the entire ASCII character set from vector data to bitmap, an unnecessary loading time I do not want to have to wait for.

FreeType is perfectly fast enough to render one or two lines of text per frame without putting *any* effort into optimization (and there are *significant* opportunities for it). That makes the "line of text per texture" approach perfectly sensible.

Additionally, using this approach, it's easy to add (eg.) Pango to get full international text layout and rendering, and font substitution.

As far as I'm concerned, GlyphTool and its friends (FTGL, GLF, etc) are solutions in search of a problem. Yeah, it's a neat programming problem to figure out how to pack glyphs into an image, but it's not the highest-quality or most-flexible method, and any speed gains are debatable.

I can't force you to actually *read* posts and *think* about them. I'm not trying to dog your program, all this work is just to point out that saying GlyphToolkit is faster than FreeType is like saying your cat is faster than a basketball. Anyway, I give up...

OneSadCookie Wrote:Additionally, using this approach, it's easy to add (eg.) Pango to get full international text layout and rendering, and font substitution.

That is the only case where I would consider FreeType & friends.

OneSadCookie Wrote:As far as I'm concerned, GlyphTool and its friends (FTGL, GLF, etc) are solutions in search of a problem. Yeah, it's a neat programming problem to figure out how to pack glyphs into an image, but it's not the highest-quality or most-flexible method, and any speed gains are debatable.

Sure, why would anyone want a cartoon-like, shadowed, gradient filled+border, <whatever> nice effect in a font when you could use plain, boring, single-color fonts?