[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