Your bottleneck might not be in your rendering code. I don't know wether PyOpenGL is even supposed to be much faster than pygame, but if rendering is not where your bottleneck is, switching will not help at all.
I didn't look at the code, but in the profile it seems _collide_bullet is a frequently used method. Are you using a naive collision detection algorithm? In that case, something like a quadtree or cell-based collision detection approach may heavily improve the performance of your game. Hugo On Sun, Jun 15, 2008 at 10:21 PM, flx <[EMAIL PROTECTED]> wrote: > Hi all > > I've been fidling for some time with pygame on a tryout project [1], > it's a fast 2d action game. > > After a while i switched the drawing code to pyopengl looking for a > litle performance boost, but i haven't got the expected results, i > have had to lower the global fps from 60 to 30 and even then, it lags > with 150-200 sprites on screen. > > I know there must be something wrong with my code because there are > more complicated things drawn with pyopengl. > > This are the first lines of profiling output (switch to monospace font now > ;) ) > 6202178 function calls in 52.748 CPU seconds > > ncalls tottime percall cumtime percall filename:lineno(function) > 148066 6.507 0.000 28.780 0.000 gl.py:114(draw) > 200620 5.532 0.000 27.806 0.000 wrapper.py:650(wrapperCall) > 200616 3.828 0.000 3.828 0.000 numpymodule.py:114(contiguous) > 200616 3.579 0.000 5.622 0.000 numpymodule.py:19(dataPointer) > 766540 2.803 0.000 3.000 0.000 error.py:167(glCheckError) > 440660 2.368 0.000 3.815 0.000 ship.py:60(_collide_bullet) > > code referenced is on [1] or running > svn checkout > http://pyship.googlecode.com/svn/trunk/ pyship < recomended since the > tarbal is several days old and there are some particle and sprite > especific examples on the svn > > [1] - http://code.google.com/p/pyship/ > > -- > .__.ยทยบ(foolhu!) > (oO) > / | | \ >
