Animated sprites should receive their own time

[LegenDAirie]

Because time is global, switching animations usually causes the new animation to start in the middle of the sequence.

Users should be able to manage a unique time for each sprite. Doing this will allow users to start animations at any point in the animation sequence(usually the start) as well as handle uncommon animations that may not loop in a normal fashion.

Does the time field in the render config serve another important purpose besides determining a sprites animation frame?

[Zinggi]

Would it be enough to add a time offset parameter to animatedSpriteWithOptions?
This way you could add an offset to each animation, which should allow you to do what you want, but it might be a bit weird. For instance, if you want to have your animation start at the first frame when inserting a new sprite, you'd have to pass -timePassedSinceStart to timeOffset.

Does the time field in the render config serve another important purpose besides determining a sprites animation frame?

No, currently it's only used in sprite animations

[LegenDAirie]

Hmmmm my initial reaction to that would be to say no. I am just imaging a scenario where someone might want to have their walking animation speed fluctuate depending on velocity or something.

I guess personally I just found it confusing that time was in render config since the time is really for sprites. As well as not being able to have the control to cancel a running animation half way through the sequence and start a jumping animation at the first frame.

I am very interested in getting on the same page with what you are thinking =). Can you elaborate more on why you would like to keep time in render config? Are you trying to preserve simplicity for those who would like just use a non-reactionary animated sprite? I just wanna make sure I am heading in the right direction

[Zinggi]

So The problem with canceling an animation and starting a new one is that it necessarily involves keeping some state (starting time / time already running or similar). This would mean that the library would have to provide it's own update function plus model.

I don't like this, because it makes the library less accessible.
Currently the library only provides view functions. I'd like to keep it this way.

I think advanced users can still do whatever they want using customFragment or veryCustom like this:

veryCustom (\{ camera, screenSize } ->
    renderTransparent vertTexturedRect fragAnimTextured unitSquare
        { transform = makeTransform position rotation size pivot
        , texture = tex
        , bottomLeft = V2.fromTuple bottomLeft
        , topRight = V2.fromTuple topRight
        , duration = duration
        , numberOfFrames = numberOfFrames
        , cameraProj = Camera.view camera screenSize
        , time = yourOwnTime
        }
)

Also, as soon as you want to switch animations, you probably want to introduce some abstract type Animation, that would describe the speed, starting frame, starting time, source rectangle, etc.

This might be a great candidate for a small extension library, but I think it doesn't fit in the scope of elm-2d-game

What about just adding a manuallyManagedAnimatedSpriteWithOptions? E.g. basically the same as AnimatedSpriteWithOptions, but with an additional time parameter that you'd have to manage yourself.
Is that what you had in mind?

[LegenDAirie]

Yeah, something like that. I think I might have caused some confusing with the term animation. I am referring only to animation frames of a sprite.

Allowing someone to handle all of their own animation states so they can specify exactly what animation frame they are on every tick is what I would like to do.

I completely agree that having the library keep track of animation state is not the right direction and keeping this only for views is.

I like the idea of adding manuallyManagedAnimatedSpriteWithOptions to do that. That way if someone has like a little cloud sprite that just loops and does nothing special, what you already have set up just lets them do that easily otherwise you handle each sprites frame number manually.

Let me know if that makes sense.

[Zinggi]

Ok, so I added a manuallyManagedAnimatedSpriteWithOptions. Does this suit your needs?

At some later point I want to rethink the whole animation system and make it more flexible. But for now I think this will suffice.

I wont publish 3.0.0 just yet, as I'll be away for a week, and when I publish a new breaking version I want to be around to fix potential problems.

[LegenDAirie]

Yes, this is brilliant! I can definitely make due with this!

Thank you!

[Zinggi]

The changes are now published 🎉