GUI Font Rendering

Started by
3 comments, last by TomKQT 13 years, 4 months ago
I was looking into text rendering, and for decals I seemed to have found that using signed distance fields is the way to go (Valve method). However, for gui objects this seems like it would be overkill. Is there any suggested method for GUI font rendering that will allow for a nice crisp display?
Advertisement
I should also mention that I am not specifically looking for bitmap fonts either, if it requires the use of .ttf then that is fine also.
Without a fancy scaling technique, you only really have one alternative: rasterize font glyphs to texture at the appropriate target resolution, and then render in such a way as to achieve a direct mapping between texels and pixels. If you know the specific sizes and resolutions in advance you can pre-compute the textures, otherwise you'll have to do it at runtime.
strtok, this is what I do and it works well. I use directx to create the font I want then I copy the letters into a texture and then draw all of my text in an instanced call. This is many hundreds of times faster than the directx DrawText function. I am almost positive that directx uses a single draw call per letter --or at least it seems that way because of the MAJOR slowdown when using it.
Wisdom is knowing when to shut up, so try it.
--Game Development http://nolimitsdesigns.com: Reliable UDP library, Threading library, Math Library, UI Library. Take a look, its all free.
Quote:Original post by smasherprog
strtok, this is what I do and it works well. I use directx to create the font I want then I copy the letters into a texture and then draw all of my text in an instanced call. This is many hundreds of times faster than the directx DrawText function. I am almost positive that directx uses a single draw call per letter --or at least it seems that way because of the MAJOR slowdown when using it.


It's a ID3DXSprite::Draw call per letter.
Quote:Original post by smasherprog
I am almost positive that directx uses a single draw call per letter --or at least it seems that way because of the MAJOR slowdown when using it.
Another reason may be that DrawPixel does a lot of additional things such as translating language sets, compositing glyphs, hinting, kerning, and subpixel rendering in software, in realtime. It may be able to cache the raster image so subsequent renders of the same letter are faster, but depending on circumstances, it may as well not be able to cache that data. Rendering high-quality text in an accurate, correct way is a really complicated and non-obvious thing.
The same letter might get totally different colour values (not just differently blended shades of grey) at a different text position, because kerning and whatnot offsets it by so and so many fractions of a pixel which will require a different colour mix for subpixel rendering to work.

Certainly, copying a static texture subimage into the framebuffer using dedicated hardware will be much, much faster. :-)

This topic is closed to new replies.

Advertisement