Module screen 

Screens and the screen stack: the shape every screen of a game has.

A Screen reads the frame’s actions (FrameInput) in update and answers with a Transition; it paints itself into a GlyphBuffer in draw. The ScreenStack routes input to the top screen only and draws from the top-most opaque screen up, so overlays (menus, dialogs) show the screen below them. Screens are generic over the game’s part of the context (GameData), which also gives their actions.

A screen can ask something on a screen of its own and get the answer back: it pushes the question, which pops with a value (Transition::pop_with), and the stack hands that value to the screen below in uncovered. A screen also hears when one is pushed over it (covered) and when that one goes, with or without a value.

A screen declares the actions it reacts to (actions, ADR-0008 §3), so shuyi check --target can tell whether its required ones fit a target’s buttons. To keep the declarations honest, a stack with its guard on (the test Harness’s) hands a screen only the actions it declares, and logs the others (ScreenStack::undeclared).

A sound started with a handle (AudioQueue::start_sound) belongs to the screen that started it: when that screen leaves the stack through ScreenStack::apply_in, the stack stops it, so a loop can’t outlive its screen. A sound started from outside any screen belongs to the top one.

Re-exports

pub use crate::input::frame::FrameInput;

Structs

ScreenResult

A value a screen pops with (Transition::PopWith) for the screen below, which reads it back as its type in Screen::uncovered. Any 'static type will do; the two screens agree on which.

ScreenStack

The stack of open screens. Only the top screen is updated; drawing starts at the top-most opaque screen and goes up through the overlays above it.

Enums

Transition

What a screen asks the stack to do after an update.

Traits

Screen

One screen of a game: a title, a map, a menu overlay, …