Add a small docs about signal.wrapTime

[mprevel]

Hi,

This is a minor change for the docs.

Please, let me know if this is not the good way to do it and that I should update the sample.

Regards,

[davesmith00000]

I'm not proposing you do this, but what we really need is to remove these docs and replace them with a working documented example, like the graphic one, which ends up as doc page.

[davesmith00000]

That's an interesting solution to the problem, but not the intended us of wrapTime. Also if you called that every frame, then you'd constantly be wrapping 'now'.

Wrap time is really there so that you can play something on a loop. Say you have an animation that is 2 seconds long, you'd do signal.wrapTime(2.seconds).

To get the animation to start playing 'from now', you then do this (made up, syntax might be wrong):

val animation: Signal = (moveCharacter >>> walkCycle)
val wrapped = animation.wrapTime(2.seconds)

// On present
sprite |> wrapped.at(context.gameTime.running - model.animStartTime)

Where animStartTime is some state recording the time the animation began.

[mprevel]

Yes, I've seen it was not doing what I've thought, just after creating the PR 🤦
Until now I was using something like :

  extension [A](s: Signal[A]) {
    def startsAt(reference: Seconds): Signal[A] =
      Signal { t =>
        s.at(t - reference)
      }
  }

But the fact I did not see some easier way to do it let me think I'm probably misusing the Signal.
So I don't know if I should keep the start time in the model like you're suggesting in your previous sample (model.animStartTime), or if I should embed the information in the signal itself like in the previous extension.

[davesmith00000]

Animations can be stateless, if you don't care when they start:
https://purplekingdomgames.github.io/talks/lovable-scala-rogues/#/35

But if you want them to start at a specific time, then you cannot avoid holding that information somewhere:
https://purplekingdomgames.github.io/talks/lovable-scala-rogues/#/36

Where and how you track that state / time is an exercise for the reader, because it depends on your needs and circumstances. In the example above for example, the state is timeOfDeath and carried as part of the player model.

Signals are designed to be reuseable animations, because they're just pure functions. So if you embed the time in the signal, the implication is that you always know when it's going to run from. At least, that's how I see it.

There is also a higher level DSL for animations, if it's of interest. Sooner or later you still need to make the same state based calculation however.
https://purplekingdomgames.github.io/talks/lovable-scala-rogues/#/38

That too, needs a nice example in the docs. 😅

[mprevel]

Thanks for your quick answer. I'll check these links. :)
I close this PR since the docs I've written is not doing what I've thought so it's pretty misleading.