Expand description
The App-driven game loop.
The App-driven game loop.
Where Backend is the output contract, App is the per-frame update
contract. A game implements App once and runs on every backend unchanged.
The loop decomposes into three pieces:
- the contract (
App,Flow,Frame), here in the core; - the generic blocking driver (
run_blocking/run_blocking_with,stdonly), which coversCrossterm(inretroglyph-crossterm) andHeadless; - the inverted driver in the windowing layer (the software backend’s
run_app), which cannot be generic because winit owns the loop instead of handing control back to a shared driver function.
+-----------------------------+
| App, Flow, Frame (core) |
+-----------------------------+
|
App::update
|
+---------------------+---------------------+
| |
run_blocking / run_blocking_with windowing layer's run_app
(std only; owns the loop) (winit owns the loop instead)
| |
crossterm, headless software backendBoth drivers call App::update as the per-frame body and present automatically after it
returns, skipping the present on Flow::Idle or when update already presented itself. The
low-level poll / present API remains
available for turn-based games and headless tests.
Structs§
- Frame
- Per-frame context handed to
App::update. - RunOptions
- Options controlling
run_blocking_with’s pacing and idle behavior.
Enums§
- Flow
- Whether the game loop should continue or stop after a frame, and whether that frame renders.
Traits§
- App
- The per-frame update contract for a game.
Functions§
- run_
blocking - Drive an
Appwith a blocking, event-driven loop until it returnsFlow::Exit. - run_
blocking_ with - Drive an
Appwith a blocking loop until it returnsFlow::Exit, paced byoptions.