On Wed, Mar 26, 2008 at 1:19 AM, Ben Sizer <[EMAIL PROTECTED]> wrote: > > On Mar 25, 8:37 am, "Alex Holkner" <[EMAIL PROTECTED]> wrote: > > pyglet.sprite is highly optimised for the case where an image is drawn > > at the same place more than once (even updating only once every two > > frames really takes advantage of the architecture). > > > > Of course, some games are made up entirely of images that move every > > single frame (for example, the astraea example provided in the pyglet > > distributions). pyglet.sprite is not crippled for these cases (note > > that astraea runs with upwards of 100 on-screen elements on a low end > > computer while maintaining a high framerate), in fact it's not far off > > as optimal as you can get in pure Python, especially without > > introducing a lot of OpenGL-like state dependencies into the > > application. > > So, what you're saying is that pyglet makes the assumption that it's > quicker to rebuild the vertex array whenever an object moves (which > you assume is infrequently) than to explicitly translate every object > every frame, right?
The vertex array will contain colour, position and texture coordinate data for every sprite in the same group and batch. Only the sections of the vertex array that need to be updated are modified (the vertex array is not "rebuilt" as you suggest). I guarantee that even in the worst case where every sprite is moving every frame it will be much faster than calling glTranslate on each sprite (which involves the overhead of at least one OpenGL/ctypes call, and an OpenGL state change). > > In this case, is it feasible to create a new type of Sprite that is > optimised for the moving case, which is implemented in terms of > translations and rotations on a per-frame basis? If you find yourself needing more speed, you'd be better off writing a class that encapsulates multiple sprites, and can update the vertex array for all of their movements at once (a particle emitter is a good example). The benefit of this is fewer Python function calls and less array slicing on the vertex array. I don't think a generalised "move every frame" sprite can get much better performance than pyglet.sprite without some native code. Feel free to prove me wrong, of course ;-) Alex. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pyglet-users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pyglet-users?hl=en -~----------~----~----~----~------~----~------~--~---
