I'm still running 1.6 (it's on my machine at work), but when I try to pass in None to set_clip I get segmentation faults. If I just call s.set_clip() I get the expected results:
1.6 <rect(10, 10, 10, 10)> <rect(10, 10, 10, 10)> <rect(0, 0, 800, 600)> So if there's a bug it'd probably be fairly easy to track down. Have you tried just calling the function without any parameters? On 3/15/07, Diego Essaya <[EMAIL PROTECTED]> wrote:
So, any hints about this? Can anyone confirm that this is a bug? If that is the case, I might find some spare time to try to make a patch (no promises here, I have never read the pygame source code :-). I'm getting the same odd behavior on both Linux and Windows versions of pygame, using Python 2.4. Didn't try with 2.5. Thanks! Diego On 3/12/07, Diego Essaya <[EMAIL PROTECTED]> wrote: > > I'm having this problem with the Surface.set_clip() method that appears > to be a bug: > > import pygame > print pygame.__version__ > s = pygame.display.set_mode((800, 600)) > r = pygame.Rect(10, 10, 10, 10) > s.set_clip(r) > print s.get_clip() > r.move_ip(10, 0) > print s.get_clip() > s.set_clip(None) > print s.get_clip() > > This yields the following output: > > 1.7.1release > <rect(10, 10, 10, 10)> > <rect(10, 10, 10, 10)> > <rect(25708, 0, 0, 600)> > > After this, the clip region of the display surface is garbled and > operations on the surface fail. Running the script again yields a different > garbled value. > > I tried modifying the line with set_clip() with: > > s.set_clip(pygame.Rect(r)) > > but this did not solve the problem. > > Is this really a bug, or am I doing something wrong? Also, my apologies > if this has been discussed before. > > Thanks, > Diego > >
