[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [pygame] Weird lag

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.


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