There is the BLEND_ADD blitter with pygame 1.8. This leaves the dest alpha alone, and just adds the color from the source image. These blitters aren't very optimized - but still fairly fast C.
I wanted to modify the surface.fill method to also have these extra blend flags, but never got around to it. That would allow you to really quickly add/sub/mult different colors. Which is handy for lighting functions. It's much faster because you don't need to read two bits of data, just add the same color to each pixel. So it requires half the memory bandwidth. Maybe for the next release. On 12/24/06, Brian Fisher <[EMAIL PROTECTED]> wrote:
On 12/24/06, Kamilche <[EMAIL PROTECTED]> wrote: > The problem is this: Let's say the above worked. I still have to compose > the desired sprites into a temporary buffer, apply the night with the > special blit, then blit them out of that temporary buffer onto the final > buffer. Those two extra blits are killing the speed. > well even if you are seeing a huge frame rate hit when you are doing some effect every frame, you still might be able to get great run-time performance by caching the effect's intermediate steps in the app you are building how often does the night darken things enough that you can notice the change? To explain what I mean - If it took say 5 minutes to go from day to completely pitch black, that would mean that there would be more than a second between times where the result of the effect would change at all (5 min * 60 sec/min / 256 color values = 1.17 seconds/color value change. So maybe the darkened temp copies can be reused enough to make it run well? > That special blit would still be nice, but it's not a showstopper, > because there's several methods around it, including Brian's and a > couple of others I've used. > If there was a special blit that might be able to help, I would think it would be colorized blit - where as you blit the source color & alpha is multiplied by a blending color & alpha, and that product is what is used for blending to the dest. A colorized blit would probably be significantly slower than a normal 32->24 blit, but would still be much faster than making surface copies and modifiying them (FYI, openGL can do colorized blits with absolutely no speed penalty at all on the vast majority of hardware by setting the color of vertices)
