Yes, that fixed both problems (green and rolling pixels over incorrectly). Thanks...
(on Windows if that matters) ~Ty On Tue, Mar 10, 2009 at 11:02 AM, Brian Fisher <br...@hamsterrepublic.com> wrote: > That's a bug. I think all the BLEND_ stuff was broken like that (where green > is messed up). It should be fixed now, though - can you try a pre-release > build? If you are on windows or Mac, you can get a pre-release build here: > http://thorbrian.com/pygame/builds.php > > on linux though, I think you'd need to build from source. > > > On Tue, Mar 10, 2009 at 7:32 AM, Ty ... <ty.sql...@gmail.com> wrote: >> >> I'm trying to get a fade to black working, to that end I've written a >> simple program just to try it out... the (partial) code looks like >> this: >> >> self.screen.fill(white) >> self.screen.blit(self.image, self.size, self.size) >> print self.screen.get_at((4,4)); >> self.screen.fill((2,2,2), None, BLEND_SUB) >> print self.screen.get_at((4,4)); >> self.screen.fill((2,2,2), None, BLEND_SUB) >> print self.screen.get_at((4,4)); >> self.screen.fill((2,2,2), None, BLEND_SUB) >> print self.screen.get_at((4,4)); >> sys.exit() >> >> And the output... >> >> (46, 46, 44, 255) >> (44, 255, 42, 255) >> (42, 255, 40, 255) >> (40, 255, 38, 255) >> >> To me, it looks like it's working for the R and B components, but for >> some reason G immediately goes to 255 and never changes. Is there >> something I'm doing wrong here? >> >> Also, one other question... how would I get it to stop at (0,0,0) >> rather than wrap around? If I continue the loop for a long time, I >> get output that looks like this... >> >> (8, 255, 6, 255) >> (6, 255, 4, 255) >> (4, 255, 2, 255) >> (2, 255, 0, 255) >> (0, 255, 254, 255) >> (254, 255, 252, 255) >> (252, 255, 250, 255) >> (250, 255, 248, 255) >> >> Which means I've going to have to check that each time and make sure >> no wrap around has occured? I might as well loop through every pixel >> in the image and do this kind of operation myself :P. >> >> Thanks! >> >> ~Ty > >
