PS1 Hardware Constraints & Budgets

Polygon Engine targets the real PlayStation 1 rendering and memory model:

• no z-buffer,
• ordering-table based visibility,
• fixed-point GTE transforms,
• 1 MB VRAM,
• 2 MB main RAM,
• 512 KB SPU RAM.

Because of that, stable PS1 output depends on both budget discipline and authoring discipline.

Read PS1 Hardware Architecture first if you want the system-level explanation behind these limits.

Hardware Snapshot

Resource	Total	Practical Note
Main RAM	2 MB	Shared by runtime code, buffers, scene data, Lua, audio state
VRAM	1 MB	Shared by framebuffers, textures, CLUTs
SPU RAM	512 KB	Audio sample storage
CPU	33 MHz R3000A	No hardware FPU
GTE	Fixed-point geometry coprocessor	Transform, lighting, perspective
GPU	2D rasterizer	Draws ordered 2D primitives, not a z-buffered 3D pipeline

Default Project Budgets

Configured in Project Settings > PS1 Budgets:

Budget	Default
VRAM Budget	1,048,576 bytes
RAM Budget	786,432 bytes
SPU Budget	491,520 bytes
Max Texture Size	256
Max Unique Textures	64
Recommended Max Triangles Per Mesh	2,000
Hard Mesh Sort Cap	2,048 triangles
Max Scene Triangles	4,000

Runtime Limits That Matter in Authoring

These are the limits that most directly affect scene design:

Area	Runtime Limit
Authored UI canvases per scene	8
Authored UI elements per scene	32
Bitmap fonts per scene	3
Rooms / Portals	24 / 48
Navigation nodes / directed links	256 / 1,024
Cutscene clips / total keyframes	8 / 256
Standalone Animation clips / active instances	12 / 8
Transform Animator components / states per component	32 / 4
Skinned meshes per scene	16
Scene directional lights	3
Texture assets loaded at runtime	64
Manifest scenes	32
Manifest scripts	64

PS1 Budget Dashboard

The editor includes View > Show PS1 Budget and Build > Export PS1 Budget Report. Use this dashboard before each build pass, especially when changing level geometry, materials, scripts, or audio.

The dashboard tracks:

• runtime counts for GameObjects, UI, scripts, meshes, materials, textures, texture pages, and audio clips,
• estimated mesh RAM, texture VRAM, SPU audio, Lua heap, packet buffer usage, and scene triangles,
• VRAM texture page placement and CLUT row placement,
• an interactive VRAM map with framebuffer, page, footprint, and CLUT conflicts,
• first-person and third-person workflow signals such as player controllers, Camera Rigs, Interactables, and Camera Zones.

The editor export writes Build/ps1/logs/ps1_budget_current_scene.json as an authoring estimate. A PS1 build overwrites that active-scene file with post-bake runtime data and also writes one ps1_runtime_budget_<scene>_<hash>.json per built scene plus ps1_build_performance_report.json.

The Big Rendering Constraint: No Z-Buffer

The PS1 runtime sorts geometry by ordering-table depth buckets, not by per-pixel depth.

That means the following content is fragile unless it is authored or baked carefully:

• huge coplanar floors,
• very long wall quads,
• interpenetrating geometry,
• large polygons crossing the near plane,
• high-poly rounded primitives used as hero geometry.

Polygon Engine Strategy

To make editor-authored content work on PS1, the build pipeline applies PS1-specific processing:

• static built-in Plane and Cube geometry can be baked,
• large primitives can be chunked into smaller staged meshes,
• staged meshes preserve materials while reducing OT conflicts,
• validation warns when content exceeds runtime-friendly limits,
• release builds reject meshes that exceed the runtime sort cap,
• stale texture and audio outputs are detected from source and settings hashes before staging.
• navigation surfaces are baked into bounded fixed-capacity node/link graphs,
• hard-skinned FBX animation is baked into fixed-capacity geometry and matrix data,
• dense static OBJ and FBX sources can be reduced by the non-destructive PS1 Asset Optimizer before runtime index limits and expensive topology diagnostics are applied,
• standalone scene animations use fixed clip, slot, track, and keyframe pools,
• .BSN scene data uses sized rendering, loading/UI, world, navigation, animation, and timeline chunks so each runtime section remains bounded.

Practical Authoring Rules

Follow these rules when building PS1 scenes:

1. Prefer modular chunks over giant scaled primitives.
2. Do not rely on coplanar overlaps to hide seams.
3. Avoid using dense built-in capsules as hero props in PS1-facing scenes.
4. Use authored UI for shipping HUD and menu flows.
5. Keep static level geometry simple, axis-aligned, and bake-friendly whenever possible.

For a detailed explanation of why these rules matter, see PS1 Level Authoring. For a single table of runtime caps, see Runtime Limits.