[SDL] 2D API evolution (SDL 1.3/2.0)

[René Dudfield]

For the blending modes we did for 8 bit, 15/16 bit, 24 bit and 32 bit
it was not much code.  Most of the code could be put in macros, and
then for each different type of blending mode it's just an extra
couple of lines.

eg.

#define BLEND_ADD(sR, sG, sB, sA, dR, dG, dB, dA)  \
    dR = (dR+sR <= 255 ? dR+sR: 255); \
    dG = (dG+sG <= 255 ? dG+sG : 255); \
    dB = (dB+sB <= 255 ? dB+sB : 255); \

Then you can add special case ones for each bit depth for better speed... eg.

#define BLEND_ADD4(S,D)  \
    tmp = (D) + (S);  (D) = (tmp <= 255 ? tmp: 255); \



Then I have one function to do all of the blits made up from macros.
For each blend mode you have one case statement.

        case PYGAME_BLEND_ADD: {
            BLEND_TOP_4;
            BLEND_ADD4(*src,*dst);
            BLEND_START_GENERIC;
            BLEND_ADD(sR, sG, sB, sA, dR, dG, dB, dA);
            BLEND_END_GENERIC;
            break;
        }


src/alphablit.c is the file in pygame subversion if you want a look.



On 8/18/06, David Olofson <david at olofson.net> wrote:
> On Thursday 17 August 2006 18:14, Torsten Giebl wrote:
> > Hello !
> >
> >
> > > Implementation? :)
> > > Adding a feature to the existing software blitters is a daunting
> > > prospect, since the complexity increases exponentially.
> >
> >
> > Are the Blitters itself complicated or is it
> > complicated to get the best optimum as possible ?
>
> Well, the SDL blitters can never really be trivial, simply because
> there are quite a few required features to implement to make a useful
> backend. The supported permutations of alpha blending, full surface
> alpha, colorkey and RLE acceleration in SDL 1.2 already result in a
> bunch of specific cases that you pretty much have to implement
> specifically for anything like usable performance. Multiply that with
> three more blending modes, then multiply with three types/levels of
> scaling, and then... well, you get the idea. :-)
>
> Now, if you want eliminate all unnecessary conditionals and expensive
> flexibility in inner loops, there are even more dimensions to add.
> Just for starters, everything will have to come in versions for at
> least 8 bit, 15/16 bit, 24 bit and 32 bit pixel formats. Add real
> time dithering (so that dithering can work with transforms, without
> throwing in an intermediate rendering buffer with higher bit depth
> than the display), and you'll need support for a bunch of useful
> combinations, such as 32->15/16, 24->15/16, 32->8 and 24->8.
>
> Basicall, you don't even have to dive into the tricky details of
> actually optimizing the various permutations. The number of
> permutations alone quickly explodes into insane proportions.
>
>
> //David Olofson - Programmer, Composer, Open Source Advocate
>
> .-------  http://olofson.net - Games, SDL examples  -------.
> |        http://zeespace.net - 2.5D rendering engine       |
> |       http://audiality.org - Music/audio engine          |
> |     http://eel.olofson.net - Real time scripting         |
> '--  http://www.reologica.se - Rheology instrumentation  --'
>
> _______________________________________________
> SDL mailing list
> SDL at libsdl.org
> http://www.libsdl.org/mailman/listinfo/sdl
>