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
