Expand description
This crate provides a game loop with a fixed timestep.
The game loop comes in the form of the Clock
iterator.
§Examples
use chron::{Clock, Tick};
use std::num::NonZeroU32;
let updates_per_second = NonZeroU32::new(50)?;
let frames_per_second = NonZeroU32::new(60)?;
let clock = Clock::new(updates_per_second)
.max_frame_rate(frames_per_second)
.max_updates_per_frame(3);
for tick in clock {
match tick {
Tick::Update => {
// ...
}
Tick::Render { interpolation } => {
// ...
}
}
}
§Features
§Fixed Timestep
A Clock
emits two types of events:
- An
Update
indicates that it is time to update the game logic. - A
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
. Its accuracy may or may not be good enough, depending on the platform.
See Clock::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
for more.
Modules§
- clock
- Provides the game loop iterator and related types.
Structs§
Enums§
- Tick
- A game loop event.