Use of glDrawPixels for Text in SDL 1.2 and 1.3

For purposes of rendering 2D utility text (e.g., FPS display) with OpenGL, I’ve been using glDrawPixels to render a 2D “overlay layer.” The source for the text pixel data is SDL_ttf 2.0.9. Using an example I found somewhere, I did the following: (1) Create an SDL “text” surface with TTF_RenderUNICODE_Blended; (2) Create an SDL “RGB” surface suitable for OpenGL rendering with SDL_CreateRGB surface; (3) Blit the text surface to the RGB surface with SDL_UpperBlit; (4) Render the pixel data in the RGB surface with glDrawPixels. This worked well … until I tried the same thing with SDL 1.3.

With SDL 1.3, no text was rendered. While debugging, I discovered that TTF_RenderUNICODE_Blended was generating good pixel data. SDL_CreateRGBSurface, likewise, created an apparently good SDL surface. However, after the SDL_UpperBlit, the pixel data in the RGB surface was all zeros.

When I saw the format of the pixel data in the text surface (RGBA, 4-byte pixels), I thought why not render the image data right out of the text surface? That works!

Two questions:

Is my solution a reasonable practice or a dangerous practice?

Can anyone venture a guess as to what was wrong with my original approach and SDL 1.3.

2009/10/16 WaltN :

Two questions:

Is my solution a reasonable practice or a dangerous practice?

Can anyone venture a guess as to what was wrong with my original approach
and SDL 1.3.

Does SDL_DisplayFormatAlpha() still make sense for SDL 1.3?

If so, I’d say use it, then convert your surface to a texture, then blit it.

Kenneth Bull wrote:

2009/10/16 WaltN <@Walt_Niehoff>:

Two questions:

Is my solution a reasonable practice or a dangerous practice?

Can anyone venture a guess as to what was wrong with my original approach
and SDL 1.3.

Does SDL_DisplayFormatAlpha() still make sense for SDL 1.3?

If so, I’d say use it, then convert your surface to a texture, then blit it.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

But isn’t that an additional two copies of the pixel data versus rendering it right out of the TTF-generated surface?

That sounds like a bug in SDL 1.3. Can you create a simple test case
and report a bug here?
http://bugzilla.libsdl.org/

As for using the text surface directly, that’s totally fine. :slight_smile:

Thanks!On Fri, Oct 16, 2009 at 1:15 PM, WaltN wrote:

For purposes of rendering 2D utility text (e.g., FPS display) with OpenGL,
I’ve been using glDrawPixels to render a 2D “overlay layer.” The source for
the text pixel data is SDL_ttf 2.0.9. Using an example I found somewhere, I
did the following: (1) Create an SDL “text” surface with
TTF_RenderUNICODE_Blended; (2) Create an SDL “RGB” surface suitable for
OpenGL rendering with SDL_CreateRGB surface; (3) Blit the text surface to
the RGB surface with SDL_UpperBlit; (4) Render the pixel data in the RGB
surface with glDrawPixels. This worked well … until I tried the same thing
with SDL 1.3.

With SDL 1.3, no text was rendered. While debugging, I discovered that
TTF_RenderUNICODE_Blended was generating good pixel data.
SDL_CreateRGBSurface, likewise, created an apparently good SDL surface.
However, after the SDL_UpperBlit, the pixel data in the RGB surface was all
zeros.

When I saw the format of the pixel data in the text surface (RGBA, 4-byte
pixels), I thought why not render the image data right out of the text
surface? That works!

Two questions:

Is my solution a reasonable practice or a dangerous practice?

Can anyone venture a guess as to what was wrong with my original approach
and SDL 1.3.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


-Sam Lantinga, Founder and President, Galaxy Gameworks LLC

Sam Lantinga wrote:

That sounds like a bug in SDL 1.3. Can you create a simple test case
and report a bug here?
http://bugzilla.libsdl.org/

I will try to reproduce the problem in C. I am writing support for SDL/OpenGL in APL, so, if I gave you my existing code, no one is likely to understand it!