-
Notifications
You must be signed in to change notification settings - Fork 77
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.
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 implementation for timers #587
Conversation
Two comments
|
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). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for your work so far! This is a good start, and I've made a few comments for changes before merging.
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.
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. |
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? |
We may want to use the accumulator strategy from the aforementioned 'Fix your Timestep!'. In that case, instead of re-setting the timer to while timer.tick() {
let delta_time = timer.remaining();
update(delta_time);
} Does that make sense? |
That should do it |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Other than a quick doc update, all looks done here! 👍
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 :) |
Great work! |
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
CONTRIBUTING.md
.CHANGES.md
, with [BREAKING] next to all breaking changesREADME.md
compiles and functions like expected