Hi Neon, Sorry for the slow reply. The Animation + Frame classes are generic, and not strictly tied to any particular format. With regards to Gif files, that is the choice of the image codec to return an Animation. You can also manually make your own Animation from a sequence of images, or create your own codec for another image format. I have custom codecs for Aseprite and Piskel which also return Animations, which I use in some of my projects. The Frame.duration attribute is generally taken from whatever the loaded format has embedded.
Even though these classes are generic, it's only currently being used by Sprite class (which is why the conversation is image centric). I'm personally in favor of keeping the classes generic, so that they can be reused by the 3D model class later. It's up to the consumer of the Animation instance to handle the data that is inside a Frame. On Wednesday, June 20, 2018 at 5:45:18 PM UTC+9, Neon22 wrote: > > I'm not sure if I've got a good grip on this discussion. > Because I think the term Animation is here used in a limited way to refer, > originally, to controlling the animation rate of gif files. > So I wonder if we could clear up what the class does and what extra > capabilities are being created by improving this section, and whether a > better name would be appropriate. > > If its to control gif files - which have their own internal framate rate > and loop control - and to overide this and use them as a series of images - > then independently control which image is shown in what order and for how > long - then maybe this class should be associated with the texture bins (or > wherever) that a gif file would be loaded into. > > If its to control more general image sequences - which may have been > loaded from gifs, image sequences, texture Atlases - then maybe it could be > associated with the lowest class in the hierarchy to work across all of > these (or more?) use cases. > > Maybe it belongs in Sprites and then you get lots more control over > position, reuse, sychronisation ? > > Effectively video is also just an image sequence - So we can make a Sprite > and select its texture by pointing to the player. Normally the frame rate > is constant but no reason why it should not have the same kind of control. > > So the above is all about if the term ```Animation``` is the about > controlling when and where a sequence of images updates a specific > ```texture``` reference for use by several pyglet mechanisms. > > Alternatively the term Animation might be better (more accurately and > usefully perhaps?) used to control parameters over time. > So an ease-in-out or controlling a numeric parameter by using time into a > Bezier curve function to get a value to use for selecting a frame, > translating a Sprite, any 3d transform, or color might be a better way to > use the term. > > My suspicion is that currently we are talking about coupling image > selection with sequence order and controlling only when the next image is > to be used. I'd like to suggest decoupling image selection from a numeric > Animation control. And then allowing the numeric control to select an image > for Sprite, etc > What do people think about this ? > -- 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.
