1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
//! 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;
//!
//! # fn main() { test().unwrap(); }
//! # fn test() -> Option<()> {
//! 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 => {
//! // ...
//! # break;
//! }
//! Tick::Render { interpolation } => {
//! // ...
//! }
//! }
//! }
//! # Some(())
//! # }
//! ```
//!
//! ## 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.
//!
//! [`Render`]: Tick::Render
//! [`Update`]: Tick::Update
pub use crate;