Your game is spending a little over 60% of its time blitting. About
20% is evaluation, and the rest of the work is overhead. That might
seems high given the complexity, but window size really matters when
it comes to software rendering. Decrease the window size to 800x500
(for widescreen) or 640x480 and you'll notice a large performance
boost. The other thing I noticed is that the control code (or
something setting flags that disable it or something) is sort of
crappy. It tends to freeze and jitter even when the frame rate holds
steady.
A quick suggestion might be to drop the onscreen checks for the player
and enemies. There won't be that many of them and it takes longer to
check than it does to draw them. They're not going to draw, the
blitter is coded in C and will figure out much more quickly than your
Python code that it doesn't need to draw anything. If you start
getting hundreds of sprites offscreen, wherever possible, group them
together and test in bulk. Every time you call a function or a method
or get an attribute, you accrue overhead. You want as few loops as
possible and as few tests inside of them as possible.
As a rule in Python, it's almost always faster to do more work
unnecessarily than test to see if you need to. For example, there was
one portion in my code where I had 3 or 4 sets that I needed to ensure
were empty. It was much faster to reassign them to set() than it was
to test if they had anything inside of them.
Another option is to look at OpenGL for graphics. It won't _speed up_
your drawing without some complex optimization, but it will make
sprite size, screen size and number of changed pixels entirely
irrelevant. It also gets you scaling, rotation, blending, and color
tinting effects for free. Since easy, high-performance sprite code
code using Pygame/OpenGL seems pretty hard to come by, I'm thinking of
releasing the base classes I've been writing for my game over the past
week. I've created a glSprite class and a glSpriteObjectGroup
container that holds, updates, and draws OpenGL objects like pygame
sprite groups do. If you're interested, I can give you a copy before
it's finished, if only as an example, if you decide you want to go the
OpenGL route.
-Zack
On Mar 1, 2009, at 3:24 AM, Daniel Mateos wrote:
Peter Gebauer wrote:
How is collision testing done? 200 sprites tested against 200 sprites
is a big difference from just testing 2-3 sprites against 200, in
particular
if you do the iteration in Python.
At the moment only the player char is checked for collisions so its
1:200.
http://github.com/dmateos/paperworld/tree/master is the source if
anyone
cares enough to take a look.
--
Daniel Mateos
http://daniel.mateos.cc
