Re: [pygame] SDL vs. Pygame: Alpha Differences

["Brian Fisher" <brian@xxxxxxxxxxxxxxxxxxx>]

On 12/23/06, Pete Shinners <pete@xxxxxxxxxxxx> wrote:
> Yes, SDL has a special blitter for blending alpha to alpha.
I assume you meant pygame has a special blitter - you mean
pygame_AlphaBlit, right?

> You can work
> around this by disabling the SRC_ALPHA flag on the source. then it will
> work the same as SDL.
I think you mean you work around this by clearing the SRC_ALPHA flag
on the dest, not clearing it on the source....

the thing Kamilche wanted was to blit a 32 bit to a 32 bit with
SRC_ALPHA on the source and go through to SDL, so that SDL would do
the blending using the SRC_ALPHA, but not write to the dest alpha.

If you turn off SRC_ALPHA on the source, then SDL doesn't alpha blend
the color and instead copies pixels (including the alpha)... but from
looking at pygame's surface.c it seems you can get at SDL's blit if
the dest doesn't have SRC_ALPHA


----
... also, about the pygame special alpha blit... looking at the code
in surface.c it looks like it doesn't do anything very useful - it's
not a pixel copy (like SDL does with SRC_ALPHA off on the source), and
it's not decaling, or doing a color blend that preserves dest alpha
(like SDL does when the source doesn't have SRC_ALPHA), and it's not
something that does proper compositing cause it gets the color
saturation all wrong when the original dest alpha is not 0 or 255 (the
easy way to see the code is wrong is that ALPHA_BLEND doesn't consider
the original dest alpha when blending the color).

so what is it that it is trying to be? Is it trying to composite
correctly? (i.e so that blitting a->b then b->c is the same as b->c
then a->c). Cause if that's what it's supposed to do, I would be
delighted to help fix it...  (it looks like it gets the final alpha
value correct for compositing, it just needs to make the dest
contribute to the final color proportional to the part of the final
alpha value that came from the dest)