RGBA->RGBA blitting again

MagerValp · November 27, 2003, 4:31am

I’m writing a small font library that prints text to a transparent
overlay, which is then displayed on the screen when a key is held
down. The code works fine as long as the font is stored in a
colorkeyed surface, but when I copy it to an RGBA surface with
SDL_DisplayFormatAlpha for faster blitting, the text itself becomes
transparent. I searched the archives, and I guess this is an old
problem, but this limits me to slow blits with 1-bit alpha and no
anti-aliased fonts. You can see my test code here:

http://www.cling.gu.se/~cl3polof/testalpha.c
http://www.cling.gu.se/~cl3polof/10x12yellow.bmp

Is there a workaround for this?–
___ . . . . . + . . o
|_| + . + . + . Per Olofsson, arkadspelare
o-o . . . o + MagerValp at cling.gu.se
- + + . http://www.cling.gu.se/~cl3polof/

David_Olofson · November 27, 2003, 5:04am

I’m writing a small font library that prints text to a transparent
overlay, which is then displayed on the screen when a key is held
down. The code works fine as long as the font is stored in a
colorkeyed surface, but when I copy it to an RGBA surface with
SDL_DisplayFormatAlpha for faster blitting, the text itself becomes
transparent.

Yes… That’s because RGBA->RGBA blits don’t apply the source alpha
the way you’d expect. (Performance reasons, I guess.)

I searched the archives, and I guess this is an old
problem, but this limits me to slow blits with 1-bit alpha and no
anti-aliased fonts. You can see my test code here:

http://www.cling.gu.se/~cl3polof/testalpha.c
http://www.cling.gu.se/~cl3polof/10x12yellow.bmp

Nice little font, BTW. Reminds me of great old Atari ST and Amiga
games.

Is there a workaround for this?

The easy solution, if you don’t have too much text on the screen, is
to just render directly to the screen. This is how it’s done in Kobo
Deluxe, and the text “overlays” only have a slight effect on the
frame rate on very low end hardware, as far as I’ve seen.

If you need massive amounts of text, you’re probably better off
rendering the overlay surfaces with your own blitting code, that
applies/combines alpha the way you want. If there’s no overlapping,
you could just copy the full pixels from the font surface. Limited
overlapping could be handled by cheating; just or the source and
destination alpha together. Note that if you change the overlay
surfaces frequently, the rendering and RLE decoding/encoding overhead
will become significant.

BTW, don’t ask for a 32 bpp display unless you absolutely need it to
be exactly 32 bpp. If you run that code in windowed mode, or on a
target that can’t switch to 32 bpp, you’ll get a shadow rendering
buffer that is converted and blitted to the screen when you flip. Not
insanely expensive if you’re doing full screen s/w rendering anyway,
but for more normal applications it eliminates any chances of using
h/w accelerated blits.

//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 —On Thursday 27 November 2003 13.30, MagerValp wrote:

Gabriel_Gambetta · November 27, 2003, 5:36am

I’m writing a small font library that prints text to a
transparent overlay, which is then displayed on the screen
when a key is held down. The code works fine as long as the
font is stored in a colorkeyed surface, but when I copy it
to an RGBA surface with SDL_DisplayFormatAlpha for faster
blitting, the text itself becomes transparent. I searched
the archives, and I guess this is an old problem, but this
limits me to slow blits with 1-bit alpha and no anti-aliased
fonts. You can see my test code here:

I had to write a custom blitter and use dst_alpha = max (dst_alpha,
src_alpha)

It’s ugly but it worked at least where I wanted it to work It was
with
fonts, too.

Lic. Gabriel Gambetta
ARTech - GeneXus Development Team
ggambett at artech.com.uy> ----- Original Message -----

From: MagerValp [mailto:MagerValp@cling.gu.se]
Sent: Jueves, 27 de Noviembre de 2003 09:31 a.m.
To: sdl at libsdl.org
Subject: [SDL] RGBA->RGBA blitting again

I’m writing a small font library that prints text to a transparent
overlay, which is then displayed on the screen when a key is held down.
The code works fine as long as the font is stored in a colorkeyed
surface, but when I copy it to an RGBA surface with
SDL_DisplayFormatAlpha for faster blitting, the text itself becomes
transparent. I searched the archives, and I guess this is an old
problem, but this limits me to slow blits with 1-bit alpha and no
anti-aliased fonts. You can see my test code here:

http://www.cling.gu.se/~cl3polof/testalpha.c
http://www.cling.gu.se/~cl3polof/10x12yellow.bmp

Is there a workaround for this?

–
___ . . . . . + . . o
|_| + . + . + . Per Olofsson, arkadspelare
o-o . . . o + MagerValp at cling.gu.se
- + + . http://www.cling.gu.se/~cl3polof/

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

MagerValp · November 27, 2003, 7:18am

“DO” == David Olofson writes:

DO> Yes… That’s because RGBA->RGBA blits don’t apply the source
DO> alpha the way you’d expect. (Performance reasons, I guess.)

Well RGBA->RGBA blits as they are now are basically useless…

MV> http://www.cling.gu.se/~cl3polof/10x12yellow.bmp

DO> Nice little font, BTW. Reminds me of great old Atari ST and Amiga
DO> games.

Heh, thanks. The final font will be released with a BSD license,
together with the rest of my code, so feel free to use it. That copy
there isn’t finished though.

