SDL_OPENGLBLIT and alpha

SDL Development
1

Can someone please tell me how I can modify testgl.c using -logo so the
"logo" or icon is transluecuent (i.e. 50% alpha) when its blitted on the
screen? I basically want to know how I can blit an SDL surface on top of
OpenGL view using the SDL_OPENGLBLIT flag with the option of having portions
of it using alpha. Is this possible to set the global alpha for that
surface, or does it use per-pixel? And curious, if it is using per-pixel
alpha transparency, which I dont see how it would get any of that data from
a .BMP file, how would I go about modifying that?

I tried all sorts of things to get it to work, without any luck, including
setting the bpp to 16 bit, or 32, trying to set image using SDL_SetAlpha,
anything I could think off. I either mess it up so its a solid white block,
or it just draws it normally.

Please no preaches about using a billion multiple textures as the preferred
way of doing this type of thing, I’m aware of it and plan on doing it at a
later date like when I dont have a full-time job. I’m also a newbie at this
:slight_smile:

Also, I am using the latest SDL snapshot that Sam posted on 3/4.

Thanks
Matt Johnson

2

Can someone please tell me how I can modify testgl.c using -logo so the
"logo" or icon is transluecuent (i.e. 50% alpha) when its blitted on the
screen? I basically want to know how I can blit an SDL surface on top of
OpenGL view using the SDL_OPENGLBLIT flag with the option of having portions
of it using alpha. Is this possible to set the global alpha for that
surface, or does it use per-pixel?

no you can’t have per-surface alpha on an SDL_OPENGLBLIT screen surface
since it already has an alpha channel

And curious, if it is using per-pixel
alpha transparency, which I dont see how it would get any of that data from
a .BMP file, how would I go about modifying that?

use SDL_image and a format that supports an alpha channel (TGA or PNG).
You can also set the alpha in several ways - set the alpha
channel of each pixel in the region of interest to 50%.

An easier way would be to convert your image with SDL_DisplayFormatAlpha()
(which adds an opaque alpha channel), and before you blit it to the
destination, use SDL_FillRect on the destination rectangle on the screen
to fill it with a 50% opaque pixel (use SDL_MapRGBA). Since blits
without SDL_SRCALPHA set preserve the destination alpha this should do
what you want

3

And curious, if it is using per-pixel
alpha transparency, which I dont see how it would get any of that data
from

a .BMP file, how would I go about modifying that?

use SDL_image and a format that supports an alpha channel (TGA or PNG).
You can also set the alpha in several ways - set the alpha
channel of each pixel in the region of interest to 50%.

An easier way would be to convert your image with SDL_DisplayFormatAlpha()
(which adds an opaque alpha channel), and before you blit it to the
destination, use SDL_FillRect on the destination rectangle on the screen
to fill it with a 50% opaque pixel (use SDL_MapRGBA). Since blits
without SDL_SRCALPHA set preserve the destination alpha this should do
what you want

Curious, why would I do this? If I’m trying to blit an image onto the
SDL_OPENGLBLIT screen surface, why would blitting a rectangle help? I’d need
to blit the image itself at that opacity. I mean, I can see how this might
work for a HUD, where I am supposed to blit a solid color at some
transparency. But… if I wanted the whole image be translucent…

I dunno, I probably should just be using textures. Everything has to be a
pain doesnt it :slight_smile:

Matt

4

Curious, why would I do this? If I’m trying to blit an image onto the
SDL_OPENGLBLIT screen surface, why would blitting a rectangle help? I’d need
to blit the image itself at that opacity. I mean, I can see how this might
work for a HUD, where I am supposed to blit a solid color at some
transparency. But… if I wanted the whole image be translucent…

oops, won’t work unless you blit with SDL_SRCALPHA, sorry. No you probably
have to do it manually or load the image from a file with an appropriately
set alpha channel

5

An easier way would be to convert your image with SDL_DisplayFormatAlpha()
(which adds an opaque alpha channel), and before you blit it to the
destination, use SDL_FillRect on the destination rectangle on the screen
to fill it with a 50% opaque pixel (use SDL_MapRGBA). Since blits
without SDL_SRCALPHA set preserve the destination alpha this should do
what you want

