What It Takes to Ship a PS1 Project from an Editor

The goal of Polygon Engine is not only to render a PS1 scene. The goal is for a user to create a game from the editor, validate it, build it, test it, and understand why something fails when it fails.

That is a much harder target than a one-off demo.

The Minimum Product Bar

A shippable PS1 editor workflow needs all of these pieces to cooperate:

• project creation and loading,
• asset import,
• stable GUID references,
• scene editing,
• component authoring,
• Level Builder mesh creation,
• Lua gameplay scripts,
• UI canvas authoring,
• build settings,
• validation,
• runtime selection (or compilation in a private source build),
• asset staging,
• disc packaging,
• emulator testing,
• hardware-oriented release guidance.

If any one of those is vague, the user ends up debugging engine internals instead of making a game.

Build Output Has to Be Inspectable

Polygon Engine separates staged disc data from final package output:

Build/ps1/disc_root/
  SYSTEM.CNF
  POLYGON.EXE
  DATA/
    MANIFEST.JSN
    S/  scenes
    L/  Lua scripts
    M/  meshes
    R/  materials
    T/  textures
    A/  resident audio
    X/  XA music

Build/ps1/package/
  *.bin
  *.cue
  *.iso
  polygon.xml
  README_BURN_PS1.txt

This makes build failures easier to reason about. If the runtime says it cannot load a script, the staged DATA/L folder and manifest are visible. If packaging fails, the package folder and mkpsxiso log are visible.

Failure Modes the Editor Prevents

The engine has already run into the kinds of problems a real user would hit:

• missing binary assets,
• scenes not included in the build,
• script load errors,
• runtime out-of-memory errors,
• input mapping confusion,
• colliders missing from visible meshes,
• near-plane face dropout,
• polygon overlap from large surfaces,
• performance drops from too much scene work,
• SPU/VRAM pressure from assets.

Those failures become validation, documentation, and safer defaults instead of project-specific knowledge.

Validation as a Product Feature

The Problems panel is one of the most important parts of the editor. It turns runtime pain into editor feedback.

Good validation says:

This Level Builder mesh has no Collider and can be walked through.
This startup scene is not included in Scenes In Build.
This Lua heap exceeds the PS1 runtime cap.
This material is transparent and needs careful PS1 ordering.
This primitive cell size is too coarse for stable PS1 depth ordering.

That is more valuable than a generic build failure. The user can act on it.

Emulator Testing Is Necessary but Not Sufficient

DuckStation is the right fast loop for day-to-day work. It catches:

• boot errors,
• missing files,
• script errors,
• input problems,
• performance regressions,
• obvious rendering artifacts.

But emulator success is not the same thing as a hardware claim. Real hardware remains the final confidence gate, especially for timing, disc behavior, audio, and edge-case rendering.

DuckStation is the fast test loop; real hardware is the release-quality check.

Supported Boundaries

Polygon Engine keeps the supported path explicit. It does not claim to provide:

• arbitrary mesh boolean optimization,
• general-purpose world streaming,
• unlimited Lua,
• arbitrary simultaneous audio streaming beyond the single CD-XA music path,
• modern lighting,
• order-independent transparency,
• automatic perfect conversion for every primitive,
• hardware certification without real hardware testing.

Clear limits make the supported path stronger.

Production Checklist

Before calling a project release-ready, the workflow should pass this checklist:

Area	Requirement
Scenes	Startup scene and all loadable scenes included in build
Assets	No missing mesh, material, texture, audio, or script references
Geometry	Large floors/walls chunked or baked into safer pieces
Collision	Blocking objects have Colliders; triggers are intentional
Lua	Script counts, heap, properties, and instruction budget validated
UI	Authored UI stays within element budget
Audio	Resident clips fit SPU RAM; XA tracks stay within the streaming limit
Save data	Card errors are surfaced and each game uses a unique save-file ID
Performance	Scene runs acceptably in emulator with debug overlays off
Package	.cue and .bin generated and inspected
Hardware	Final build tested on the real target before public claims

Why the Complete Path Matters

PS1 homebrew tooling is still a small space. A visual editor, Lua scripting, binary asset pipeline, and PSn00bSDK runtime in one workflow is unusual enough that the technical details matter.

The editor does not replace the target architecture. It moves expensive conversion and descriptive validation to Windows, then sends compact, bounded data to the console.

That end-to-end contract is what turns an editor demonstration into a repeatable PS1 production workflow.

Continue Reading

• A Practical Map of the Original PlayStation
• The CD-ROM Is Not Extra RAM
• Controller Polling and Memory Cards on PS1
• Build pipeline reference

Updated for Polygon Engine 0.1.0-ea.2.