Hi,
The RGB ones just do the RGB channels, but RGBA also does the ALPHA channel
too.
They are simply adding the channels. They don't inspect the alpha channel
to see if they should add that pixel, or do an alpha blend as well as an
additive blend.
These defines show what they do...
#define BLEND_ADD(tmp, sR, sG, sB, sA, dR, dG, dB, dA) \
tmp = dR + sR; dR = (tmp <= 255 ? tmp : 255); \
tmp = dG + sG; dG = (tmp <= 255 ? tmp : 255); \
tmp = dB + sB; dB = (tmp <= 255 ? tmp : 255);
#define BLEND_RGBA_ADD(tmp, sR, sG, sB, sA, dR, dG, dB, dA) \
tmp = dR + sR; dR = (tmp <= 255 ? tmp : 255); \
tmp = dG + sG; dG = (tmp <= 255 ? tmp : 255); \
tmp = dB + sB; dB = (tmp <= 255 ? tmp : 255); \
tmp = dA + sA; dA = (tmp <= 255 ? tmp : 255);
I think what you want is probably something different... that can probably
be done via some other combination of blits though.
cheers,
On Fri, Dec 16, 2011 at 8:10 AM, Florian Berger
<fber...@florian-berger.de>wrote:
> Hi!
>
> Ian Mallett <geometr...@gmail.com>:
> >
> > Simply call .convert_alpha() on each surface after you make your
> > window. This clears up most problems.
>
> I am doing that already. In fact I blit the sprite, so I can see that
> alpha works; then I create a Surface.copy(), manipulate that and blit
> it over the sprite using BLEND_RGBA_ADD.
>
> The result is that the blit incorporates the RGB values of the fully
> transparent pixels and adds them as well, resulting in an ugly square
> around the sprite.
>
> The solution in my case is to make sure that the transparent pixels
> also have a (0, 0, 0) RGB value. But this is annoying. I think this
> calls for a bug report. ;-)
>
> Regards,
> Florian
>
