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.

Controller input and save data look like small gameplay services in an editor. On the original PlayStation they are external devices with protocols, connection states, and failure cases.

A useful engine API hides the transaction details without hiding the facts that matter to the game.

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.

Lua is valuable in a PS1 engine because it separates gameplay iteration from C runtime work. Lua is also dangerous on a PS1 if it grows without limits.

Polygon Engine's scripting model is built around that tension: scripts should be easy to attach, inspect, and test, while the runtime keeps memory, script count, and API surface bounded.

A PlayStation disc can hold hundreds of megabytes while the console has only 2 MB of main RAM. That contrast defines the asset pipeline: the disc stores the game, but the runtime still needs explicit loading, bounded buffers, and a plan for seek latency.

The CD-ROM is capacity, not working memory.

The editor and the PS1 runtime should not consume the same data. That is one of the most important architectural decisions in Polygon Engine.

The editor wants readable project files, flexible authoring state, stable GUIDs, import metadata, screenshots, logs, and panels. The PS1 runtime wants compact data, fixed limits, predictable memory, and short disc paths.

Polygon Engine started with a familiar idea: let the user build a level from visual objects in an editor. The PS1 immediately pushes back on that idea. A scaled cube in an editor is easy. A scaled cube that sorts correctly, clips correctly, collides correctly, and packages correctly for PS1 is a much bigger requirement.

This is why level authoring in Polygon Engine is split into two related paths: scene primitives and reusable Level Builder mesh assets.

The original PlayStation is not just a slow modern GPU. It is a different rendering model. That difference is the reason Polygon Engine treats PS1 rendering as a content and tooling problem, not only as a runtime problem.

The editor can show a clean 3D scene. The PS1 runtime has to turn that scene into ordered GPU primitives with no z-buffer, fixed-point transforms, small memory pools, and a very unforgiving camera near plane.

The original PlayStation has 1 MB of VRAM, but treating that number as a simple texture budget is misleading. VRAM is a 1024 x 512 field of 16-bit words shared by display buffers, texture data, and color lookup tables.

Every rendering decision changes that layout. Resolution, color depth, double buffering, texture format, and palette placement all consume the same address space.

The original PlayStation is a group of specialized processors connected by narrow, explicit data paths. The CPU runs game code, the GTE accelerates geometry math, the GPU draws 2D primitives, the SPU plays sound, and the CD-ROM supplies data that cannot remain in memory.

Understanding those boundaries explains most PS1 engine decisions. The machine is fast when work is prepared for the right unit and expensive when the CPU has to compensate for a poor data layout.