[SDL] sRGB alpha blending

[David Olofson]

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.

Good point.


> Furthermore as I already wrote, no game coder ever complained about
> current 
> 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" 
blending.


> > > 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 
accelerated,
> > > and so not recommended on hardware surfaces.
> > ...you *can* h/w accelerate this, and much more, with pixel 
shaders.
> > 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 
resolutions.

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 ---