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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> > 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 > > >
