[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [pygame] SDL vs. Pygame: Alpha Differences

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 <brian@xxxxxxxxxxxxxxxxxxx> wrote: 
On 12/24/06, Kamilche <kamilche@xxxxxxxxxxxx> 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)