Hi! Iirc, Pyglet doesn't do animations for textures? That is, changing the texture based on a preset time scale.
/Peter On 2009-03-19 (Thu) 08:36, Casey Duncan wrote: > You should check out how pyglet uses VBOs (and vertex arrays as a > fallback) for its batched sprite engine. It also has some pretty keen > texture atlas support to reduce texture state changes. > > -Casey > > On Mar 19, 2009, at 8:03 AM, Peter Gebauer wrote: > >> Hi casey! >> >> Yeh, unfortunately, I haven't found any smart ways to use retained >> mode >> for 2D graphics engines. Even if you do use VBO's in stream mode you >> have >> to update the data every frame, i.e a Python call that makes C calls, >> all >> those array structs have to be converted from Python types to C types >> eventually as well. Also, changing textures requires immediate mode >> calls. >> From what little I know about it, my guess is that a C extension is >> way faster than ctypes and SWIG generated code. >> >> SWIG makes sense for an entire scenegraph written in C, the scenegraph >> is retained in itself and will accept your data, including animations, >> and continously executing it for you. >> >> What most people want is a fast and simple scenegraph, that is >> avoiding >> shaders and the intricate details of opengl. >> If you have solution for multiple textures in one VBO that does not >> use shaders and >> works in retained mode, please do share. I've been looking for ages. >> With multiple textures I mean the ability to glBindTexture in retained >> mode, not the use of multi textures. >> >> /Peter >> >> >> On 2009-03-17 (Tue) 21:43, Casey Duncan wrote: >>> With the emphasis these days on batch operations (VBOs, etc) and >>> doing >>> more and more of the work on the video card itself via shaders, I >>> seriously doubt that the bottleneck of a well-written, modern >>> PyOpenGL >>> application will be the ctypes overhead. The only time I could see >>> that >>> could be would be for immediate mode usage, which is deprecated >>> anyhow, >>> for the simple reason that per-vertex operations no longer mesh well >>> with >>> a modern graphics architecture. >>> >>> If you are not writing a modern OpenGL app, then by all means, use >>> the >>> old version. It's going to be a while I think before cards drop >>> support >>> OpenGL 2 and earlier features. It will happen eventually though. >>> >>> There are significant maintenance advantages to ctypes over C- >>> wrappers, >>> generated by SWIG or otherwise. It is difficult to make the latter >>> work >>> well across platforms and python versions. If you've ever looked at >>> the >>> build system for PyOpenGL 2.x, you'd understand what I mean. And >>> this is >>> coming from somebody who enjoys writing C extensions, but for >>> wrapping >>> existing APIs, ctypes is the state of the art. Like Python itself it >>> trades execution speed for development efficiency and better >>> portability. >>> >>> PyOpenGL is more or less a one man project afaik, and let me tell >>> you, >>> development efficiency rules when you're trying to move mountains >>> yourself. >>> >>> -Casey >>> >>> On Mar 17, 2009, at 7:37 PM, Richie Ward wrote: >>> >>>> why did they not make 3.0 with swig? >>>> >>>> On Tue, Mar 17, 2009 at 12:26 PM, RB[0] <roeb...@gmail.com> wrote: >>>>> http://groups.google.com/group/pyglet-users/msg/832b15389fccd28d? >>>>> pli=1 >>>>> >>>>> Hmm, this is a bit outdated, but I found a few other references >>>>> that >>>>> say >>>>> SWIG will generally be faster to run, though would have more >>>>> overhead - so I >>>>> dunno. >>>>> >>>>> HTH >>>>> >>>>> On Tue, Mar 17, 2009 at 7:17 AM, RB[0] <roeb...@gmail.com> wrote: >>>>>> >>>>>> I saw saw tests for performance between the old C PyOpenGL and the >>>>>> new >>>>>> ctypes one... >>>>>> The older one was significantly faster from what I saw - but that >>>>>> is how >>>>>> it will always be - direct usage of a C lib is just like calling C >>>>>> functions >>>>>> and such - whereas ctypes you have to call a python function >>>>>> (which may call >>>>>> others) which will execute the C lib code... >>>>>> >>>>>> I'll see if I can't find the page somewhere... >>>>>> >>>>>> On Mon, Mar 16, 2009 at 3:44 PM, Brian Fisher >>>>>> <br...@hamsterrepublic.com> >>>>>> wrote: >>>>>>> >>>>>>> That's what PyOpenGL 2.0 was - a C extension instead of ctypes. >>>>>>> (made >>>>>>> with SWIG) >>>>>>> >>>>>>> I actually still use PyOpenGL 2.0 for reasons other than >>>>>>> performance >>>>>>> (py2exe packaging) - I had to build it myself on windows for >>>>>>> Python 2.5, you >>>>>>> can get at an installer for it here: >>>>>>> http://thorbrian.com/pyopengl/builds.php >>>>>>> >>>>>>> I've never performance tested the difference between it and 3.0 >>>>>>> though - >>>>>>> is somebody else could do that, I'd love to see the results >>>>>>> >>>>>>> On Mon, Mar 16, 2009 at 10:49 AM, Zack Schilling >>>>>>> <zack.schill...@gmail.com> wrote: >>>>>>>> >>>>>>>> If someone did this and I could drop it in to my code, that >>>>>>>> would be >>>>>>>> very nice. But for right now, PyOpenGL is serving my needs just >>>>>>>> fine. I can >>>>>>>> use about 600 independently textured and animated sprites >>>>>>>> onscreen, scaled >>>>>>>> and rotated, without stressing a low-end system more than 40%. >>>>>>>> >>>>>>>> On Mar 16, 2009, at 1:00 PM, 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. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> 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. >>>>>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> Thanks, Richie Ward