diff options
| author | 3gg <3gg@shellblade.net> | 2026-04-12 11:18:46 -0700 |
|---|---|---|
| committer | 3gg <3gg@shellblade.net> | 2026-04-12 11:18:46 -0700 |
| commit | 5125d6788f7765a14fbcdeb6d4f6f67742c98596 (patch) | |
| tree | 3509aad1ca668e82eeff698e17265b7e307f2345 /simloop/include/simloop.h | |
| parent | 6014cb2db329f84ccfc4b4b8a19f54b1d2295cc3 (diff) | |
Update doc
Diffstat (limited to 'simloop/include/simloop.h')
| -rw-r--r-- | simloop/include/simloop.h | 22 |
1 files changed, 14 insertions, 8 deletions
diff --git a/simloop/include/simloop.h b/simloop/include/simloop.h index b08dcac..c5a0372 100644 --- a/simloop/include/simloop.h +++ b/simloop/include/simloop.h | |||
| @@ -4,9 +4,16 @@ | |||
| 4 | * control flow. The client steps the loop and then checks whether the | 4 | * control flow. The client steps the loop and then checks whether the |
| 5 | * simulation must be updated and/or the result rendered. | 5 | * simulation must be updated and/or the result rendered. |
| 6 | * | 6 | * |
| 7 | * If the simulation's update cannot keep up with the desired frame rate, then | 7 | * The simulation is updated at a fixed time step given a desired frame rate. |
| 8 | * the loop degrades to match the simulation's rate by requesting a single | 8 | * Rendering frame rate can likewise be capped or be unlimited. In any case, the |
| 9 | * update. | 9 | * loop guarantees that the same frame is not rendered twice. |
| 10 | * | ||
| 11 | * Generally, the simulation's update logic should be able to keep up with the | ||
| 12 | * requested frame rate; it is the application's responsibility to ensure this. | ||
| 13 | * Should the update logic not be able to keep up, then the loop requests a | ||
| 14 | * single update per iteration, effectively "degrading" to match the update | ||
| 15 | * logic frame rate, and giving the update logic a chance to catch up with | ||
| 16 | * subsequent loop iterations. | ||
| 10 | * | 17 | * |
| 11 | * Under a variable time delta, the loop could simply update the simulation | 18 | * Under a variable time delta, the loop could simply update the simulation |
| 12 | * with a large delta that puts the simulation back into the current clock | 19 | * with a large delta that puts the simulation back into the current clock |
| @@ -14,14 +21,13 @@ | |||
| 14 | * choices instead: | 21 | * choices instead: |
| 15 | * | 22 | * |
| 16 | * a) Queue as many updates as necessary to bring the simulation back to the | 23 | * a) Queue as many updates as necessary to bring the simulation back to the |
| 17 | * current clock time (time_diff / fixed_delta). | 24 | * current clock time (time_difference / fixed_delta). |
| 18 | * | 25 | * |
| 19 | * b) Queue a single update. | 26 | * b) Queue a single update. |
| 20 | * | 27 | * |
| 21 | * The issue with (a) is that the number of requested updates diverges and | 28 | * The issue with (a) is that, if the simulation is never able to catch up, then |
| 22 | * eventually the simulation appears to freeze. At every loop, the number of | 29 | * the number of requested updates at every loop iteration diverges and |
| 23 | * queued updates increases with respect to the last iteration as the | 30 | * eventually the simulation appears to freeze. Example: |
| 24 | * simulation fails to keep up with the desired frame rate. Example: | ||
| 25 | * | 31 | * |
| 26 | * desired delta = 10ms (100 fps) | 32 | * desired delta = 10ms (100 fps) |
| 27 | * actual delta = 20ms ( 50 fps) | 33 | * actual delta = 20ms ( 50 fps) |
