Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a small docs about signal.wrapTime #1

Closed
wants to merge 1 commit into from
Closed

Add a small docs about signal.wrapTime #1

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 10 additions & 0 deletions website/documentation/08-time/signals.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -195,6 +195,16 @@ Want to jump to random "frames" in the animation?
Want to squidge (technical term) backwards and forwards through the animation?
`Signal.SmoothPulse.flatMap(signal.at(total time * _))`

To be reusable the reference start time of a signal is Seconds(0) by default.
So, when you want to use a signal relative to the current game time (e.g., start the signal from the current time as the new "zero point"), you need to adjust the signal's time reference:

```scala
import indigo.*

val signal = Signal.Lerp(Point(0, 0), Point(100, 100), Seconds(2.0))
val relativeToCurrentTimeSignal = signal.wrapTime(context.gameTime.running)
```
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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. 😅

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.


## Testing

Since the animation is now captured as a pure function based on time, you can now test your animation!
Expand Down
Loading