Workflow: Build & Export

Use the Build menu when the scene, assets, UI, and scripts are ready for PS1 packaging.

Build Commands

Command	What it does
Build Settings...	Choose Scenes In Build and the startup scene
Validate Project	Run editor validation and open Problems
Show PS1 Budget	Open the current-scene budget dashboard
Open VRAM Inspector	Inspect current framebuffer, texture-page, footprint, and CLUT placement
Export PS1 Budget Report	Write Build/ps1/logs/ps1_budget_current_scene.json
Open Build Report	Open the latest post-bake ps1_build_performance_report.json
Build PS1 (Release)	Validate, select the bundled runtime, stage assets/scenes, and package the disc image
Run Production Acceptance	Build Release and fail unless the project is fully PS1 Ready
Package Disc Only	Repackage staged content without recompiling the runtime
Build & Run PS1	Build the release disc image and launch DuckStation
Tool Paths...	Configure managed packaging tools and DuckStation
Toolchain Health Check...	Open the same path validator used before builds

Before You Build

Verify these tool paths:

• the installed Polygon PS1 runtime bundle
• mkpsxiso
• PSn00bSDK, CMake, and Ninja only when compiling a private source runtime
• DuckStation (optional)

The example project keeps tool paths blank on purpose. Each developer should set local paths from Build > Tool Paths... or the first-build guidance flow.

For emulator BIOS setup, optional user-supplied disc boot data, and the mandatory four-second startup logo, see BIOS, Disc Boot Data, and Startup Splash. The default export supplies no Sony boot data.

What You See in the Editor

Project Browser > Build Output

The editor exposes the packaged PS1 output folder so the user can directly inspect:

• .bin
• .cue
• .iso
• packaging notes

The internal disc_root is still generated for the pipeline, but it is not the primary user-facing build output.

Console

Build and packaging logs appear in the Console. Validation errors should be resolved before relying on runtime tests.

Build Completion and History

After a build, the completion dialog reports success or failure, duration, configuration, startup scene, and the size of generated CUE, BIN, ISO, or XML outputs. From the dialog you can open the package, run the existing package in DuckStation, or copy a compact summary for a bug report.

The same result is stored as machine-readable JSON:

File	Purpose
Build/ps1/logs/build_summary.json	Latest build result, output sizes, failure step, message, and budget-report path
Library/build_history.json	Last 20 build summaries for local diagnosis

Build history is generated local state. Do not use it as the release artifact; archive the package and authoritative reports from the successful build.

PS1 Budget

The editor panel shows an authoring estimate. The build pipeline writes the authoritative post-bake runtime reports under Build/ps1/logs/:

• ps1_budget_current_scene.json,
• ps1_runtime_budget_<scene>_<hash>.json,
• ps1_build_performance_report.json.

Use Run Production Acceptance before publishing a template or sample. A normal Release build may succeed with warnings, but production acceptance requires the build-level readiness field to be PS1 Ready.

These reports include:

• current scene GameObject and UI counts,
• unique meshes, materials, textures, audio clips, and script sources,
• post-bake mesh renderers, baked mesh chunks, sectorized renderers, and triangles,
• mesh RAM, mesh file bytes, texture VRAM, SPU audio, Lua heap, packet estimate, and .BSN read size,
• manifest usage, runtime memory margin, scene-content bytes, and loader transient bytes,
• Lua Update() Behaviour count, Audio Source count, and Transform Animator count against the 32-component runtime pool,
• texture page and CLUT placement,
• warnings and hard compatibility issues found by the budget analyzer.

Use the budget panel to identify capacity problems before export. Export Report, Open Logs and Open VRAM Inspector provide the next level of detail.

Open the image to view it at full size.

Practical PS1 Export Guidance

• Use Validate Project and Show PS1 Budget before building.
• Use Build PS1 (Release) while iterating on content.
• Use Build & Run PS1 when testing in DuckStation.
• Confirm the NTSC/PAL target in Project Settings before a full Release build.
• Use Package Disc Only with an available runtime; use a full Release build after changing the engine or build configuration.
• Burn the .cue, not the .iso, for real PS1 disc creation.

Release builds re-check imported textures and resident audio before staging, then encode enabled streaming-music sources to CD-XA. If a source file or import setting changed, the asset is reimported or the build stops with an actionable error. The .BSN writer also validates runtime string lengths before writing so names, prompts, UI text, Input Action names, Transform Animator states, Spawn Point IDs, and Lua callback names are never silently truncated.

Current builds write bounded .BSN scene data with tagged rendering, loading/UI, world, navigation, animation, and timeline chunks. Rebuild projects after an engine update so the current writer and validation rules inspect every feature before packaging.

Why Export Can Differ From Editor Preview

PS1 export is not a raw dump of the editor scene.

During build, Polygon Engine may:

• stage every referenced scene,
• rewrite asset paths to staged short names,
• refresh stale texture and resident-audio outputs,
• encode streaming music into DATA/X,
• bake static primitives to mesh chunks,
• bake enabled NavMesh Surface grids into bounded nodes and links,
• append advanced scene chunks for rendering, loading/UI, rooms/portals, navigation, and timelines,
• package authored UI and scripts for the runtime manifest.

That is intentional: it keeps the visual workflow friendly while producing content that survives the real PS1 runtime.