Hello Benjamin, Great to see you're still very active on Pyglet development!
Just my two cents regarding the Animation class. You say performance is unchanged if we have lots of different Sprites with different Animations. Did you make some tests for that? I obviously didn't. But I would assume that the additional event dispatching might have a cost in terms of performances. The case where many Sprites share the same Animation seems pretty rare in my opinion. But I might be wrong! If several tiles must have a common animation, it's generally not very pleasing to the eyes to see multiple animations running exactly at the same time. A bit of offset between them makes usually for a more pleasant experience. But this version does not allow it. See below for a possible solution. If the event dispatching is not penalising the performances significantly, I would consider making an additional class for running the Animation. Call it maybe the Animator class. The reason is that Animators would only be responsible for keeping track of the current frame and would have methods like play, stop, rewind, etc. Multiple Animators could share a single instance of an Animation class which is just a list of Images together with a duration. As a short example, let's consider your proposal for the Animation class. Let's say the user wants to create an animation from a gif file. Normally we use pygame.resource.animation for that. This will load the images and add them to a TextureAtlas. If the user wants to create multiple Sprites from this Animation but keeping each Animation separate because they should start at different moment in time, he will need to load again the animation from the file or make a copy of it somehow. This means additional Textures with the same data. The current implementation actually bypass this problem as the data for running the Animation is held in the Sprite class. So we can pass the same Animation to different Sprites and have them run independently. If we have an Animator class, we can give it our Animation class and the Animator will simply keep track of the current frame (an index in the Animation list) and schedule some function to move the frame forward or backward or whatever we want it to do. This brings a small additional complexity or call it an indirection. I would imaging that if a Sprite is given an Animation object, it will need to instantiate its own Animator. But the Sprite should also be able to receive an Animator object in case we want to share the exact same animation across multiple sprites, as you described. I'm not sure I've thought of all the possible use cases. But I feel like we should carefully consider all the options before to committing to something. Any thoughts? Dan. -- You received this message because you are subscribed to the Google Groups "pyglet-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/pyglet-users. For more options, visit https://groups.google.com/d/optout.
