BigFile Load Procedure

BigFiles are loaded in a series of stages. This prevents the game from freezing up during loads in single-threaded environments. The BigFile is processed for a short period of time then if it is not done, it returns 1 to indicate more processing needs to be done. The game then runs for a bit before loading the BigFile some more. This continues until 0 is returned meaning no more processing needs to be done. The stage index always starts with a value of 0.

Initialization

Stage 0

The version string is checked. The stage index is incremented by 1 and returns 1.

Stage 1

A StreamManager_Z buffer is setup for the header data. The stage index is incremented by 1 and returns 1.

Stage 2

Initialize working buffers and copy pool-related stuff from the header into the loader. The stage index is incremented by 1 and returns 1.

Stage 3

The first block is loaded for processing. StreamManager_Z buffers are allocated for the working buffers and the offset pointers are calculated. RTC and Non-RTC BigFiles are handled differently in this stage. The stage index is incremented by 1 and returns 1.

Process Blocks

Stages 4 through 6 are run for each block before advancing to the next block. The first block is included in these stages. In earlier games, this section was all one stage, stage 4.

Stage 4

Processes the current block, starting with the first block. Then it loads the next block for processing in the next iteration of the loop. The working buffer cursor, a pointer to the beginning of the BigFile data from the file after the reserved working_buffer_offset, is accessed so that stage 5 can proceed. RTC and Non-RTC BigFiles are handled differently in this stage. Increments the stage index by one and jumps straight to stage 5 without returning.

Stage 5

All of the objects in the block are loaded in sequence into the class manager and a pointer to each is stored in the loader for later processing. Each object has its link header virtual function called, is decompressed, and its body load virtual function called in that order before processing the next object. The stage index is incremented by 1 and returns 1.

Stage 6

Increment the current block index. If all blocks have been processed then the stage index is set to 7 and returns 1. Otherwise, the stage index is set to 4 and returns 1.

Custom Stages

Stages 7, 8, and 9

The stage's virtual table function, EndLoad, AfterEndLoad, and LoadDone for stages 7, 8, and 9 respectively, is called on all loaded ResourceObject_Zs in the order they appear in each block. Once all objects have been processed for each stage, the stage index is incremented by 1 and returns 1. This can be used to have custom loading procedures that run on each object after other objects have loaded, such as transforming names to handles. Mesh_Z uses these to do animation setup stuff in stage 7 and 8. Lod_Z and Skin_Z use these for animation and sound setup stuff in stage 7.

For each of these stages a fixed amount of time is dedicated to running the virtual functions. Once that time is up there are two cases. If all of the objects have been processed for that stage then the stage index is incremented by 1 and returns 1. If there are still objects left to be processed then the stage index is not modified and returns 1.

Terminal

Stages 10 and 11

Both close the BigFile and return 0 indicating processing is complete.