Re: [pygame] Effecient way to 'darken' a surface?

[Rene Dudfield <renesd@xxxxxxxxx>]

For pallete graphics it used to be a good idea to swap the palletes
around.  I have't tried that with pygame/SDL though.

This does an approximate - 200.  By shifting.  I'm not sure how fast
it is though...  haven't tested it.   If you could do an inplace right
shift with numeric it'd be faster(not sure if you can do that).

Something like this untested code...
arr = surfarray.pixels2d()
arr[:] = arr >> Numeric.array(2, a.typecode)
# clean up the array so that the surface is unlocked.
del arr



Please let me know if it's faster for you!


Have you tried blitting a black surface with different set_alpha on it?


What I did in one game was to fade the background to black, and keep
the single image in the middle of the screen untouched.  This worked
very fast and achieved a similar effect by making the screen darker. 
Maybe you could get by with just this.

Using this code:

	        c = int( 255 - (255 * (cur_time - start_fade_time) ))
		if c < 0:
		    c = 0
		if c > 255:
		    c = 255


		self.background.fill((c, c, c ))




What you really need is a nonexistant function called
pygame.transform.subtract_color(surf, 200) That takes away from each
of the rgb components and clamps to 0.




On 12/21/05, Knapp <magick.crow@xxxxxxxxx> wrote:
> With my alpha idea I was thinking of having a bunch of backgounds to blend
> with as needed not change ones alpha each time. As was pointed out you will
> only have 255 levels of gray and you might be able to step though them at
> jumps of 8 so you would only need 32 of them or less depending on how dark
> to how light you need to go. I do hope to learn what is the fastest way. I
> was under the idea that this was a whole screen thing. If it is just a tile
> set than make 32 tile sets and have real speed.
>
>  Also untested by me but can't you use refrenced color and change the
> refrence for fast color updates?
>
>
> On 12/20/05, andrew baker < failrate@xxxxxxxxx> wrote:
> > Include instructions to the player to slowly squint his eyes until you say
> stop.
> >
> > Failing that, one quick optimization you might be able to get away with is
> not altering the color every step, but perhaps by 8 or more steps at a time.
>  I'm not sure if that would be not smooth enough a color transform for you,
> though.
> >
> > Also, you make no mention if you are transforming tiles or just one large
> bitmap.  If you are color transforming tiles, then you could probably just
> alter the colors of the source tiles and then blit them, as opposed to
> blitting first, then altering.
> >
> > Kinda hard to tell what would work for you without knowing what the
> overall application is.
> >
> >
> > --
> > Andrew Ulysses Baker
> > "failrate"
>
>