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

Re: [pygame] pygame performance limits



The short answer is you don't really have limits. Unless you're doing something slow / inefficient, that would be slow anway. Brute forcing / re-creating surface every frame  / mixing different formats on your surfaces / etc.

Biggest one I'd think is collision detection. You can make your algorithm more efficient / use quadtrees / or probably use a physics module. Depending on the game, that can be overkill.

==
But remember, 'premature optimization, is the root of all evil'.
And when you optimize, use profiling. Because 99% of the slowdown can be in 1% of the code. And you will rarely know where it is, without profiling. This can be true even in simpler code.
==

If you do reach a slowdown, there's a huge amount of modules that you have access to. That causes the slower code to run c-code, and has been optimized by many people ie: PyOpenGL, pybox2d (physics), numpy (for arrays / 3d math / opengl), pygame, etc...

So between optimizing your algorithms ( That you'd have to do in other languages anyway: Not re-allocating textures every frame, or other errors ), using c-code from other libraries, You don't run into much different speed issues than you do in pure c, for most games you'd work on.
--
Jake