Derek Simkowiak wrote:
I just fired up some code I wrote about a year ago. The PyGame API has changed and now I can't see how to make my PyGame code work again.Derek, wow you've been through a big process here. in the end i've got more questions and want to make sure this is all straight. it sounds like what you are wanting to do should be the default behavior. first we'll create some text with pixel alpha, and xfer that to another surface.
RGBA->RGBA without SDL_SRCALPHAthis is the case that is now broken. this should be enabled again for sure. the whole problem comes down to the fact that SDL support for pixel alphas is pretty weak in my opinion. pygame is trying to help SDL out by covering a few special cases. first SDL will just crash if you blit a SRCALPHA to an 8bit surface. in this case pygame temporarily disables the SRCALPHA. the other problem is when blitting to a destination with SRCALPHA, none of SDL's blitters set the destination SRCALPHA (well, all except the one you've just pointed out). in this case pygame hijacks the blit with it's own built-in blit functions that actually do what you want. this is what has changed and is throwing off your desired effect.
The RGBA data is copied to the destination surface. If SDL_SRCCOLORKEY is set, only the pixels not matching the colorkey value are copied.
source.set_alpha(flags=0)this should never have worked. adding keyword arguments to C functions is an extra step i have not taken on any of the pygame functions.
But the new and "improved" API does not use the named argument "flags". The above code results in this error:
TypeError: set_alpha() takes no keyword arguments
So, unless I pass in an alpha value that is PyNone, SDL_SRCALPHA automatically gets set for me.ah, this is a potentially strange, but no one has been snubbed by it before now. still, it seems it shouldn't effect anything in SDL since if there is no SDL_SRCALPHA flag, SDL ignores all surface and pixel alpha values. in your case, if the surface does have pixel alphas, then the surface alpha is entirely ignored anyway. i'm trying to guess if this is what is the real problem.
"Fine", you say, "just pass in an alpha argument of None and the flags will be left alone". Except that when the alpha argument is None, the value passed to the underlying SDL_SetAlpha() is a default of zero
but i can't argue with that. ahh, unless.. (/me checks code..)Attached is the patch to fix this bug. It makes my code work again.
And now in venting mode, it took me several hours to find and correct this (highly frustrating and very well-hidden) bug. Everytime something like this happens to me it's a matter of some developer deciding he knows better than me what arguments I wanted to pass in. There are two other places in surface.c where flags are "automagically" set. Please, remove that "feature" and just give me SDL from Python. (End venting mode.)derek, sorry this bit ya. in the end here's what set me off on the wrong path. You've found another case where SDL's destination alpha blitting code is surprising. here's the final(?) set of cases.