Hardware-facing constraints and implementation notes.
View All TagsController 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.
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 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.