[SDL] alpha blending bug - possible fix?

[Stephane Marchesin]

Daniel F Moisset wrote:

>Recently I posted about a problem with alpha blending that turned out to
>be a problem with the generic blit function when there is no
>acceleration, BlitNtoNPixelAlpha. Alex Volkov pointed me to the
>following comment:
>
>	/* FIXME: for 8bpp source alpha, this doesn't get opaque values
>	   quite right. for <8bpp source alpha, it gets them very wrong
>	   (check all macros!)
>	   It is unclear whether there is a good general solution that doesn't
>	   need a branch (or a divide). */
>	   
>The problem is a precision bug at the ALPHA_BLEND macro:
>
>#define ALPHA_BLEND(sR, sG, sB, A, dR, dG, dB)	\
>do {						\
>	dR = (((sR-dR)*(A))>>8)+dR;		\
>	dG = (((sG-dG)*(A))>>8)+dG;		\
>	dB = (((sB-dB)*(A))>>8)+dB;		\
>} while(0)
>
>you can make a slight correction changing this to:
>
>#define ALPHA_BLEND(sR, sG, sB, A, dR, dG, dB)	\
>do {						\
>    int premultR = (sR-dR)*(A); \
>    int premultG = (sG-dG)*(A); \
>    int premultB = (sB-dB)*(A); \
>    dR += ((premultR>>8)+((A)>>7)+(premultR>>16);	\
>    dG += ((premultG>>8)+((A)>>7)+(premultG>>16);	\
>    dB += ((premultB>>8)+((A)>>7)+(premultB>>16);	\
>} while(0)
>
>That incurs into some extra shifts and adds, but no division or branch.
>The correction is not better on the average (it is slightly worse,
>although the maximum error in the function is the same), but it gives
>equal or much better results at usual alpha values (0, 128, 255)
>
>could this change be introduced? thanks a lot, 
>
>  
>
Is changing (even slightly) the alpha behaviour for one among many alpha 
blitting functions a good idea ?

Stephane