Sounds good to me, especially the performance gain :D My use of Sprite involved trying to set the frame_index of the animation (so I could select a frame - ie jump forward in an animation so the on screen anims all started with different ages) and easily switch off auto-advancing (so I could pause an animation and do other types of animations such as ping-pong and random).
On 28 May 2018 at 11:28, Benjamin Moran <[email protected]> wrote: > Hi everyone, > > Dodgyville, and others in the past have asked about improved animation > control in pyglet. To this end, I have some experimental changes in a > branch, and wanted to get feedback before merging it in. > > First of all, let me give a quick explaination of how things work now. The > `Animation` class itself is simply a holder for `Frame` objects. The > `Frame` class is just an image and a duration. That's basically it - > Animations don't do anything by themselves. The actual logic for how to > Animations are used lies in the `Sprite` class. When assigning an Animation > to a Sprite, the Sprite class will schedule an interal update method with > `pyglet.clock.schedule_once` to handle advancing the Animation Frames and > updating it's own Texture. This works just fine, but there is no real way > to control the Animation without bloating the Sprite class with more > methods. > > My changes are this: > 1. Make the Animation class an EventDispatcher. > 2. Handle scheduling of Frame advancement inside the Animation class. > 3. The Animation has a `current_frame` property for getting the current > texture. > 4. Dispatch "next_frame" and "on_animation_end" events when appropriate. > 5. When assigning an Animation to a Sprite, the Sprite will simply > subscribe to the events, and update it's Texture when handling the > "next_frame" event. > > What does this do in practice? From an API perspective, nothing has > changed. The Sprite class is also still an EventDispatcher, and will > re-dispatch the "on_animation_end" event that is passed by the Animation. > If you create a ton of Sprites all with different Animations, performance > is un-changed. However, if you share the same Animation among lots of > sprites, it's about 50% faster in my benchmarks. This speedup is because > there is only one `pyglet.clock.schedule` in use, and each Sprite simply > has to handle an event. This can by useful in tiled games, that might use > the same tiled water animation for example. > These changes shouldl also make it easier to add high-level control to any > animation. You could add pause, reset, etc. methods to an Animation. > > One potential downside to these changes is that if you load a lot of > Animations, and don't use them, they will still be scheduling fram updates > in the background. If this is an issue, it could be mitigated with an > "activate" method to starts in going. This would be called automatically > when assigning it to a Sprite. > > Feedback welcome! > > -- > 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. > -- 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.
