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,
D.
PS: I tested the formula separately an it works, but have not tried
merging the above into SDL. perhaps something needs to be fixed first
Cheers,
D.–
Except - Free Software developers for hire - http://except.com.ar