I'm not sure ctypes is sufficient for everything you can do with OpenGL, but I don't know.
/Peter On 2009-03-16 (Mon) 13:00, Forrest Voight wrote: > Would writing a replacement for PyOpenGL in C instead of in Python > with ctypes help? I think it really would ... PyOpenGL is internally > pretty complex, sometimes when I get tracebacks the error is 5 or 6 > levels into PyOpenGL. Even a C library that only implemented the > common functions and relied on PyOpenGL for the constants and > functions that do complex things like handling strings would probably > help a lot. > > On Fri, Feb 27, 2009 at 11:19 AM, Peter Gebauer > <[email protected]> wrote: > > Hi! > > > > I've done a few sprite thingies in OpenGL here are some pointers: > > > > Afaik display lists and VBO's can't bind different textures (?) > > per list/array. You can't animate lists by changing texcoords > > independently per element, so no go. VBO's have texture coords, > > but only one texture. Again, I'm no expert, might be wrong. > > > > With the quad aproach you should try > > to make the number of calls as few as possible. If you get > > rid of the push and translate for each sprite you'll get some > > extra speed. Try positioning each quads directly. The downside > > with sharing matrix over all sprites is the obvious lack of > > using OpenGL transformations, but some vector math aplied to > > the quads has been faster for me than having one transformed > > matrix per quad. > > > > Since I haven't been able to animate a list/vbo with independent > > textures and texture coords for each element/buffer object I've only > > used it for backdrops. The speed increase is tremendous. > > I also partition the elements so only one list/vbo is displayed per > > visible section, if you're screen display is smaller than the > > entire scene, this helps even more. > > > > If you put all your sprites and their animation frames into one > > big texture you could use VBO's, but I've never had the tenacity > > to try that aproach. > > > > Another way to increase speed is to write an opengl rendering engine > > in C and call and make it available as a Python extension. This is > > a major speed boost, in particular for a large number of iterations. > > Iirc PyOpenGL bindings are generated, many times this is suboptimal > > code for what you're trying to do, writing the Python extension in C > > manually have been faster for me many times. This is indeed true > > if you put your iterations inside a C loop instead of calling the > > C function from Python many times. > > > > In any case, still waiting for that OO 2D game engine with tons of > > OpenGL features and effects, including simple things like frame animation, > > LERP-like features and a simple 2D scenegraph. No luck yet, all attempts > > I've tried so far lack at least one "must have" feature. :) > > > > /Peter > > > > On 2009-02-26 (Thu) 11:29, Casey Duncan wrote: > >> Immediate mode calls (glVertex et al) are the very slowest way to use > >> OpenGL. In fact they are deprecated in OpenGL 3.0 and will eventually be > >> removed. > >> > >> The display list is better as you discovered, but you still are making a > >> few OpenGL state changes per sprite, which is likely slowing you down. > >> Also there is some overhead for the display list call, which makes them > >> sub-optimal for just drawing a single quad. > >> > >>> glPushMatrix() > >>> glTranslate(self.positionx,self.positiony,0) > >>> glCallList(self.displist) > >>> glPopMatrix() > >> > >> You really need to batch the quads up into a few vertex arrays or vbos > >> to stream them to the card in one go. pyglet has a high-level python > >> sprite api that automates this for you fwiw. > >> > >> -Casey > >> > >> On Feb 26, 2009, at 11:04 AM, Zack Schilling wrote: > >> > >>> I know the PyOpenGL mailing list might be a better place to ask this > >>> question, but I've had a lot of luck talking to the experienced people > >>> here so I figured I'd try it first. > >>> > >>> I'm trying to migrate a game I created from using the Pygame / SDL > >>> software rendering to OpenGL. Before attempting the massive and > >>> complex conversion involved with moving the whole game, I decided to > >>> make a little test program while I learned OpenGL. > >>> > >>> In this test, I set up OpenGL to work in 2D and began loading images > >>> into texture objects and drawing textured quads as sprites. I created a > >>> little glSprite class to handle the drawing and translation. At first > >>> its draw routine looked like this: > >>> > >>> glPushMatrix() > >>> glTranslate(self.positionx,self.positiony,0) > >>> glBindTexture(GL_TEXTURE_2D, self.texture) > >>> glBegin(GL_QUADS) > >>> glTexCoord2f(0, 1) > >>> glVertex2f(0, 0) > >>> glTexCoord2f(1, 1) > >>> glVertex2f(w, 0) > >>> glTexCoord2f(1, 0) > >>> glVertex2f(w, h) > >>> glTexCoord2f(0, 0) > >>> glVertex2f(0, h) > >>> glEnd() > >>> glPopMatrix() > >>> > >>> Note: self.texture is a texture ID of a loaded OpenGL texture object. > >>> My sprite class keeps a dictionary cache and only loads the sprite's > >>> image into a texture if it needs to. > >>> > >>> I'd get maybe 200 identical sprites (same texture) onscreen and my CPU > >>> would hit 100% load from Python execution. I looked into what could be > >>> causing this and found out that it's probably function call overhead. > >>> That's 14 external library function calls per sprite draw. > >>> > >>> The next thing I tried was to create a display list at each sprite's > >>> initialization. Then my code looked like this: > >>> glPushMatrix() > >>> glTranslate(self.positionx,self.positiony,0) > >>> glCallList(self.displist) > >>> glPopMatrix() > >>> > >>> Well, that's nice, down to 4 calls per draw. I was able to push ~500 > >>> sprites per frame using this method before the CPU tapped out. I need > >>> more speed than this. My game logic uses 30-40% of the CPU alone and > >>> I'd like to push at least 1000 sprites. What can I do? I've looked into > >>> passing sprites as a matrix with vertex arrays, but forming a proper > >>> vertex array with numpy can sometimes be more trouble than it's worth. > >>> Plus, I can't swap out textures easily mid-draw, so it makes things > >>> much more complex than the simple way I'm doing things now. > >>> > >>> Is there any design pattern I could follow that will get me more speed > >>> without sending me off the deep end with complexity. > >>> > >>> Thanks, > >>> > >>> Zack > >
