254 lines
4.4 KiB
Markdown
254 lines
4.4 KiB
Markdown
< [Summary](table-of-contents.md) | [Next](chapter-2.md) >
|
|
|
|
# ⏱️ **Time Model and Cycles**
|
|
|
|
# 1. Overview
|
|
|
|
PROMETEU is a **time-oriented** system.
|
|
|
|
Nothing happens "instantly".
|
|
|
|
Every action consumes **measurable time**, expressed in **execution cycles**.
|
|
|
|
This chapter defines:
|
|
|
|
- the system's **base clock**
|
|
- the concept of a **PROMETEU cycle**
|
|
- how time is distributed across frames
|
|
- how the **CAP (Execution Cap)** relates to this model
|
|
|
|
---
|
|
|
|
## 2. System Base Clock
|
|
|
|
PROMETEU operates with a **fixed clock of 60 Hz**.
|
|
|
|
This means:
|
|
|
|
- 60 iterations of the main loop per second
|
|
- each iteration corresponds to **one frame**
|
|
- the clock is **deterministic and stable**, regardless of the platform
|
|
|
|
> The clock defines the machine's rhythm,
|
|
not the amount of mandatory work per frame.
|
|
>
|
|
|
|
---
|
|
|
|
## 3. The PROMETEU Frame
|
|
|
|
A **PROMETEU frame** represents a complete unit of execution.
|
|
|
|
Each frame conceptually executes the following stages:
|
|
|
|
```
|
|
FRAME N
|
|
──────────────
|
|
INPUT
|
|
UPDATE
|
|
DRAW
|
|
AUDIO
|
|
SYNC
|
|
──────────────
|
|
|
|
```
|
|
|
|
The system guarantees:
|
|
|
|
- fixed order
|
|
- predictable repetition
|
|
- absence of "ghost" frames
|
|
|
|
---
|
|
|
|
## 4. PROMETEU Cycles
|
|
|
|
### 4.1 Definition
|
|
|
|
A **PROMETEU cycle** is the smallest abstract unit of time in the system.
|
|
|
|
- each VM instruction consumes a fixed number of cycles
|
|
- peripheral calls also have a cost
|
|
- the cost is **documented and stable**
|
|
|
|
Cycles are:
|
|
|
|
- **countable**
|
|
- **comparable**
|
|
- **independent of real hardware**
|
|
|
|
---
|
|
|
|
### 4.2 Why cycles, and not milliseconds?
|
|
|
|
PROMETEU does not measure time in milliseconds because:
|
|
|
|
- milliseconds vary between platforms
|
|
- real clocks differ
|
|
- jitter and latency hide the real cost
|
|
|
|
Cycles allow stating:
|
|
|
|
> "This program is more expensive than that one,
|
|
>
|
|
>
|
|
> regardless of where it runs."
|
|
>
|
|
|
|
---
|
|
|
|
## 5. Per-Frame Budget
|
|
|
|
Each frame has a **maximum cycle budget**.
|
|
|
|
This budget:
|
|
|
|
- is reset every frame
|
|
- does not accumulate unused cycles
|
|
- represents the capacity of the "virtual CPU"
|
|
|
|
### Conceptual example
|
|
|
|
```
|
|
Frame Budget:10,000cycles
|
|
|
|
Used:
|
|
-Update logic:4,200
|
|
-Draw calls:3,100
|
|
-Audio:900
|
|
|
|
Remaining:
|
|
1,800cycles
|
|
|
|
```
|
|
|
|
---
|
|
|
|
## 6. Separation between Clock and Work
|
|
|
|
PROMETEU **does not require** all logic to run every frame.
|
|
|
|
The programmer is **explicitly encouraged** to distribute work over time.
|
|
|
|
### Common examples
|
|
|
|
- enemy logic every 2 frames (30 Hz)
|
|
- pathfinding every 4 frames (15 Hz)
|
|
- animations independent of AI
|
|
- timers based on frame count
|
|
|
|
This reflects real-world practices from:
|
|
|
|
- classic consoles
|
|
- embedded systems
|
|
- microcontroller firmware
|
|
|
|
> Not everything needs to happen now.
|
|
>
|
|
|
|
---
|
|
|
|
## 7. Temporal Distribution as Architecture
|
|
|
|
PROMETEU treats **work distribution over time** as an architectural decision.
|
|
|
|
This means that:
|
|
|
|
- code that runs every frame is more expensive
|
|
- distributed code is more efficient
|
|
- optimization is, first and foremost, **temporal organization**
|
|
|
|
PROMETEU teaches:
|
|
|
|
> performance doesn't just come from "less code",
|
|
>
|
|
>
|
|
> but from **when** the code runs.
|
|
>
|
|
|
|
---
|
|
|
|
## 8. Execution CAP (Contextual Budget)
|
|
|
|
### 8.1 What is the CAP
|
|
|
|
The **CAP** defines a set of technical limits associated with a **specific context**, such as:
|
|
|
|
- Game Jams
|
|
- academic evaluations
|
|
- technical challenges
|
|
|
|
The CAP can define:
|
|
|
|
- maximum cycle budget per frame
|
|
- memory limit
|
|
- peripheral call limits
|
|
|
|
---
|
|
|
|
### 8.2 CAP does not block execution
|
|
|
|
Fundamental rules:
|
|
|
|
- the game **always runs**
|
|
- the game **can always be packaged**
|
|
- the game **can always be played**
|
|
|
|
The CAP **never prevents** execution.
|
|
|
|
---
|
|
|
|
### 8.3 CAP generates evidence, not punishment
|
|
|
|
When a CAP is active, PROMETEU:
|
|
|
|
- measures execution
|
|
- records peaks
|
|
- identifies bottlenecks
|
|
- generates a **certification report**
|
|
|
|
This report:
|
|
|
|
- does not block the game
|
|
- does not invalidate the delivery
|
|
- **documents compliance or non-compliance**
|
|
|
|
---
|
|
|
|
## 9. Time-Based Certification
|
|
|
|
PROMETEU certification analyzes:
|
|
|
|
- average cycle usage per frame
|
|
- maximum peaks
|
|
- problematic frames
|
|
- cost distribution
|
|
|
|
Example:
|
|
|
|
```
|
|
Target CAP:PROMETEU-LITE
|
|
Frame Budget:5,000cycles
|
|
|
|
Frame 18231:
|
|
Used:5,612cycles❌
|
|
|
|
Primary cause:
|
|
enemy.updateAI():1,012cycles
|
|
|
|
```
|
|
|
|
This certification accompanies the game as a **technical artifact**.
|
|
|
|
---
|
|
|
|
## 10. Pedagogical Implications
|
|
|
|
The time and cycles model allows teaching:
|
|
|
|
- execution planning
|
|
- time-oriented architecture
|
|
- technical trade-offs
|
|
- reading real profiles
|
|
|
|
< [Summary](table-of-contents.md) | [Next](chapter-2.md) > |