260 lines
4.4 KiB
Markdown
260 lines
4.4 KiB
Markdown
< [Voltar](chapter-5.md) | [Sumário](table-of-contents.md) | [Adiante](chapter-7.md) >
|
|
|
|
# 🎮 **Periférico INPUT (Sistema de Entrada)**
|
|
|
|
## 1. Visão Geral
|
|
|
|
O **Periférico INPUT** é responsável por **coletar e disponibilizar o estado dos controles** ao programa PROMETEU.
|
|
|
|
Em PROMETEU:
|
|
|
|
- input é **estado**, não evento implícito
|
|
- input é **amostrado no tempo**, não entregue assíncronamente
|
|
- input tem **ordem, custo e momento definidos**
|
|
|
|
> Botões não “disparam eventos”.
|
|
Eles mudam de estado.
|
|
>
|
|
|
|
---
|
|
|
|
## 2. Filosofia do Sistema de Entrada
|
|
|
|
PROMETEU modela input como hardware clássico:
|
|
|
|
- o estado dos controles é lido **uma vez por frame**
|
|
- o programa consulta esse estado durante `UPDATE`
|
|
- não existem callbacks assíncronos de input
|
|
|
|
Esse modelo:
|
|
|
|
- é determinístico
|
|
- é simples de entender
|
|
- reflete microcontroladores e consoles clássicos
|
|
|
|
---
|
|
|
|
## 3. Dispositivos de Entrada
|
|
|
|
PROMETEU abstrai diferentes dispositivos em uma interface comum.
|
|
|
|
Dispositivos típicos:
|
|
|
|
- controle digital (D-Pad + botões)
|
|
- teclado (mapeado para botões)
|
|
- gamepad
|
|
- toque (mobile, mapeado)
|
|
|
|
Independentemente da origem, PROMETEU expõe **o mesmo modelo lógico**.
|
|
|
|
---
|
|
|
|
## 4. Modelo de Estado
|
|
|
|
### 4.1 Estado por Frame
|
|
|
|
Para cada frame, o sistema mantém:
|
|
|
|
- estado atual dos botões
|
|
- estado do frame anterior
|
|
|
|
Isso permite consultar:
|
|
|
|
- botão pressionado
|
|
- botão liberado
|
|
- botão mantido pressionado
|
|
|
|
---
|
|
|
|
### 4.2 Tipos de Consulta
|
|
|
|
Operações típicas:
|
|
|
|
```
|
|
input.btn(id)// botão está pressionado
|
|
input.btnp(id)// botão foi pressionado neste frame
|
|
input.btnr(id)// botão foi liberado neste frame
|
|
```
|
|
|
|
Essas funções:
|
|
|
|
- são puramente consultivas
|
|
- não alteram estado
|
|
- têm custo explícito
|
|
|
|
---
|
|
|
|
## 5. Momento da Amostragem
|
|
|
|
O estado do input é capturado **no início de cada frame**, antes da fase `UPDATE`.
|
|
|
|
Fluxo conceitual:
|
|
|
|
```
|
|
FRAME N:
|
|
SAMPLEINPUT
|
|
UPDATE
|
|
DRAW
|
|
AUDIO
|
|
SYNC
|
|
```
|
|
|
|
Durante todo o frame:
|
|
|
|
- o estado de input é imutável
|
|
- chamadas repetidas retornam o mesmo valor
|
|
|
|
> Input não muda no meio do frame.
|
|
>
|
|
|
|
---
|
|
|
|
## 6. Determinismo e Reprodutibilidade
|
|
|
|
O modelo de input PROMETEU garante:
|
|
|
|
- mesma sequência de inputs
|
|
- mesmos frames
|
|
- mesmos resultados
|
|
|
|
Isso permite:
|
|
|
|
- reprodução de execuções
|
|
- replays determinísticos
|
|
- certificação confiável
|
|
|
|
Input pode ser:
|
|
|
|
- gravado
|
|
- reproduzido
|
|
- injetado artificialmente
|
|
|
|
---
|
|
|
|
## 7. Input e CAP
|
|
|
|
Operações de input:
|
|
|
|
- consomem poucos ciclos
|
|
- participam do orçamento por frame
|
|
- aparecem em relatórios de certificação
|
|
|
|
Exemplo:
|
|
|
|
```
|
|
Frame 18231:
|
|
input.btn():12cycles
|
|
```
|
|
|
|
Embora barato, input **não é gratuito**.
|
|
|
|
---
|
|
|
|
## 8. Mapeamento de Botões
|
|
|
|
### 8.1 Identificadores Lógicos
|
|
|
|
PROMETEU define identificadores lógicos de botões:
|
|
|
|
- `UP`, `DOWN`, `LEFT`, `RIGHT`
|
|
- `A`, `B`, `X`, `Y`
|
|
- `START`, `SELECT`
|
|
|
|
O mapeamento físico:
|
|
|
|
- depende da plataforma
|
|
- é resolvido fora da VM
|
|
- é transparente ao programa
|
|
|
|
---
|
|
|
|
### 8.2 Portabilidade
|
|
|
|
O mesmo cartucho PROMETEU:
|
|
|
|
- roda em teclado
|
|
- roda em gamepad
|
|
- roda em touch
|
|
|
|
Sem alteração de código.
|
|
|
|
---
|
|
|
|
## 9. Input Analógico (Opcional)
|
|
|
|
PROMETEU pode expor eixos analógicos de forma explícita:
|
|
|
|
```
|
|
input.axis(id)
|
|
```
|
|
|
|
Características:
|
|
|
|
- valor normalizado (ex.: -1.0 a 1.0)
|
|
- custo explícito
|
|
- atualização por frame
|
|
|
|
Input analógico:
|
|
|
|
- não é obrigatório
|
|
- não substitui input digital
|
|
- deve ser usado conscientemente
|
|
|
|
---
|
|
|
|
## 10. Boas Práticas de Input
|
|
|
|
PROMETEU incentiva:
|
|
|
|
- tratar input como estado
|
|
- consultar input apenas em `UPDATE`
|
|
- separar input de lógica pesada
|
|
- mapear ações, não teclas
|
|
|
|
E desencoraja:
|
|
|
|
- lógica dependente de polling excessivo
|
|
- leitura de input em DRAW
|
|
- acoplamento direto a hardware físico
|
|
|
|
---
|
|
|
|
## 11. Relação com Consoles Clássicos
|
|
|
|
O modelo PROMETEU reflete:
|
|
|
|
- leitura de registradores de input
|
|
- polling por frame
|
|
- ausência de eventos assíncronos
|
|
|
|
Esse modelo:
|
|
|
|
- simplifica raciocínio
|
|
- aumenta previsibilidade
|
|
- facilita debugging
|
|
|
|
---
|
|
|
|
## 12. Implicações Pedagógicas
|
|
|
|
O Periférico INPUT permite ensinar:
|
|
|
|
- diferença entre evento e estado
|
|
- amostragem temporal
|
|
- determinismo em sistemas interativos
|
|
- sincronização entre input e lógica
|
|
|
|
Com feedback claro e reproduzível.
|
|
|
|
---
|
|
|
|
## 13. Resumo
|
|
|
|
- input é estado, não evento
|
|
- amostrado uma vez por frame
|
|
- imutável durante o frame
|
|
- consultas têm custo explícito
|
|
- input participa do CAP
|
|
- modelo é determinístico
|
|
|
|
< [Voltar](chapter-5.md) | [Sumário](table-of-contents.md) | [Adiante](chapter-7.md) > |