260 lines
4.2 KiB
Markdown
260 lines
4.2 KiB
Markdown
< [Back](chapter-5.md) | [Summary](table-of-contents.md) | [Next](chapter-7.md) >
|
|
|
|
# 🎮 **INPUT Peripheral (Input System)**
|
|
|
|
## 1. Overview
|
|
|
|
The **INPUT Peripheral** is responsible for **collecting and providing the state of controls** to the PROMETEU program.
|
|
|
|
In PROMETEU:
|
|
|
|
- input is **state**, not an implicit event
|
|
- input is **sampled over time**, not delivered asynchronously
|
|
- input has a **defined order, cost, and moment**
|
|
|
|
> Buttons do not “trigger events”.
|
|
> They change state.
|
|
>
|
|
|
|
---
|
|
|
|
## 2. Philosophy of the Input System
|
|
|
|
PROMETEU models input like classic hardware:
|
|
|
|
- the state of controls is read **once per frame**
|
|
- the program queries this state during `UPDATE`
|
|
- there are no asynchronous input callbacks
|
|
|
|
This model:
|
|
|
|
- is deterministic
|
|
- is simple to understand
|
|
- reflects microcontrollers and classic consoles
|
|
|
|
---
|
|
|
|
## 3. Input Devices
|
|
|
|
PROMETEU abstracts different devices into a common interface.
|
|
|
|
Typical devices:
|
|
|
|
- digital control (D-Pad + botões)
|
|
- keyboard (mapped to buttons)
|
|
- gamepad
|
|
- touch (mobile, mapped)
|
|
|
|
Regardless of the origin, PROMETEU exposes **the same logical model**.
|
|
|
|
---
|
|
|
|
## 4. State Model
|
|
|
|
### 4.1 Per-Frame State
|
|
|
|
For each frame, the system maintains:
|
|
|
|
- current state of buttons
|
|
- state from the previous frame
|
|
|
|
This allows querying:
|
|
|
|
- button pressed
|
|
- button released
|
|
- button held down
|
|
|
|
---
|
|
|
|
### 4.2 Query Types
|
|
|
|
Typical operations:
|
|
|
|
```
|
|
input.btn(id)// button is pressed
|
|
input.btnp(id)// button was pressed this frame
|
|
input.btnr(id)// button was released this frame
|
|
```
|
|
|
|
These functions:
|
|
|
|
- are purely advisory
|
|
- do not change state
|
|
- have an explicit cost
|
|
|
|
---
|
|
|
|
## 5. Sampling Moment
|
|
|
|
The input state is captured **at the beginning of each frame**, before the `UPDATE` phase.
|
|
|
|
Conceptual flow:
|
|
|
|
```
|
|
FRAME N:
|
|
SAMPLEINPUT
|
|
UPDATE
|
|
DRAW
|
|
AUDIO
|
|
SYNC
|
|
```
|
|
|
|
Throughout the entire frame:
|
|
|
|
- the input state is immutable
|
|
- repeated calls return the same value
|
|
|
|
> Input does not change in the middle of the frame.
|
|
>
|
|
|
|
---
|
|
|
|
## 6. Determinism and Reproducibility
|
|
|
|
The PROMETEU input model guarantees:
|
|
|
|
- same sequence of inputs
|
|
- same frames
|
|
- same results
|
|
|
|
This allows:
|
|
|
|
- execution playback
|
|
- deterministic replays
|
|
- reliable certification
|
|
|
|
Input can be:
|
|
|
|
- recorded
|
|
- played back
|
|
- artificially injected
|
|
|
|
---
|
|
|
|
## 7. Input and CAP
|
|
|
|
Input operations:
|
|
|
|
- consume few cycles
|
|
- participate in the per-frame budget
|
|
- appear in certification reports
|
|
|
|
Example:
|
|
|
|
```
|
|
Frame 18231:
|
|
input.btn():12cycles
|
|
```
|
|
|
|
Although cheap, input **is not free**.
|
|
|
|
---
|
|
|
|
## 8. Button Mapping
|
|
|
|
### 8.1 Logical Identifiers
|
|
|
|
PROMETEU defines logical button identifiers:
|
|
|
|
- `UP`, `DOWN`, `LEFT`, `RIGHT`
|
|
- `A`, `B`, `X`, `Y`
|
|
- `START`, `SELECT`
|
|
|
|
The physical mapping:
|
|
|
|
- depends on the platform
|
|
- is resolved outside the VM
|
|
- is transparent to the program
|
|
|
|
---
|
|
|
|
### 8.2 Portability
|
|
|
|
The same PROMETEU cartridge:
|
|
|
|
- runs on a keyboard
|
|
- runs on a gamepad
|
|
- runs on touch
|
|
|
|
Without any code changes.
|
|
|
|
---
|
|
|
|
## 9. Analog Input (Optional)
|
|
|
|
PROMETEU can expose analog axes explicitly:
|
|
|
|
```
|
|
input.axis(id)
|
|
```
|
|
|
|
Characteristics:
|
|
|
|
- normalized value (e.g.: -1.0 to 1.0)
|
|
- explicit cost
|
|
- per-frame update
|
|
|
|
Analog input:
|
|
|
|
- is not mandatory
|
|
- does not replace digital input
|
|
- must be used consciously
|
|
|
|
---
|
|
|
|
## 10. Input Best Practices
|
|
|
|
PROMETEU encourages:
|
|
|
|
- treating input as state
|
|
- querying input only in `UPDATE`
|
|
- separating input from heavy logic
|
|
- mapping actions, not keys
|
|
|
|
And discourages:
|
|
|
|
- logic dependent on excessive polling
|
|
- reading input in DRAW
|
|
- direct coupling to physical hardware
|
|
|
|
---
|
|
|
|
## 11. Relationship with Classic Consoles
|
|
|
|
The PROMETEU model reflects:
|
|
|
|
- reading input registers
|
|
- per-frame polling
|
|
- absence of asynchronous events
|
|
|
|
This model:
|
|
|
|
- simplifies reasoning
|
|
- increases predictability
|
|
- facilitates debugging
|
|
|
|
---
|
|
|
|
## 12. Pedagogical Implications
|
|
|
|
The INPUT Peripheral allows teaching:
|
|
|
|
- the difference between event and state
|
|
- temporal sampling
|
|
- determinism in interactive systems
|
|
- synchronization between input and logic
|
|
|
|
With clear and reproducible feedback.
|
|
|
|
---
|
|
|
|
## 13. Summary
|
|
|
|
- input is state, not an event
|
|
- sampled once per frame
|
|
- immutable during the frame
|
|
- queries have an explicit cost
|
|
- input participates in the CAP
|
|
- model is deterministic
|
|
|
|
< [Back](chapter-5.md) | [Summary](table-of-contents.md) | [Next](chapter-7.md) > |