> The only other way I know how to make OpenGL textures is with NumPy, using > the GL_FLOAT token. This may be better for your purposes--although the way > I see it, converting a surface to a texture is going to involve a conversion > no matter which way you do it. Note that it's much faster to *update* a > texture rather than create a new one. If at all possible, this may be your > best opinion to improve speed.
I'm very skeptical that PyOpenGL actually works correctly. On my box (old 2.4 GHz laptop w/geforce 4), the classic nehe lesson 42 (drawing a maze to a texture) python port gives HORRIBLE framerates, judging by eye to be about 5 fps, no matter whether I'm using Python 2.4, 2.5, 2.6, and I've tried repeated reinstalls and upgrades of PyOpenGL. The maze drawing always stops prematurely too, but that may be a logic bug in the ported version. Has anyone else duplicated this problem? The original C version of lesson 42 works at full frame rate. My self-written programs have really bad framerates too, but I barely understand OpenGL so it's possible those are my own fault. Alan
