Struct FrameInput

Source

pub struct FrameInput<A>where
    A: ActionSet,{
    pub actions: Vec<A>,
    /* private fields */
}

Expand description

One frame’s input as a screen sees it.

Fields§

§actions: Vec<A>

Actions this frame, in order: key presses, then key repeats. A fixed step reads presses instead, which have no repeats.

Implementations§

Source §

impl<A> FrameInput<A>
where A: ActionSet,

Source

pub fn new(actions: Vec<A>, dt: f32, held: Vec<A>) -> FrameInput<A>

Input for one frame; held lists the actions whose keys are down. No pressed_chords. A dt that is not finite or is negative counts as 0 (frame_seconds). Each of actions is a press (presses), and one that isn’t held is a tap, let go too (released), until with_presses says otherwise.

Source

pub fn declared( &self, screen: &'static str, declared: &[A], ) -> (FrameInput<A>, Vec<A>)

This input as screen sees it when it declares that it reacts to declared alone (Screen::actions): only those actions, with the actions held back (in order, as often as they came). Asking the result whether an action outside declared is held panics: the screen reads an action it didn’t declare. Its presses, released and held actions are declared’s alone. Keys, buttons and text stay as they were.

Source

pub fn with_presses(self, presses: Vec<A>, released: Vec<A>) -> FrameInput<A>

The same input with the actions presses, pressed this frame in order without the key repeats, and released, let go this frame in order, as InputState gives them.

Source

pub fn presses(&self) -> &[A]

The actions pressed this frame, in order, without the key repeats that actions has after them: what a fixed step reads. A tick stage reads them through its TickDriver, which gives each to one step.

Source

pub fn released(&self) -> &[A]

The actions let go this frame, in order: each when no key or button holds it any more.

Source

pub fn held(&self) -> &[A]

The actions whose key or button is down at the end of this frame, in the game’s order (ActionSet::ALL).

Source

pub fn with_resumed(self, resumed: bool) -> FrameInput<A>

The same input with whether the game came back from a suspend just before this frame.

Source

pub fn resumed(&self) -> bool

Whether the game came back from a suspend just before this frame (the platform’s SystemEvent::Resume): a tick stage forgets the presses it kept from before (TickDriver does).

Source

pub fn with_buttons(self, down: Vec<Button>, up: Vec<Button>) -> FrameInput<A>

The same input with the controller buttons that went down and up this frame (and so pad_pressed if any went down).

Source

pub fn dt(&self) -> f32

Seconds since the previous frame: always finite and at least 0, so a screen adds it up as it is. It is for what only looks: rules count ticks or turns, with shuyi_core::timer.

Source

pub fn with_ticks(self, ticks: u32) -> FrameInput<A>

The same input with ticks fixed simulation steps due.

Source

pub fn ticks(&self) -> u32

How many fixed simulation steps are due this frame (ADR-0003 §2: 60 a second, at most 4 a frame): a stage with a tick simulation steps it this many times. The platform’s App counts them from its clock (shuyi_platform::tick); 0 while the game is suspended, in an update with no time passing (Game::act) and in a frame no App ran. Rules time things in these steps, with shuyi_core::timer, and never with dt.

Source

pub fn pressed_buttons(&self) -> &[Button]

The controller buttons that went down this frame (bound or not; by binding position, stick directions included), for the Key bindings screen, which captures the button for a slot. Anything else reacts to actions.

Source

pub fn released_buttons(&self) -> &[Button]

The controller buttons that went up this frame, as pressed_buttons.

Source

pub fn with_pad(self, pad: bool) -> FrameInput<A>

The same input with whether a controller button went down this frame.

Source

pub fn pad_pressed(&self) -> bool

Whether this frame’s input came from a controller (a button went down, or a button chord’s button gave its own action as it was let go): the player is on a controller, so a screen that needs text shows a letter grid instead of asking them to type. A game sets it with with_pad; with_buttons sets it for a button that went down.

Source

pub fn with_typing(self, pressed: Vec<Chord>, text: Vec<char>) -> FrameInput<A>

The same input with the chords pressed and the characters text typed this frame.

Source

pub fn pressed_chords(&self) -> &[Chord]

The chords pressed this frame (bound or not; presses only, no repeats), for the few screens that read keys themselves: a text box’s fixed keys (text_key) and the Key bindings screen, which captures the key for a slot. Anything else reacts to actions.

Source