Add implementation for timers

[lenscas]

I added a basic Timer struct to help with #580 . However, before I continue on making sure it actually works and update the documentation, I want to know if this the API you had in mind. As I deviate a bit from the given example (mostly using duration instead of f32)

Motivation and Context

It solves not being able to know when to render or update

Checks

• I have read CONTRIBUTING.md.
• I have updated CHANGES.md, with [BREAKING] next to all breaking changes
• I have updated the documentation if necessary

• The example found in README.md compiles and functions like expected

[johnpmayer]

Two comments

1. This feels less "directionally correct" than introducing something async - https://github.com/johnpmayer/quicksilver-utils/blob/master/quicksilver-utils-async/src/time.rs
2. Does this guarantee that render happens during an animation frame? Or does quicksilver 0.4 already handle that some other way?

[lenscas]

I was looking at #580 (comment) when making this. So, if there is other stuff I need to keep in mind, it probably doesn't (yet).

[ryanisaacg]

Thanks for your work so far! This is a good start, and I've made a few comments for changes before merging.

[ryanisaacg]

@johnpmayer

This feels less "directionally correct" than introducing something async - https://github.com/johnpmayer/quicksilver-utils/blob/master/quicksilver-utils-async/src/time.rs

This isn't quite equivalent to sleeping. Imagine you want to render at rate R frame/second and update at rate U frame/second. You don't want to sleep, because these rates may not be equivalent (so you may be waiting on a render but need to update, or vice-versa.) Fix your timestep is the canonical text here.

Does this guarantee that render happens during an animation frame? Or does quicksilver 0.4 already handle that some other way?

That's not currently guaranteed, though I think it would be a useful / important feature. I've opened an issue to handle it in the underlying windowing library. It would be out of scope here.

[lenscas]

One question: If you are late with calling tick(), should it still take the full time until the next frame like it does now? Or should you being late be taken into account for the next frame?

If it being late should be taken into account, what should happen if you are an entire tick (or more) late?

[ryanisaacg]

If it being late should be taken into account, what should happen if you are an entire tick (or more) late?

We may want to use the accumulator strategy from the aforementioned 'Fix your Timestep!'. In that case, instead of re-setting the timer to now on tick, we could add the period to it. Each time you tick, you catch up one period. Then the usage pattern would look like:

while timer.tick() {
    let delta_time = timer.remaining();
    update(delta_time);
}

Does that make sense?

[lenscas]

If it being late should be taken into account, what should happen if you are an entire tick (or more) late?

We may want to use the accumulator strategy from the aforementioned 'Fix your Timestep!'. In that case, instead of re-setting the timer to now on tick, we could add the period to it. Each time you tick, you catch up one period. Then the usage pattern would look like:

while timer.tick() {
    let delta_time = timer.remaining();
    update(delta_time);
}

Does that make sense?

That should do it

[ryanisaacg]

Other than a quick doc update, all looks done here! 👍

[lenscas]

Something I just thought about while updating the example to show how to catch up. To my knowledge it doesn't really matter to catch up to the rendering, does it? So, maybe a function that doesn't mind dropping ticks is nice?

That way, users can choose between dropping updates/frames and solve being late in another way if they so desire? However, that is probably a discussion that should happen after this pr got merged :)

[ryanisaacg]

Great work!