Re: [pygame] Unexpect blit behavior when using BLEND_ADD

["Brian Fisher" <brian@xxxxxxxxxxxxxxxxxxx>]

the current math I see checked in (where alpha just has the same ops applied as color) would probably be completely incorrect - at least in the use case Rene mentioned....

You mentioned an additive particle system - for that in particular, you would never be doing rgba to rgba anyways - as a particle system that changes all the time, you wouldn't cache it, so you'd be going directly to a display surface. so it would be a case of rgba to rgb (display surfaces don't have alpha, even if 32 bit), so dest alpha would be irrelevant.

also, every time I've ever worked on a game with an additive blend particle system where the source contained alpha data, the desired operation was this:
 destColor = destColor + srcColor*srcAlpha
 destAlpha = destAlpha
meaning srcAlpha was used only to scale the amount of color added. The big reason for that is because now the same art is compatible for traditional mult-blending or additive-blending (doing a little of both can get the best visual result, actually), meaning the artist just uses the same production techniques. If that kind of art was used with pygame's BLEND_ADD it would probably just end up rendering as a big solid colored blob.

I actually think the correct approach is to have the code pick the actual blending maths based on what the src & dest are - namely RGB to RGBA, RGB to RGB, RGBA to RGB and RGBA to RGBA.

On Mon, Apr 21, 2008 at 12:18 AM, René Dudfield <renesd@xxxxxxxxx> wrote:

Hi,

yeah, that may be expected by some... however I think we need to think
about backwards compatibility too.  Or am I mistaken that your change
will break compatibility?

I volunteer to update the docs, and code if you'd like - once we
decide what to do?


For additive particle systems for example(which is the main reason the
code was originally added), you only want to use BLEND_ADD_RGB not
BLEND_ADD_RGBA ... I think.

Maybe the form... BLEND_ADD, could be considered the same as BLEND_ADD_RGB ?

Or we could leave BLEND_* as they are now(for backwards
compatibility), and add things like BLEND_ADD_RGB, BLEND_ADD_RGBA ?

But, for backwards compatibility I think we should aim to keep BLEND_*
working as in the 1.8 release...


Perhaps we should come up with a list of all the blend modes we could
implement in the future?  So we can hopefully get come up with a
sensible list of blend modes.  Possibly basing them off the 255 blend
modes.


So... I think what could be best is:
- keeping current BLEND_* flags as meaning BLEND_*_RGB,
- adding flags BLEND_*_RGBA, and BLEND_*_RGB.
- changing the blitters to do either RGB, or RGBA
- come up with a list of blender flags we might implement in the future.



cheers,

On Mon, Apr 21, 2008 at 4:56 PM, Marcus von Appen <mva@xxxxxxxxxxxx> wrote:
> On, Mon Apr 21, 2008, Rene Dudfield wrote:
>
>  > hrmm, but this changes the behaviour of those blit functions, or adds
>  > separate blend flags?
>
>  It changes the blend flags to take alpha into account. As one usually
>  would expect when reading the docs. I think that this is the best
>  solution until someone goes ahead and fixes the issues and documents the
>  blend flags.
>
>  Regards
>  Marcus
>