Loading Scenes and Music from CD-ROM

While working on scene loading in Polygon Engine, CD-ROM access was one of the clearest differences from development for a current desktop computer. The disc provides much more storage than PS1 RAM, but data must be read and prepared before the game can use it. Drive speed and file placement both affect that time.

This also affects game transitions. Before entering another area, I need to decide which assets will be loaded, what appears during the wait, and what happens to the music. Implementing that flow meant considering data loading and disc playback together.

Estimating disc loading times

I first had to distinguish disc capacity from read speed. Capacity describes how much content can be stored; transfer rate describes how much data can be read per second in a particular mode. Seeking to the sectors and processing their contents add to that time.

For a simple reference point, reading 150 sectors per second with 2,048 bytes of user data per sector gives 307,200 bytes per second, or 300 KiB/s. That is the familiar nominal double-speed data rate for that sector payload. It excludes seeking, command overhead, and processing, and other sector formats have different payload arrangements.

If an area needs 600 KiB through that path, the transfer alone has a nominal two-second lower bound before those other costs. It is a planning example, not a benchmark of a particular Polygon Engine scene. The CD-ROM reference explains the modes and sector structure behind the calculation.

That estimate provides a starting point for planning the transition. One option is to keep the next area's assets resident; others are to reduce the required data or show a loading screen. The choice depends on available memory and how the game's areas are organized.

Grouping assets for sequential reads

Suppose a room needs a mesh, several textures, materials, scripts, and sound effects. Loading each dependency as an unrelated file can mean repeatedly changing where the drive reads. Even if their combined size is modest, access patterns can add waiting.

Grouping assets that will be used together allows sequential reads and reduces changes in pickup position. That is the reason for Polygon Engine's scene-local dependency bundles: the build prepares a layout better suited to loading.

Organizing those bundles also means deciding how to handle shared assets. Repeating one in several scenes can simplify reads at the cost of disc space. Keeping one shared copy saves space but requires coordination over when it is loaded and how long it remains in memory. A smaller package does not necessarily load faster.

Memory adds another constraint. Reading a large bundle into a temporary buffer is not automatically a good idea if the final scene already occupies most of RAM. Sequential access and bounded working memory need to be considered together.

Coordinating XA music and scene loading

Long music tracks need a different approach because keeping a complete recording in SPU RAM would use too much space. CD-XA lets the track play as its data arrives from the disc. Short effects can instead remain loaded so they respond immediately to an interaction.

Music playback and scene loading use the same drive. When both need data, the engine has to coordinate access. Some architectures use interleaved sectors and buffers arranged for alternating reads, but that behavior requires a specific implementation.

In Polygon Engine's current implementation, XA music is suspended while scene data loads and starts again from the beginning when resumed. That limitation affects track selection and transition design. A restart is more noticeable in a song with a recognizable opening than in an ambient track with a gradual introduction.

The audio guide explains how to configure this workflow. A scene change can use a pause, a different track at the destination, or a resident transition effect. The transition needs to be designed around the playback behavior the engine currently provides.

Preparing the loading screen

The loading screen also needs to be ready in time. If its data only becomes available after the destination scene loads, it cannot appear during the wait. The transition system needs enough information to draw it before the slower part of the process begins.

That means having the loading presentation available, keeping the image stable, and switching to the new scene when it is ready. The screen does not have to be elaborate, but it should appear at the beginning of the transition rather than after several seconds without feedback.

The camera, audio, and input also need a defined owner at each stage. The old scene becomes inactive, the transition presents the loading state, and the new scene takes over when ready. Coordinating those changes prevents movement or interaction from continuing while level data is being replaced.

Designing transitions around loading

For level design, this information helps determine where new content should load. Every door does not need to trigger a load, and every area does not need to remain resident. Area size and available memory help determine how to divide the game.

A small set of rooms can remain loaded, while a substantial change of location can use an explicit transition. Corridors also help control visibility, although that does not by itself solve file loading. Visibility decisions need to be considered separately from storage and reading.

Understanding these timings helped me connect the loading system to scene design. File layout affects how long the player waits, and the transition's presentation affects how that wait feels. Both need to be reviewed when testing the exported game.