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 <clockworksaint@xxxxxxxxx
<mailto:clockworksaint@xxxxxxxxx>>
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 <daniel@xxxxxxxxx>
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
>