According to the documentation, SDL_DisplayFormat() converts
a surface for the fastest posible blitting. On the other hand,
we have RLE blitting for color-keyed images.
Would it be possible to make an even faster format while
supporting [more than 1 bit] alpha?
Ideally, this format would encode each scanline as runs of 1)
empty pixels, 2) opaque pixels, 3) pixels with intermediate
alpha. For cases 2) and 3) the format would have either a 8 bit
index and an 8 bit alpha or 24 color bits and an 8 bit alpha.
Would this be faster than plain alpha blitting?
Yes - and looking at the performance improvement when using RLE on
alpha surfaces (antialiazed sprites and stuff), I’m quite certain
that SDL is already doing what you suggest.
For example, the rounded framework with shadows and glass highlights
in Kobo Deluxe is a single RGBA surface that’s blitted over the
playfield after rendering each frame. Doing that without RLE results
in a terrible frame rate even on P-II+ CPUs (tried it), but as it is,
it’s actually the fastest way to do it. Fully transparent pixels are
skipped and opaque pixels are just copied.
About a paletted image, isn’t a palette lookup and a write faster
than a full 24/32 bit read and a 24/32 bit write? The 768 byte
palette should fit in the cache and using 8bpp values should mean
that image data is read 3x/4x faster.
Maybe on reasonably modern CPUs… (Fast cores + relatively slow
The problem is that each palette entry will have to be 4 bytes for
24/32 bpp, which means the palette is about as large as a 56x55
surface. So, unless you do this only for large surfaces or have lots
of surfaces share the same physical palette, you’re going to lose
even if the code is memory bound.
I’m sorry if this is
completely wrong, I don’t have much experience with optimizing
cache usage. Please clarify.
Well, it’s pretty simple in this case actually; for the cache to do
any good, you have to use the cached palette data several times -
which means the total size of the palette and the image data must
be smaller than the corresponding 24/32 bpp image.
Further, unless you explicitly tell the cache controller to fetch the
entire palette before you use it, the access palette pattern (which
depends on the image data) may screw things up, making things slower
than a plain 24/32 bpp blit even if the latter touches more memory.
I know very few formats, if any (some TGA format?) support a 8bpp
indexed image and 8 bit alpha. AFAIK GIF and PNG support paletted
images only with 1 bit alpha.
GIF doesn’t support alpha at all AFAIK; only colorkey transparency.
Dunno about PNG… It seems like GIMP won’t even let you create a
palettized image with an alpha channel in it’s internal format, so I
can’t try it either.
However, one could take a 32 bit PNG,
split it into a 24 bit BMP (colormap) and an 8 bit BMP (alpha),
quantize the colormap BMP and store both.
Had to hack a tool to do that for some editing tool for The Sims,
BTW… That was just because the editing tool lacked this obvious
feature, but it suggests that The Sims use some kind of 8 bit
palettized + 8 bit alpha format internally.
//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 Wednesday 31 March 2004 17.29, Gabriel Gambetta wrote: