RE: [Algorithms] handling large amounts of dynamic text

[Eric M. <ema...@um...>]

Thanks everyone for your excellent responses, they were quick too. :P I'm
deciding to stick with the quads approach for now. It is great to hear
everyone's take on it. I'm a little surprised that the majority of people
are using quads for each character. I guess I'm getting enough raw
performance out of my app to feel comfortable sending hundreds of quads
for text down the pipeline. someday... :) when it becomes imperative to
streamline the text routine for performance reasons, I'll probably attempt
something similar to what Jason suggested for large bodies of text, a word
caching texture builder. I'm just doing alot of UI coding at the moment
and my text routine could definitely be faster, so it seemed like a good
time to revisit the issue. But, in response to the responses...

Herb:
>if you're changing something just to change it, and not either fix a
performance problem or a long->term architecture problem, then don't
change it :)

it's a performance/efficiency thing. I'm a firm believer in "if it ain't
broke, don't fix it." :) Storing bitmaps of text at installation isn't an
option (too much text) and creating all of them at load-time would
dramatically increase the load time. So, I guess it was a little of both,
performance and architecture.

Erwin:
I'm currently using display lists for each character and calling the
appropriate lists depending on what characters are needed. I then render
each string with a single call to glBegin/glEnd.

thanks again everyone!

E.