4 posts tagged with "Runtime"

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.

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.

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.