[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[pygame] Update performance




Hi,

In my game I'm at a stage where basic stuff works, but very inefficiently,
du to coding laziness. I now need to go back and clean up some stuff and
optimize where possible.

One thing I have been wondering about is what is the performance gain of
updating only parts of the screen versus updating the whole screen all the
time?

I ususally change only a few rects of the screen, but nevertheless always
update the whole thing with Surface.update() on the toplevel surface.
Works ok, but would it be faster to store the Rects for the updatable
regions and call Surface.update([rects]) instead? It probably is faster,
but how many rects can there be or how big % of the screen should the
rects max cover before updating the whole screen is faster?

Would it be efficient to try to keep some "minimum bounding rect" around
all the rects that I blit, and then update only that bounding rect? If I
for example have the following:

     +--+              +-----+
     |  |   +-------+  |     |
     +--+   +-------+  |     |
                       +-----+

The bounding rect would then be:

     +--+--------------+-----+
     |  |   +-------+  |     |
     +--+   +-------+  |     |
     +-----------------+-----+

Would it be faster to update only the one (slightly bigger) rect, or the
three smaller? Performance gains with the bounding thing would be better
if several of the inner rects are overlapping. But of course there is a
little bit of calculations for each small rect that is blitted, as the
bounding rect needs to be enlarged if necessary.

Any ideas, guys and girls?

--------------------+--------------------------------------------------------
Jan 'Chakie' Ekholm |     Balrog New Media    http://www.balrog.fi/
   Linux Inside     | I'm the blue screen of death, nobody hears your screams

____________________________________
pygame mailing list
pygame-users@seul.org
http://pygame.seul.org