Alpha blitting

SDL Development
1

Sent this yesterday, but forgot to set my From. I wasn’t going to
resend it until the approval/rejection came through, but I don’t know
how long that typically takes on this list, so I’ll just risk a
double-post.***

Gah. Spent most of today tracking this down. Mostly because it was
compounding with lots of bugs in my own code; since I knew my code was
so buggy, I didn’t even think that something might be going wrong with
SDL, too.

First, the short:

Blitting from an R8G8B8A8 surface to an R4G4B4A4 (or R5G5B5A1) surface
was losing alpha completely: the whole surface would end up transparent.

Fixed this with the following:

— …/SDL_blit.h 2002-03-06 06:23:02.000000000 -0500
+++ SDL_blit.h 2002-10-19 22:19:40.000000000 -0400
@@ -330,7 +330,7 @@
pixel = ((r>>fmt->Rloss)<Rshift)|
((g>>fmt->Gloss)<Gshift)|
((b>>fmt->Bloss)<Bshift)| \

  •     ((a<<fmt->Aloss)<<fmt->Ashift);          \

  •     ((a>>fmt->Aloss)<<fmt->Ashift);          \

}
#define ASSEMBLE_RGBA(buf, bpp, fmt, r, g, b, a)
{ \

I’m sure that may have been that way for a reason (though there’s no
comment explaining the exception), and that might break other blits,
but it fixed my problem.

Hmm. Now I need to implement resizing (with linear filtering, both
min and mag, preferably supporting wrapping the texture for the filter
as an option) and 32->16 bpp dithering. Is there any decent code out
there to handle these with SDL surfaces? This seems like a wheel.

–
Glenn Maynard

2 
  •     ((a<<fmt->Aloss)<<fmt->Ashift);          \

  •     ((a>>fmt->Aloss)<<fmt->Ashift);          \

Any hints on this? I’d hate to have to maintain a patch for SDL for
this project indefinitely.

Hmm. Now I need to implement resizing (with linear filtering, both
min and mag, preferably supporting wrapping the texture for the filter
as an option) and 32->16 bpp dithering. Is there any decent code out
there to handle these with SDL surfaces? This seems like a wheel.

Well, I’ve implemented a shiny new wheel: ordered dithering. (Now that
I’ve implemented it, I expect to see at least three or four posts from
other people who have done the same; existing wheels never turn up before
the time’s been spent.) It works for the surfaces I’m using, at
least, though it’s probably buggy in the general case, and it could
probably be optimized more. Simplifications and optimizations welcome.
I don’t really want optimizations that make the code unmaintainable,
though; it’s not that time-critical of a function.

I don’t intend to special case pixel formats; it’s not worth the source
bloat. Perhaps a C++ template-driven system could be devised for
generating encodes/decodes for each pixel type, but I’m not up to it
right now.

It certainly takes a lot of code to traverse a surface; the PixelFormat
structure is rather inconvenient. Why were its members not arrays?
(Rloss, Gloss, Bloss, Aloss, instead of loss[4], which is nicely
loopable, and so on.) I’d make my own struct to alias over it, matching
field-for-field, but that could cause problems down the line (if SDL_PF
was reordered, at least; I’m not sure if it could cause alignment issues),
and it would mean a bunch of casts.

It’d be very nice if the loss values were 0 for paletted surfaces,
instead of 8, which would make it represent the palette’s color values.

If the list eats the attachment, it’s at:

http://zewt.org/~glenn/dither.ccOn Sun, Oct 20, 2002 at 03:42:41PM -0400, Glenn Maynard wrote:

–
Glenn Maynard
-------------- next part --------------
A non-text attachment was scrubbed…
Name: dither.cc
Type: text/x-c++src
Size: 6062 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20021022/af0dcf68/attachment.cc

3

Oh thanks for the reminder. It’s in CVS now.

-Sam Lantinga, Software Engineer, Blizzard Entertainment> On Sun, Oct 20, 2002 at 03:42:41PM -0400, Glenn Maynard wrote:

  •     ((a<<fmt->Aloss)<<fmt->Ashift);          \

  •     ((a>>fmt->Aloss)<<fmt->Ashift);          \

Any hints on this? I’d hate to have to maintain a patch for SDL for
this project indefinitely.