aboutsummaryrefslogtreecommitdiff
path: root/simloop/include
diff options
context:
space:
mode:
author3gg <3gg@shellblade.net>2026-04-26 13:06:44 -0700
committer3gg <3gg@shellblade.net>2026-04-26 13:06:44 -0700
commit48422e313b31b79d76dd8f027b4d934994168859 (patch)
tree8235fe036e556ee3810d0a57846be7f666b1a894 /simloop/include
parente014d3cc269c636767528f2cdd716fc6badcaa89 (diff)
Test for catch-up. Document
Diffstat (limited to 'simloop/include')
-rw-r--r--simloop/include/simloop.h46
1 files changed, 0 insertions, 46 deletions
diff --git a/simloop/include/simloop.h b/simloop/include/simloop.h
index 7774c35..4e3ed20 100644
--- a/simloop/include/simloop.h
+++ b/simloop/include/simloop.h
@@ -1,49 +1,3 @@
1/* Simulation loop module.
2 *
3 * This implements a simulation loop but in a way that the client retains
4 * control flow. The client steps the loop and then checks whether the
5 * simulation must be updated and/or the result rendered.
6 *
7 * The simulation is updated at a fixed time step given a desired frame rate.
8 * Rendering frame rate can likewise be capped or be unlimited.
9 * In any case, an interpolation factor is computed for smooth animation between
10 * updates.
11 * The implementation also guarantees that the same frame is not rendered twice
12 * if time does not advance.
13 *
14 * Generally, the simulation's update logic should be able to keep up with the
15 * requested frame rate; it is the application's responsibility to ensure this.
16 * Should the update logic not be able to keep up, then the loop requests a
17 * single update per iteration, effectively "degrading" to match the update
18 * logic frame rate, giving the update logic a chance to catch up with
19 * subsequent loop iterations.
20 *
21 * Under a variable time delta, the loop could simply update the simulation
22 * with a large delta that puts the simulation back into the current clock
23 * time. Under a fixed time delta this isn't possible, and we seem to have two
24 * choices instead:
25 *
26 * a) Queue as many updates as necessary to bring the simulation back to the
27 * current clock time (time_difference / fixed_delta).
28 *
29 * b) Queue a single update.
30 *
31 * The issue with (a) is that, if the simulation is never able to catch up, then
32 * the number of requested updates at every loop iteration diverges and
33 * eventually the simulation appears to freeze. Example:
34 *
35 * desired delta = 10ms (100 fps)
36 * actual delta = 20ms ( 50 fps)
37 * ---------------------------
38 * iter, sim time, clock time
39 * ---------------------------
40 * 0, 0, 0, initial state
41 * 1, 0, 10, queue 1 update
42 * 2, 10, 30, queue (30-10)/10 = 2 updates
43 * 3, 30, 70, queue (70-30)/10 = 4 updates
44 * 4, 70, 150, queue (150-70)/10 = 8 updates
45 * ...
46 */
47#pragma once 1#pragma once
48 2
49#include <stdint.h> 3#include <stdint.h>