On 12/23/06, Pete Shinners <[EMAIL PROTECTED]> 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)
