:: Opengl Text ::

[pixelshader]

I am using wglUseFontBitmaps in my application. But the output has jagged edges. I tried to implement antialiasing to remove this jaggies. But it was not working. I used


multisampling method of antiaiasing since it supports all the primitives including bitmaps. But didn’t get the expected output. Then I tried outline fonts, the anti aliasing worked fine but the size is very large compared to


the actual size set to font. And it do not support underlines. Actually in my application I want to draw the fonts as they are drawn by GDI. It must match with GDI in its size and appearance. Please provide a good solution..

 

[Panajev2001a]

I am using wglUseFontBitmaps in my application. But the output has jagged edges. I tried to implement antialiasing to remove this jaggies. But it was not working. I used


multisampling method of antiaiasing since it supports all the primitives including bitmaps. But didn’t get the expected output. Then I tried outline fonts, the anti aliasing worked fine but the size is very large compared to


the actual size set to font. And it do not support underlines. Actually in my application I want to draw the fonts as they are drawn by GDI. It must match with GDI in its size and appearance. Please provide a good solution..

Does multi-sampling AA work with bitmapped fonts? In theory the font itself in a bitmapped font should not be affected by multi-sampling AA... isn't it just basically a texture projected onto a screen aligned quad (thus only the quad's [invisible] edges get the AA treatment?)...

Sorry if I completely missing the point here or talking out of my butt... ...

 

[Davros]

Have you tried GLText ?
http://gltext.sourceforge.net/

 

[FoxMcCloud]

Short answer: Don't use bitmap fonts, use FreeType2 or the like to render to a texture surface.

Long answer: When you deal with lots of font sizes, multiple languages, diacritics, complex scripts and BiDi, you'll find that a bitmap font to encompass those characters will be a huge memory hog. What I did was render the text using FreeType2 (and ICU for some complex script shaping, if you need that, but it bloats your binary) and then process it to generate an SDF surface (see Valve's paper) and render that. Looks nice, not much of a memory hog.

 

[sebbbi]

We are also generating distance fields from true type fonts on fly. Distance fields scale well (edges stay sharp and curves do not become blocky), so you don't have to generate different sized versions of your fonts. Distance field fonts also antialias very nicely (just a few extra pixel shader instructions). Create a cache system that generates each character on demand to a large character atlas. And try to render as many characters with one render call as possible.

 

[FoxMcCloud]

Create a cache system that generates each character on demand to a large character atlas.

Word of warning, this'll fail catastrophically with complex script languages.

 

[sebbbi]

Word of warning, this'll fail catastrophically with complex script languages.

How so? We are using this kind of system with a actionscript 2 / flash driven menu system. No problems whatsoever.

 

[mikegi]

How so? We are using this kind of system with a actionscript 2 / flash driven menu system. No problems whatsoever.

I think FoxMcCloud is saying that Asian fonts, with potentially thousands of glyphs, will blow out your texture atlas. What's the typical blackbox for your distance field glyphs?

 

[FoxMcCloud]

How so? We are using this kind of system with a actionscript 2 / flash driven menu system. No problems whatsoever.

Do you have proper support for complex script languages, or is this a case of "It's working with out Latin script languages and we haven't seen any problems"? I'm willing to bet it's the latter, which implies that you mostly either didn't read or didn't properly process what I wrote.

Creating a character atlas works good for Latin languages, where every letter has 2 forms (excluding attributes like italic, bold, etc): lower and upper case. When you start dealing with characters with a high glyph count, like Japanese, you'll lose some efficiency but it'll mostly be manageable if you limit yourself to, say, katakana or so. Now if you ever start doing real grown-up i18n software and have to deal with languages like Arabic where each letter (out of 20-something, don't remember how much exactly) has about 3 or 4 shapes depending on the preceding and following letter, and each of those shapes can be further modified through a variety of diacritics (some of which can be combined together), and after all that is taken care of you still have to deal with stuff like the Lam-Alef Ligature (which changes the shape of some letter combinations in certain words, including the word Allah, which is apparently a huge deal in the Arabic speaking regions), you'll realize that a glyph atlas is a terribly bad idea.

However, if you're doing supermarket software (for a non-Arabic-speaking region) for a living, then don't bother - that'd be overkill anyway. But we don't wanna end up doing supermarket software, do we?..

 

[sebbbi]

However, if you're doing supermarket software (for a non-Arabic-speaking region) for a living, then don't bother - that'd be overkill anyway. But we don't wanna end up doing supermarket software, do we?..

If you consider console games supermarket software, then yes.

So far our games have been localized to Chinese (both traditional and simplified), Japanese, Korean, Russian, Greek and all the other European languages. A 32x32 distance field in DXT5A format takes only 512 bytes. You can have 4096 these in a single 2048x2048 atlas texture (2 MB total size). Usually games use only 1-3 fonts at a time, so 4096 glyph cache is more than enough.

We haven't needed italic so far in our games. If needed emulated bold can be achieved easily on distance field fonts simply by adding bias in the shader, and emulated italic can also be achieved by tilting the rendered quads. Lower and upper case letters haven't been a problem for us, since the most problematic fonts (East European languages) tend to only have upper case letters (Kanji / Hiragana / Katagana naturally do not have lower case letters either).

Haven't seen Arabic and Lam-Alef Ligature in the recommended localization lists (for current generation consoles). Maybe there are some console games supporting these languages, but it's not the norm.

But if you need to support many complex languages and fonts at the same time and you need to support real bold/italic/etc then I agree that glyph atlas might not be the right solution. However it's really fast and efficient method to render text in current generation games.