4.2 KiB
4.2 KiB
| id | ticket | title | status | created | completed | tags | |||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| PLN-0017 | render-all-scene-cache-and-camera-integration | Plan - FrameComposer Core and Hardware Ownership | accepted | 2026-04-14 |
|
Objective
Introduce FrameComposer as a first-class hardware-side subsystem and move canonical frame orchestration ownership out of Gfx.
Background
DEC-0014 locks FrameComposer as the canonical frame orchestration service. The first implementation step is to create the owning type, place it in hardware/drivers, and make Hardware aggregate it next to Gfx without yet completing the full render-path migration.
Scope
Included
- Create the
FrameComposertype incrates/console/prometeu-drivers. - Define the minimal owned state shape:
- active scene binding state;
- camera / viewport state;
- optional cache;
- optional resolver;
- owned
SpriteController.
- Aggregate
FrameComposerinsideHardware. - Expose the minimum driver-facing surface required for subsequent plans.
Excluded
- full sprite-model migration
- full scene binding implementation
- cache refresh application
- render-path retirement of
Gfx.render_all()
Execution Steps
Step 1 - Introduce the FrameComposer module and owned state
What:
Create FrameComposer as a concrete driver-side subsystem.
How:
- Add a new module such as
crates/console/prometeu-drivers/src/frame_composer.rs. - Define a
FrameComposerstruct with explicit placeholders for:active_scene_idactive_scenescene_statuscamera_x_pxcamera_y_pxSceneViewportCacheSceneViewportResolverSpriteController
- Keep scene/cache/resolver fields optional where no-scene operation is required.
- Do not introduce any fixed
16x16assumption into owned state; tile-size-sensitive behavior must derive from bound scene metadata.
File(s):
crates/console/prometeu-drivers/src/frame_composer.rscrates/console/prometeu-drivers/src/lib.rs
Step 2 - Aggregate FrameComposer in Hardware
What:
Make Hardware own FrameComposer alongside Gfx.
How:
- Extend
Hardwarewith aframe_composerfield. - Wire construction so
FrameComposerreceives the shared bank access it needs for later plans. - Keep ownership boundaries explicit:
FrameComposerprepares frame state,Gfxremains backend.
File(s):
crates/console/prometeu-drivers/src/hardware.rscrates/console/prometeu-drivers/src/memory_banks.rs
Step 3 - Define the minimum public driver-facing surface
What:
Give the driver layer a stable initial surface for FrameComposer.
How:
- Expose minimal constructor and accessor paths.
- Do not yet overdesign HAL-facing traits.
- Ensure the code compiles with no implicit dependence on
Gfx.render_all()ownership for frame state.
File(s):
crates/console/prometeu-drivers/src/frame_composer.rscrates/console/prometeu-drivers/src/hardware.rscrates/console/prometeu-drivers/src/lib.rs
Test Requirements
Unit Tests
FrameComposercan be constructed without a bound scene.Hardwaresuccessfully constructs with bothgfxandframe_composer.- Construction and owned state shape do not encode
16x16as an implicit world-path invariant.
Integration Tests
- Shared bank access needed by
FrameComposeris available through hardware construction.
Manual Verification
- Inspect the resulting type ownership and confirm scene/sprite state is no longer being newly introduced into
Gfx.
Acceptance Criteria
FrameComposerexists as a dedicated driver-side subsystem.HardwareaggregatesFrameComposernext toGfx.FrameComposerhas explicit owned placeholders for scene/camera/cache/resolver/sprites.- The build remains green with the new ownership structure in place.
Dependencies
- Source decision:
DEC-0014
Risks
- Introducing
FrameComposerwith too much behavior too early can blur later migration steps. - Introducing too little owned state can leave ownership ambiguous and force rework in later plans.
- Encoding
16x16into the initial owned-state shape would create a contract violation that later plans would have to unwind.