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? 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? -- Ben Sizer --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
