[SDL] SDL_ttf question

Kostas Kostiadis kos at climaxgroup.com
Mon Jan 17 02:14:35 PST 2005

more efficient in terms of cpu/gpu usage...
At the moment what I'm doing everytime I want to render text is:

create an SDL_Surface (via TTF_Render*_*)
create a texture from the surface (using SDL_CreateRGBSurface,
SDL_BlitSurface, etc.)
enter 2D mode (glOrtho, push attribs, etc.)
render the texture
exit 2D mode
Free the SDL_Surface

which is all based on glfont.c in the example code that comes with SDL_ttf.
This seems like a lot of stuff (but it may all be necessary)...

The only thing I can think of to improve performance is batch all my
render text calls and do them once a tick (so that all the enter/exit 2D
mode, etc.
happen only once).

Also, am not sure how expensive SDL_BlitSurface is (from what I saw in the
it calls SDL_UpperBlit).


-----Original Message-----
From: sdl-bounces+kos=climaxgroup.com at libsdl.org
[mailto:sdl-bounces+kos=climaxgroup.com at libsdl.org]On Behalf Of David
Sent: 17 January 2005 09:52
To: A list for developers using the SDL library. (includes SDL-announce)
Subject: Re: [SDL] SDL_ttf question

On Monday 17 January 2005 09.52, Kostas Kostiadis wrote:
> I'm using both SDL and OpenGL.
> Basicaly, I'm doing all the init stuff and handling input, events,
> timers, etc. via
> SDL, and I'm using openGL for rendering...
> I've based my font code to the glfont.c example that comes with
> the SDL_ttf sources.  Is there a more efficient way than the one
> described there?

More efficient in what way?

If you need lots of text at the same time as other stuff is going on, 
you probably need to render into temporary textures.

For a static overlay, just render it all into an RGBA texture of 
sufficient size. (Remember that some cards may not support 2048x2048 
or even 1024x1024 textures! You may have to do some tiling, or just 
hardwire your code for 256x256 tiles if that's easier.)

For scrolling, handle lines as separate textures and/or quads, or 
whatever suits your needs. The smaller the "tiles", the less texture 
memory you need for off-screen "scroll margin" - but of course, 
there's slightly more overhead.

If you need animated glyphs and stuff (assuming you don't have to 
animate *all* of them), you can just leave the animated glyphs out 
when rendering the static overlay textures, and render them "live" 

Of course, if to animate all glyphs in unison, you can just render one 
overlay texture for each frame, and "page flip" by switching texture 
every N ms or something. Or use color OpenGL modulation and/or 
transformations instead; they're pretty much free once you're in 
there rendering anyway...

I've been meaning to evolve the smoothscroll example into something 
more flexible and usable; a generic OpenGL sub-pixel smoothscrolling 
engine... (You supply a callback that renders the requested area of 
your map into an SDL surface, and the "engine" does the rest, pretty 
much.) That would be usable for scrolling text and overlaying 2D 
graphics on top of 3D or other "native" OpenGL stuff as well, I 
guess. However, that doesn't help much unless I actually get around 
to hack it. :-/

//David Olofson - Programmer, Composer, Open Source Advocate

.- Audiality -----------------------------------------------.
|  Free/Open Source audio engine for games and multimedia.  |
| MIDI, modular synthesis, real time effects, scripting,... |
`-----------------------------------> http://audiality.org -'
   --- http://olofson.net --- http://www.reologica.se ---

SDL mailing list
SDL at libsdl.org

More information about the SDL mailing list