MV> Is there a workaround for this?

Gabriel> I had to write a custom blitter and use dst_alpha = max
Gabriel> (dst_alpha, src_alpha)

DO> If you need massive amounts of text, you’re probably better off
DO> rendering the overlay surfaces with your own blitting code, that
DO> applies/combines alpha the way you want.

I was hoping there was a way of tricking SDL into doing the job for
me, but I guess not. 1-bit alpha is just going to have to do for now.

DO> BTW, don’t ask for a 32 bpp display unless you absolutely need it
DO> to be exactly 32 bpp.

OK. Well, any truecolor mode should work fine. I suppose I should call
SDL_GetVideoInfo and check vfmt instead of just asking for 32.

Thanks!–
___ . . . . . + . . o
|_| + . + . + . Per Olofsson, arkadspelare
o-o . . . o + MagerValp at cling.gu.se
- + + . http://www.cling.gu.se/~cl3polof/

kandjidev_at_yahoo.f · November 27, 2003, 11:33am

Hi, it seems that I really don’t have a clear understanding of theses topics.

Where (a web page) could I find a tutorial about :
RGB & RGBA formats
How transparency if handled in 16 & 24 bits modes ?
How surfaces are handled when in hardware video ?
What are the different pixel formats of several surfaces (the one of a fresh bmp
loaded bitmap, the one of the screen)…

I’m not talking about SDL API calls but a good introduction about 2D computer
graphics…

Thank you

If my answer is not clear, let me know I can reformulate…

David_Olofson · November 27, 2003, 12:23pm

Hi, it seems that I really don’t have a clear understanding of
theses topics.

Where (a web page) could I find a tutorial about :
RGB & RGBA formats

Dunno. The behavior of SDL_BlitSurface() is documented, though, but
you may have to read up on the terms used if you’re not into low
level computer graphics.

How transparency if handled in 16 & 24 bits modes ?

If you’re referring to display video modes, there’s no difference
between 24 and 32 bpp, except that in 32 bpp modes, each pixel has an
extra padding byte to avoid the nasty 3 byte addressing.

In 16 bpp modes, everything has to be scaled down to the lower color
depth, but that’s about it. Note that SDL_DisplayFormatAlpha()
generates 32 bpp RGBA surfaces for anything with an alpha channel,
regardless of the display mode.

How surfaces are handled when in hardware video ?

Alpha blending is done in software on all backends but DirectFB and
(soon) glSDL, AFAIK. Very few 2D APIs support alpha blending.

This is why, if you’re doing a lot of alpha blending and the backend
doesn’t provide accelerated alpha, you should render into a s/w
shadow surface (RGB - not RGBA!) that is then blitted to the display
surface. Alpha blending is a read-modify-write operation, and reading
from VRAM with the CPU is insanely slow on most current hardware.

What are the different pixel formats of several surfaces (the one
of a fresh bmp loaded bitmap, the one of the screen)…

Could be anything… Not sure I understand the question.

Anyway, don’t worry too much about this unless you’re going to touch
pixels directly, ie (application side) software rendering. It’s
relatively easy to make SDL do the Right Thing™ in most cases,
regardless of pixel formats.

I’m not talking about SDL API calls but a good introduction about
2D computer graphics…

Well, in that case, you really need two or three tutorials; something
like:

* The Basics of 2D Software Rendering
	* Pixel Formats and RGB Colors
	* Alpha Blending
	* Pixel Addressing and Alignment
	* Video Subsystems: Accessing VRAM
	* Video Subsystems: Acceleration

* SDL Internals: How is Rendering Done?
	* Display Buffer Management
	* Software Blitting
	* RLE Acceleration
	* Hardware Acceleration

* Advanced Software Rendering with SDL
	* Custom Blitters
	* Procedural Surfaces
	* Dealing with Different Targets

//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 —On Thursday 27 November 2003 20.35, kandjidev at yahoo.fr wrote:

John_Bailo · November 29, 2003, 12:16pm

kandjidev at yahoo.fr wrote:

Hi, it seems that I really don’t have a clear understanding of theses topics.

Where (a web page) could I find a tutorial about :
RGB & RGBA formats
How transparency if handled in 16 & 24 bits modes ?
How surfaces are handled when in hardware video ?
What are the different pixel formats of several surfaces (the one of a fresh bmp
loaded bitmap, the one of the screen)…

I’m not talking about SDL API calls but a good introduction about 2D computer
graphics…

Thank you

If my answer is not clear, let me know I can reformulate…

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

You might want to break down and spring for
the books. As a newbie, I’m working through "Focus on SDL"
fromthe Premier Press Game Development Series and
find it excellent.

Sean_Ridenour · December 1, 2003, 11:36pm

RGBA->RGBA blits are possible, and they can be made to work properly, but
you have to set up both surfaces in a certain way. I’ve posted the code to do
it before. I can’t find the code right now, but it’s on the list somewhere,
if you look back through the archives you should find it.

-Sean RidenourOn Thursday 27 November 2003 8:17 am, MagerValp wrote:

“DO” == David Olofson writes:

DO> Yes… That’s because RGBA->RGBA blits don’t apply the source
DO> alpha the way you’d expect. (Performance reasons, I guess.)

Well RGBA->RGBA blits as they are now are basically useless…