Curious, why would I do this?

You need to set the alpha channel of the “screen” surface. By default it’s
opaque, so even if you blit a translucent image onto the “screen”, when the
texture is updated it will still be opaque. Look at the SDL_BlitSurface()
entry in SDL_video.h for more information on the semantics of alpha in blits.

See ya,
-Sam Lantinga, Lead Programmer, Loki Entertainment Software

6

Ok, Im not sufficiently satisfied with this solution. Now I dont care about
the extra work required, I just want to do it the right way.

It would seem the appropiate way of blitting a large 2d “skin” over a 3d
game is to simply render the 2d bitmap to a surface, and to splice up that
surface into the largest 2^N texture size possible (i.e. 16x16 or 128x128)
for each portion and texture map each of those portions into a quad… Now,
I’d assume (hope) there is no distortion when having a bunch of images
spliced up and adjacent (square) quads. Assuming each quad hasnt been
resized, rotated, or scaled and at the exact same thing as the original
bitmap, is this a reasonable assumption to make that there will indeed no
distortion? (kind of like designing a webpage by breaking a large image into
a lot of smaller ones).

The reason of splicing it up,of course, is texture size limit… Apparently
you cant have textures larger than 128x128 with a Voodoo3, or certain ratios
like 1:8 (16x128)? What are the implications of having lots of little
textures that arent even updated that often? Are there any example programs
that utilize some sort of HUD or something? I cant find any on Nehe,
Gamedev or Flipcode. I also heard something about overlays but I’m at a loss
when it comes to exactly what those are.

Thanks
Matt

Curious, why would I do this? If I’m trying to blit an image onto the
SDL_OPENGLBLIT screen surface, why would blitting a rectangle help? I’d
need

to blit the image itself at that opacity. I mean, I can see how this
might> >work for a HUD, where I am supposed to blit a solid color at some

transparency. But… if I wanted the whole image be translucent…

oops, won’t work unless you blit with SDL_SRCALPHA, sorry. No you probably
have to do it manually or load the image from a file with an appropriately
set alpha channel

7

Ok, Im not sufficiently satisfied with this solution. Now I dont care about
the extra work required, I just want to do it the right way.

It would seem the appropiate way of blitting a large 2d “skin” over a 3d
game is to simply render the 2d bitmap to a surface, and to splice up that
surface into the largest 2^N texture size possible (i.e. 16x16 or 128x128)
for each portion and texture map each of those portions into a quad… Now,
I’d assume (hope) there is no distortion when having a bunch of images
spliced up and adjacent (square) quads. Assuming each quad hasnt been
resized, rotated, or scaled and at the exact same thing as the original
bitmap, is this a reasonable assumption to make that there will indeed no
distortion? (kind of like designing a webpage by breaking a large image
into a lot of smaller ones).

Seems like it - provided you disable filtering when rendering the surface.

If you want filtering, you have to leave at least one pixel outside the
texture source rect for each quad, and fill that border with data from the
adjacent rects. (That is, if you rendered all quads with the same
texture/screen resolution ratio, but rendered the full texture size, you’d
get a 2 pixel overlap between tiles.)

The reason of splicing it up,of course, is texture size limit… Apparently
you cant have textures larger than 128x128 with a Voodoo3, or certain
ratios like 1:8 (16x128)?

(IIRC, it’s 256x256, but I’m not sure… Still too small, though.)

What are the implications of having lots of
little textures that arent even updated that often?

You might exhaust the texture RAM, forcing some textures to be rendered
from system RAM - which may mean that it has to be done without h/w
acceleration on some cards, and nearly always means that it’s significantly
slower than rendering from real texture RAM.

Are there any example
programs that utilize some sort of HUD or something?

An SDL_Console version with OpenGL support was released a few days ago, IIRC.
(Can’t seem to find the post, though…)

//David

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------> http://www.linuxaudiodev.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -'On Monday 05 March 2001 20:47, Matt Johnson wrote: