Justin Rogers

<Quote>
many games use pre-generated graphics for printing text since it looks *cool*
</Quote>

Actually, games use bitmapped characters because they render extremely quickly (two stripped triangles as opposed to an outline\fill algorithm). Assuming I take your meaning correctly :)

n!

Taken slightly out of context, but not such a big deal. I should have clarified.

Most games do appreciate the performance increase of indexing into a single texture filled with pre-gen characters and overlaying that on top of an arbitrary quad.

However, you can offer many of the same performance benefits, by dynamically rendering and caching your alphabet using GDI to blit said letter onto a texture surface somewhere.

With this in mind, recent usages of a bitmapped alphabet overlay are more for coolness, IMHO, than they are for necessity of speed. Even with the recent usage of the pre-canned font class delivered as part of the DirectX SDK, the proliferation of textured alphabets does persist, along with the lack of an ellipses usage even though the pre-canned font class should be capable of rendering any character in the given character set.

I'm not sure about the performance numbers here, but I've had the experience that it is faster to render an entire text buffer to texture using GDI and overlay the texture on a single quad, than it is to build up my display using many small quads per character. It also presents the benefits of the font layout manager for character spacing, line spacing, and other features that don't exist when you are using a textured alphabet.

I'm not sure I'm talking about the same thing now :) I class dynamically rendering and caching an alphabet, using GDI+, to a texture the same thing as 'pre-generated graphics'. Even if this is done when the application is started.

Certainly rendering a single message to a texture (using the above pre-generated font) and rendering that message will be faster, but I'd still consider that the same thing.

Games (that I'm familiar with, at least) do generate their 'generic' fonts using GDI (or GDI+). I suppose you're recommending this is actually done during run-time initialization rather than pre-generated and packaged on the CD\DVD? I originally thought you meant games chose not to render fonts in the same way as windows for aesthetic reasons.

There are also other bitmap fonts that are created specifically for a game (which are all 'dolled up' to look pretty and fit with the game atmosphere). These are 'just to look cool', but then the OS (if you're lucky to be on an OS in the Win32 sense of the word) doesn't provide such fonts so there isn't much choice. Though I find these types of font are on the decline as they're more difficult to localize and read.

Sorry, I didn't mean to hi-jack the posting based on a single line. The ellipsis being a single character was a surprise to me too! :)

n!

Nothing better than talking about gaming on a blog that contains good things on gaming.

Yeah, I think we are confusing different meanings since there are so many reasons for the way text is handled in gaming. In general, you can pre-gen a font before shipping and include that on the DVD, you can pre-cache the font at run-time initialization (which is actually a method I prefer because you can render the font for the target resolution), or you can dynamically render all of your fonts.

Recently, I think most games choose to use the DirectX font class (less pre-gen, more dynamic), or a variation there-of. But they still keep the old pre-gen stuff around for other cool features as you suggest. They might be on the decline, or they might just be getting started. Games are pushing the DVD capacity limits as we speak, and a few megs worth of extra jpegs for different alphabets, coupled with the write once, use many code required to display localized resources, really isn't that bad.

I might have to do some performance work on text engines in games. I know, for instance, that Longhorn will have one of the best text compositing engines ever written. And they are saying the new text compositing has very little performance impact on the system. That leads me to believe that current text rendering systems really aren't a viable bottleneck, especially considering the small amount of text that can be fit on the screen at one time. Just doing basic tests, I can fill a form using GDI+ flow and layout in just a few milliseconds. Since in the DirectX world that render would get re-used for a second or two before I had to re-render. And I get the font rendered for the target resolution, rather than having it shrink to unseeable at super high resolutions, and have it fit the DPI of the target device in the case of 300 DPI screens.

I guess the console market still has a good reason to use pre-gens, as would small gaming devices. I'm betting they'll be in use there for a long time as a performance increase. Maybe rendering three dots is less than the cost of an extra glyph. I'm just not sure. I just know the ellipses at this point, is a character that is either often used (insert ellipsis character) or often mis-used (insert three periods). You decide!

"The most readily apparent to those of us that blog, would be to use the ellipses character directly from the HTML view &#0133. Just make sure the character set being used has such a character."

No, this is wrong. Numeric character references always refer to code points in the document character set (for HTML this is ISO 10646/Unicode) and not in the file's character set.

Ben, if you come back, can you clarify this? I've found that using &#0133 here in the .Text blogs system while in HTML view allows me to insert an ellipses. Or I can use Character Map to simply copy/paste one into the Design view. I was just trying to provide a method for individuals to insert such a character (which does work for me at least), but you seem to have additional insight. Can you perhaps demonstrate what you mean?

On the character entity references page for HTML
http://www.w3.org/TR/html4/sgml/entities.html
it has the ellipses as &hellip;