[SDL] sRGB alpha blending
david at olofson.net
Sat Feb 26 18:55:06 PST 2005
On Sunday 27 February 2005 00.42, Xavier Joubert wrote:
> Hi David,
> Selon David Olofson <david at olofson.net>:
> > Fixed Rate Pig uses AA for all sprites, and translucency for a
> > good
> > deal of them at that, and still achieves frame rates in the
> > thousands
> > with s/w rendering on my old P-III. I don't think it would be an
> > issue if the alpha blending was a few times more expensive -
> > though
> > it would probably rule out old Pentium and 486 machines.
> Don't forget PC is not the only hardware SDL runs on... Mobiles
> phones are much more limited.
> Furthermore as I already wrote, no game coder ever complained about
> blending in SDL. So, why try to fix something that is not broken ?
Right; correct blending should be an extra feature, not a replacement
for the current method. In fact, just replacing the current algorithm
would break lots of existing code/artwork that relies on the "broken"
> > > I see one way to handle this dilemna : implement a new
> > > SDL_BlitSurfaceAccurateBlending() function that would use sRGB
> > > conversion. This one would of course not be hardware
> > > and so not recommended on hardware surfaces.
> > ...you *can* h/w accelerate this, and much more, with pixel
> > That way, you can do it properly while running in circles around
> > the current s/w blitters.
> I guess so, but since games don't need it, and since painting
> programs don't need speed, why waste time ?
Right. And if you really want that kind of stuff (additive blending,
bump mapping and whatnot) + extreme performance, you should *really*
be talking directly to your 3D API of choice.
Same line of reasoning that makes me want to keep any non-SDL-2D
compliant features out of glSDL, basically; if you need more than a
quick way to speed up your SDL 2D code where OpenGL is available, you
should use OpenGL directly.
That said, this depends on where SDL is going. If the primary target
is to remain mainstream PC, console and similar hardware, I think
support for more advanced blending and transformations will be
required eventually. These features are accelerated by pretty much
anything already (even some handheld devices, it seems), and either
way, the CPU power of your average PC is on a level where even rather
generic s/w fallbacks can deliver playable performance in sensible
Either way, it might still be better to keep this advanced stuff -
that will only work on a few of the many supported platforms, at
least until your average cellphone will happily run Q3A at playable
framerates - in a "separate" lib, or at least as an optional module.
(It has to interact closely with the backend code, so it'll probably
have to be maintained pretty much in parallel with SDL regardless.)
ARL - Advanced Rendering Layer...? :-)
I see two main uses for such a thing:
1) Advanced accelerated rendering on a few supported
targets, such as OpenGL and Direct3D.
2) Powerful toolkit for off-line and less performance
critical rendering, regardless of backend.
Of course, these two could be separated as well, creating one s/w
rendering module that deals only with the "public" SDL API, and one
Advanced Accelerated Rendering module, that pullls in the former for
s/w fallbacks, to avoid code duplication.
//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 ---
More information about the SDL