92 lines
3.0 KiB
Markdown
92 lines
3.0 KiB
Markdown
# GFX Mental Model
|
|
|
|
Status: pedagogical
|
|
Companion spec: [`../specs/04-gfx-peripheral.md`](../../specs/04-gfx-peripheral.md)
|
|
|
|
Related asset spec: [`../specs/15-asset-management.md`](../../specs/15-asset-management.md)
|
|
|
|
PROMETEU treats graphics as an explicit peripheral, not as a modern GPU.
|
|
|
|
The right mental model is a retro 2D machine with:
|
|
|
|
- framebuffer;
|
|
- tile banks;
|
|
- tile layers;
|
|
- sprites ordered by draw order;
|
|
- deterministic composition per frame.
|
|
|
|
## Why This Exists
|
|
|
|
The goal is not to imitate historical hardware byte for byte. The goal is to capture the family of constraints and visual language of consoles such as SNES, CPS-2, and Neo Geo in a small, portable contract that can run on desktop and DIY hardware.
|
|
|
|
That produces some important consequences:
|
|
|
|
- draw order matters more than "effects";
|
|
- palettes matter as part of asset design;
|
|
- the programmer thinks in terms of rasterization, not shaders;
|
|
- visual cost becomes more observable.
|
|
|
|
## What The GFX Is Not
|
|
|
|
PROMETEU GFX is not:
|
|
|
|
- a modern GPU pipeline;
|
|
- an RGBA framebuffer with arbitrary alpha;
|
|
- a shader system;
|
|
- automatic post-processed composition.
|
|
|
|
Those absences are deliberate. They force a visual language closer to classic consoles and keep the contract executable in modest environments.
|
|
|
|
## Practical Intuition
|
|
|
|
- Tile layers exist for world and scenery.
|
|
- HUD exists for fixed information and should remain decoupled from the camera.
|
|
- Sprites exist for moving entities, and their depth depends on order and priority.
|
|
- Palettes exist to vary visual state without duplicating tile art.
|
|
- Fade exists as a discrete special effect, not as generic alpha.
|
|
|
|
## Palette Thinking
|
|
|
|
A good way to think about PROMETEU is that art and color are not the same thing.
|
|
|
|
The tile is the shape. The palette is the visual state.
|
|
|
|
That enables:
|
|
|
|
- enemy variation;
|
|
- biome changes;
|
|
- damage, ice, poison, power-up states;
|
|
- HUD themes;
|
|
- day and night cycles.
|
|
|
|
In the current tile-bank v1 baseline, this palette model is intentionally bounded:
|
|
|
|
- each bank carries `64` palettes;
|
|
- each palette carries `16` colors;
|
|
- `palette_id` is therefore a small runtime-facing selector, not an open-ended color namespace.
|
|
|
|
That limit is not incidental bookkeeping. It is part of how art packaging, runtime validation, and rendering stay aligned.
|
|
|
|
## Tile Banks Are Decoded Runtime Objects
|
|
|
|
The most useful intuition is to separate three layers:
|
|
|
|
- authored indexed art;
|
|
- serialized cart payload;
|
|
- resident runtime bank.
|
|
|
|
For tile banks in v1:
|
|
|
|
- authored pixels are logical indices `0..15`;
|
|
- serialized payload stores those indices as packed `4bpp`;
|
|
- runtime memory expands them to one `u8` index per pixel after decode.
|
|
|
|
So when reading the graphics model, do not imagine the renderer reading packed nibbles directly from cartridge storage. The renderer consumes a decoded `TileBank` object whose memory shape is optimized for runtime lookup, not for transport density.
|
|
|
|
## Use Cases
|
|
|
|
- area transition with `Scene Fade`;
|
|
- HUD transition with `HUD Fade`;
|
|
- damage flash or teleport flash;
|
|
- global palette swap for weather or world state.
|