Re: [pygame] Weird lag

[Daniel Mateos <daniel@xxxxxxxxx>]

Zack Schilling wrote:
> 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.
Yeah my control code needs some work :), and i did increase the window
size recently and thats probably when i noticed the performance issues
so you could be right.
>
> 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.
Ah yeah i was aware that blit does that but i wasn't quite sure what
would be more efficient, coming from c/c++ its amazing how fast you can
get stuff done in python :) but yeah ill have to be more careful with
not going to crazy with checks and crap.
>
> 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
>
Yeah OpenGL is what i plan on getting into next after a bit more SDL
practice.


Thanks for the reply, was very informative.

-- 
Daniel Mateos
http://daniel.mateos.cc