< [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) >