Actually, come to think of it, it might be a good idea to add a function that has the expected effect. Essentially the optimized C equivalent of:
def naive_fill(self, color, rect, flags): blit_me = pygame.Surface(rect[2:]) blit_me.fill(color, None, flags) self.blit(blit_me, rect) Not sure what you'd call it, though. -FM On 8/30/08, Charlie Nolan <[EMAIL PROTECTED]> wrote: > It's a bit confusing at first, until you realize what fill is: It's a > way to set large numbers of pixels to the same value, completely > ignoring whatever was there before. Since this is a write-only, > no-decision operation, it's very fast. The flags are just extra > attributes that you're setting, beyond the normal RGBA. > > The correct method is, as you discovered, to blit another surface onto > the first one. Alternatively, you could try iterating through a > surfarray, which might be faster, since you don't have to read another > surface. > > -FM > > On 8/29/08, Ron Dippold <[EMAIL PROTECTED]> wrote: >> This is pygame 1.8.1 on WinXP, DX9. >> >> I'm trying to dim the entire window for a pause screen. It seems like the >> logical way to do this would be to >> >> # screen = pygame.display.set_mode( (800,600), 0 ) at start of >> program >> screen.get_surface().fill( (100,100,100), None, BLEND_MULT ) >> >> but this results in everything being turned hideously green/cyan (and not >> dimmer at all). It doesn't seem to matter whether I use BLEND_RGB_MULT, >> BLEND_RGBA_MULT, or even ADD/SUB instead of MULT, or specify the rect >> instead of None. >> >> What does work is to do: >> dim = pygame.Surface( screen.get_size() ).convert() >> dim.fill( ( 100, 100, 100 ) ) >> screen.blit( dim, (0,0), None, BLEND_MULT ) >> which does exactly what I'd expect. >> >> Am I missing something on the .fill method? I can use the workaround, so >> this is just curiosity. >> >> Ron >> >> >> >> >