# chron
[](https://crates.io/crates/chron)
[](https://docs.rs/chron)
[](https://codeberg.org/tinturing/chron/src/branch/main/LICENSE)
A game loop with a fixed timestep.
The game loop comes in the form of the [`Clock`](https://docs.rs/chron/latest/chron/clock/struct.Clock.html) iterator.
## Example
```rust
use std::num::NonZeroU32;
let updates_per_second = NonZeroU32::new(50).unwrap();
let frames_per_second = NonZeroU32::new(60).unwrap();
let clock = chron::Clock::new(updates_per_second)
.max_frame_rate(frames_per_second)
.max_updates_per_frame(10);
for tick in clock {
match tick {
chron::Tick::Update => {
// ...
}
chron::Tick::Render { interpolation } => {
// ...
}
}
}
```
## Features
### Fixed Timestep
A `Clock` emits two types of events:
- An [`Update`](https://docs.rs/chron/latest/chron/clock/enum.Tick.html#variant.Update) indicates that it is time to update the game logic.
- A [`Update`](https://docs.rs/chron/latest/chron/clock/enum.Tick.html#variant.Render) indicates that it is time to render a new frame.
The `Clock` tries to emit `Update` events at a fixed interval, for example `60` times per second.
`Render` events, on the other hand, are emitted in-between updates with no specific target frame rate.
By default, the frame rate is unlocked, that means as many frames as possible, but it may optionally be limited (see below).
### Frame Rate Limiter
The frame rate limiter can prevent the game from running at unnecessarily high frame rates.
This features only set the maximum frame rate.
The `Clock` will emit fewer `Render` events if this is required to maintain the specified *updates per second*.
> Note: The frame rate limiter uses [`std::thread::sleep`](https://doc.rust-lang.org/std/thread/fn.sleep.html#platform-specific-behavior).
> Its accuracy may or may not be good enough, depending on the platform.
See [`Clock::max_frame_rate`](https://docs.rs/chron/latest/chron/clock/struct.Clock.html#method.max_frame_rate) for more.
### Prevent Infinite Update Loops
When the `Clock` cannot maintain the specified *updates per second* (for example because updates are taking too long) it has to play catch-up by only emitting updates and **no** renders.
Such an *infinite update loop* can be prevented by automatically inserting a `Render` event after every `N` `Update` events.
This prevents the game from never rendering at all, at the cost of slowing down even more.
See [`Clock::max_updates_per_frame`](https://docs.rs/chron/latest/chron/clock/struct.Clock.html#method.max_updates_per_frame) for more.