Assets, Audio, Lighting, and the Budgets Behind Them

The fastest way to make a PS1 demo feel real is to add textures, sound, lighting, UI, and animation. The fastest way to make it collapse is to add those systems without budgets.

Polygon Engine treats asset import and runtime budgets as the same problem. If something can be authored in the editor, it has to be countable before the build.

The Memory Picture

The original PlayStation gives the engine very little room:

Resource	Size	What competes for it
Main RAM	2 MB	Runtime, scene data, meshes, Lua, buffers, game state
VRAM	1 MB	Framebuffers, textures, CLUTs
SPU RAM	512 KB	Audio sample data
CPU	33 MHz R3000A	Gameplay, transforms, collision, scripting, build-time assumptions made visible
GTE	Fixed-point coprocessor	Transform, lighting, projection

This is why the editor has to show budgets. A project can be visually tiny and still fail if it uses too many textures, clips, scripts, or UI elements.

Textures

Textures are imported into PS1-oriented .tex data. The runtime validates the texture header, data size, format, dimensions, and VRAM placement before uploading.

The current runtime limits include:

• 64 texture assets,
• 20 texture page slots,
• 1 MB total VRAM shared with framebuffers.

Texture import supports indexed and direct formats, but content still needs discipline. A single large texture can be more expensive than several small, reusable ones. UI images also use texture memory, so menus and HUD art must be budgeted with the world.

Materials

Materials are intentionally simple:

• base color,
• optional main texture,
• render mode,
• double-sided flag,
• vertex color multiply,
• dithering.

That simplicity is part of the PS1 design. The runtime is not trying to emulate a modern material graph. It is trying to emit predictable GPU primitives.

The editor warns when a material choice is likely to be risky:

• double-sided materials increase draw cost and can make ordering less stable,
• transparent materials need careful placement and should stay small or isolated,
• missing texture assets should fail validation before runtime.

Audio

Audio starts from imported WAV files, then follows one of two PS1 paths.

Resident clips are converted to VAG ADPCM, loaded into SPU RAM, and played through Audio Source components or the AudioSource Lua API. Streaming music is encoded as CD-XA data and played from the disc through the Music Lua API.

Path	Current limit	Primary budget
Resident VAG clips	16	512 KB SPU RAM, minus the reserved system area
Streaming XA tracks	8	CD bandwidth and seek coordination

Short effects and latency-sensitive loops belong in the resident path. Long music belongs in XA streaming. Marking a long track as a resident Audio Source can still exhaust SPU RAM even when the source WAV looks modest on disk.

The import workflow is:

1. import WAV,
2. choose resident VAG or Streaming Music (CD-XA),
3. choose a target sample rate for resident audio,
4. assign VAG clips to Audio Source or address XA tracks by name,
5. validate SPU use and streaming-track count,
6. trigger playback through Play On Start, AudioSource, or Music.

The runtime suspends XA playback while it performs a scene load and restarts the suspended track from its beginning afterward. This keeps scene reads and music streaming from competing for incompatible CD access.

Lighting

Lighting is GTE-oriented and deliberately limited. The runtime supports a small number of directional lights plus ambient contribution. The current runtime cap is 3 scene directional lights.

That fits the hardware. Directional lighting gives low-poly scenes shape and readability without pretending the renderer has:

• per-pixel lights,
• dynamic shadows,
• normal maps,
• physically based materials.

Lua can still create gameplay moments by enabling/disabling Light GameObjects or sequencing scene states. The important part is that the lighting model stays understandable and cheap.

UI and Particles

Authored UI has a fixed scene element budget of 32. Particles are also capped. These limits are not glamour features, but they keep frame time and memory predictable.

For UI, the production rule is:

• use authored UI for shipping menus and HUD,
• keep element count small,
• use UI.DrawText() for temporary/debug text only,
• avoid texture-heavy UI unless it is part of the art budget.

The Budget Dashboard

The PS1 Budget dashboard is a bridge between content and runtime. It summarizes:

• GameObject count,
• UI count,
• unique meshes,
• materials,
• textures,
• texture page placement,
• audio clips,
• Lua heap,
• packet buffer estimate,
• scene triangles,
• warnings and hard issues.

This is essential for a user-facing engine. The user should not need to know C constants to understand that a scene is drifting out of bounds.

What Makes This Project Interesting

Most modern engine workflows assume the target is forgiving. Polygon Engine is interesting because the target is not forgiving at all.

The asset pipeline is therefore not just "import files." It is a system that turns friendly editor content into something a 1994 console can actually load, sort, light, play, and keep in memory.

Continue Reading

• VRAM Is a Layout, Not a Texture Folder
• The CD-ROM Is Not Extra RAM
• Lua Gameplay on a Fixed-Memory PS1 Runtime

The current RAM model includes actual scene-object storage and separate load peaks for the old scene plus BSN read and the new scene plus asset/script staging. Live diagnostics expose allocation requests and nested subsystem times; they do not measure the largest free heap block. PS1 Ready is a static budget result. See the Budget Dashboard before using it as release evidence.

Updated for Polygon Engine 0.1.0-ea.2.