254 lines
4.6 KiB
Markdown
254 lines
4.6 KiB
Markdown
[Sumário](../table-of-contens.md) | [Adiante](chapter-2.md) >
|
|
|
|
# ⏱️ **Modelo de Tempo e Ciclos**
|
|
|
|
# 1. Visão Geral
|
|
|
|
PROMETEU é um sistema **orientado a tempo**.
|
|
|
|
Nada acontece “instantaneamente”.
|
|
|
|
Toda ação consome **tempo mensurável**, expresso em **ciclos de execução**.
|
|
|
|
Este capítulo define:
|
|
|
|
- o **clock base** do sistema
|
|
- o conceito de **ciclo PROMETEU**
|
|
- como o tempo é distribuído ao longo dos frames
|
|
- como o **CAP (Execution Cap)** se relaciona com esse modelo
|
|
|
|
---
|
|
|
|
## 2. Clock Base do Sistema
|
|
|
|
PROMETEU opera com um **clock fixo de 60 Hz**.
|
|
|
|
Isso significa:
|
|
|
|
- 60 iterações do loop principal por segundo
|
|
- cada iteração corresponde a **um frame**
|
|
- o clock é **determinístico e estável**, independente da plataforma
|
|
|
|
> O clock define o ritmo da máquina,
|
|
não a quantidade de trabalho obrigatório por frame.
|
|
>
|
|
|
|
---
|
|
|
|
## 3. O Frame PROMETEU
|
|
|
|
Um **frame PROMETEU** representa uma unidade completa de execução.
|
|
|
|
Cada frame executa, conceitualmente, as seguintes etapas:
|
|
|
|
```
|
|
FRAME N
|
|
──────────────
|
|
INPUT
|
|
UPDATE
|
|
DRAW
|
|
AUDIO
|
|
SYNC
|
|
──────────────
|
|
|
|
```
|
|
|
|
O sistema garante:
|
|
|
|
- ordem fixa
|
|
- repetição previsível
|
|
- ausência de frames “fantasmas”
|
|
|
|
---
|
|
|
|
## 4. Ciclos PROMETEU
|
|
|
|
### 4.1 Definição
|
|
|
|
Um **ciclo PROMETEU** é a menor unidade abstrata de tempo do sistema.
|
|
|
|
- cada instrução da VM consome um número fixo de ciclos
|
|
- chamadas de periféricos também possuem custo
|
|
- o custo é **documentado e estável**
|
|
|
|
Ciclos são:
|
|
|
|
- **contáveis**
|
|
- **comparáveis**
|
|
- **independentes de hardware real**
|
|
|
|
---
|
|
|
|
### 4.2 Por que ciclos, e não milissegundos?
|
|
|
|
PROMETEU não mede tempo em milissegundos porque:
|
|
|
|
- milissegundos variam entre plataformas
|
|
- clocks reais diferem
|
|
- jitter e latência escondem custo real
|
|
|
|
Ciclos permitem afirmar:
|
|
|
|
> “Este programa é mais caro que aquele,
|
|
>
|
|
>
|
|
> independentemente de onde ele rode.”
|
|
>
|
|
|
|
---
|
|
|
|
## 5. Orçamento por Frame
|
|
|
|
Cada frame possui um **orçamento máximo de ciclos**.
|
|
|
|
Esse orçamento:
|
|
|
|
- é resetado a cada frame
|
|
- não acumula ciclos não utilizados
|
|
- representa a capacidade da “CPU virtual”
|
|
|
|
### Exemplo conceitual
|
|
|
|
```
|
|
Frame Budget:10,000cycles
|
|
|
|
Used:
|
|
-Update logic:4,200
|
|
-Draw calls:3,100
|
|
-Audio:900
|
|
|
|
Remaining:
|
|
1,800cycles
|
|
|
|
```
|
|
|
|
---
|
|
|
|
## 6. Separação entre Clock e Trabalho
|
|
|
|
PROMETEU **não exige** que toda lógica rode a cada frame.
|
|
|
|
O programador é **explicitamente encorajado** a distribuir trabalho no tempo.
|
|
|
|
### Exemplos comuns
|
|
|
|
- lógica de inimigos a cada 2 frames (30 Hz)
|
|
- pathfinding a cada 4 frames (15 Hz)
|
|
- animações independentes da AI
|
|
- timers baseados em contagem de frames
|
|
|
|
Isso reflete práticas reais de:
|
|
|
|
- consoles clássicos
|
|
- sistemas embarcados
|
|
- firmware de microcontroladores
|
|
|
|
> Nem tudo precisa acontecer agora.
|
|
>
|
|
|
|
---
|
|
|
|
## 7. Distribuição Temporal como Arquitetura
|
|
|
|
PROMETEU trata **distribuição de trabalho no tempo** como uma decisão arquitetural.
|
|
|
|
Isso significa que:
|
|
|
|
- código que roda todo frame é mais caro
|
|
- código distribuído é mais eficiente
|
|
- otimização é, antes de tudo, **organização temporal**
|
|
|
|
PROMETEU ensina:
|
|
|
|
> desempenho não vem só de “menos código”,
|
|
>
|
|
>
|
|
> mas de **quando** o código roda.
|
|
>
|
|
|
|
---
|
|
|
|
## 8. Execution CAP (Orçamento Contextual)
|
|
|
|
### 8.1 O que é o CAP
|
|
|
|
O **CAP** define um conjunto de limites técnicos associados a um **contexto específico**, como:
|
|
|
|
- Game Jams
|
|
- avaliações acadêmicas
|
|
- desafios técnicos
|
|
|
|
O CAP pode definir:
|
|
|
|
- orçamento máximo de ciclos por frame
|
|
- limite de memória
|
|
- limites de chamadas de periféricos
|
|
|
|
---
|
|
|
|
### 8.2 CAP não bloqueia execução
|
|
|
|
Regras fundamentais:
|
|
|
|
- o jogo **sempre roda**
|
|
- o jogo **sempre pode ser empacotado**
|
|
- o jogo **sempre pode ser jogado**
|
|
|
|
O CAP **nunca impede** execução.
|
|
|
|
---
|
|
|
|
### 8.3 CAP gera evidência, não punição
|
|
|
|
Quando um CAP está ativo, PROMETEU:
|
|
|
|
- mede execução
|
|
- registra picos
|
|
- identifica gargalos
|
|
- gera **relatório de certificação**
|
|
|
|
Esse relatório:
|
|
|
|
- não bloqueia o jogo
|
|
- não invalida a entrega
|
|
- **documenta conformidade ou não conformidade**
|
|
|
|
---
|
|
|
|
## 9. Certificação Baseada em Tempo
|
|
|
|
A certificação PROMETEU analisa:
|
|
|
|
- uso médio de ciclos por frame
|
|
- picos máximos
|
|
- frames problemáticos
|
|
- distribuição de custo
|
|
|
|
Exemplo:
|
|
|
|
```
|
|
Target CAP:PROMETEU-LITE
|
|
Frame Budget:5,000cycles
|
|
|
|
Frame 18231:
|
|
Used:5,612cycles❌
|
|
|
|
Primary cause:
|
|
enemy.updateAI():1,012cycles
|
|
|
|
```
|
|
|
|
Essa certificação acompanha o jogo como **artefato técnico**.
|
|
|
|
---
|
|
|
|
## 10. Implicações Pedagógicas
|
|
|
|
O modelo de tempo e ciclos permite ensinar:
|
|
|
|
- planejamento de execução
|
|
- arquitetura orientada a tempo
|
|
- trade-offs técnicos
|
|
- leitura de perfis reais
|
|
|
|
[Sumário](../table-of-contens.md) | Próximo: [Next](chapter-2.md) > |