This overflow.. thing (not sure if it should be considered a bug really) happened to me too. I just wrapped the blit call in a try/except block and it was still a lot faster than checking manually.
Of course this was not a game but a fractal renderer, where points could randomly escape far, far away. 2009/2/19 Weeble <clockworksa...@gmail.com> > The one time I got bitten for drawing things off the screen it was for > drawing things *very* far off the screen. I was using the pygame line > drawing methods and scaling the coordinates to do zooming. When I > zoomed in too far the coordinates overflowed from 32-bit integers into > Python's "long" integers, and the pygame methods weren't too happy > about this. However, I think my experience is unusual: I doubt most > games would ever want to draw things so far off the screen while at > the same time having few enough of them that they don't already need > some sort of spatial partitioning system. > > On Tue, Feb 17, 2009 at 2:55 PM, Daniel Mateos <dan...@mateos.cc> wrote: > > Hey All, > > > > I was just wondering if i can count on Surface.blit dealing with stuff i > > pass it that has co-ords greater than its drawable area like say i pass > > a rect of [200, 195, 10, 10] to a surface of size [200, 200]. > > > > I ask because i notice it is working right now as expected with a > > function i use that only roughly checks if something is on the screen or > > not before it is blited and im not sure if i should bother to make it > > more accurate. > > > > Daniel > > >
