[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[pygame] Fun with C modules
I've just spent a day converting some of my python classes over to C, with
some fun results.
In a nutshell, my application (ok, game ;) stores a 64x64 map grid, two
triangles per cell, in an octree. This is then culled for the frustum and
rendered as lit and textured triangles. The scene I'm getting the following
results from has 170 of the triangles from the octree being rendered.
I converted my frustum class (which has methods like calculate() and
isCubeInFrustum()), octree class (which just stores away objects with a
vertexes list and a render() method) and a simple lit/textured triangle
object which has the aforementioned vertexes array and render() method. The
python and C modules are functionally identical - they're completely
interchangeable (making this test quite easy :) but the C modules do have
several optimisations. For example, the C triangle class calls OpenGL
directly, not through the python bindings. I suspect my unpacking the
arguments to the gl calls once, when the object is created, has a large
impact...
I took a set of timings (render 100 frames and then time the next 100
frames), turning each of the C modules on and off:
No C: 7fps
C octree: 7fps
C frusum: 8fps
C triangle: 10fps
C octree&frustum: 8fps
C frustum&tri: 11fps
C octree&tri: 26fps
all: 41fps
Well, what strange numbers. At 41fps my "game" is quite playable. Sure, most
of the work is done in a single call to a C module, but Python's still there
holding it all together :)
Richard
ps. I don't have a website at present - I'm between jobs - but I hope to have
something set up soon so I can share this stuff.
____________________________________
pygame mailing list
pygame-users@seul.org
http://pygame.seul.org