Game Engine Gems 2

 343

20

PointerPatchingAssets

Jason Hughes

Steel Penny Games, Inc.

20.1Introduction

Console development has never been harder. The clock speeds of processors

keep getting higher, the number of processors is increasing, the number of

megabytes of memory available is staggering, even the storage size of optical

media has ballooned to over 30 GB. Doesn’t that make development easier, you

ask? Well, there’s a catch. Transfer rates from optical media have not improved

one bit and are stuck in the dark ages at 8 to 9 MB/s. That means that in the best

possible case of a single contiguous read request, it still takes almost a full

minute to fill 512 MB of memory. Even with an optimistic 60% compression,

that’s around 20 seconds.

As long as 20 seconds sounds, it is hard to achieve without careful planning.

Most engines, particularly PC engines ported to consoles, tend to have the

following issues that hurt loading performance even further:

■ Inter- or intra-file disk seeks can take as much as 1/20th of a second.

■ Time is spent on the CPU processing assets synchronously after loading each

chunk of data.

BadSolutions

There are many ways to address these problems. One popular old-school way to

improve the disk seeks between files is to log out all the file requests and

rearrange the file layout on the final media so that seeks are always forward on

the disk. CD-ROM and DVD drives typically perform seeks forward more

quickly than backward, so this is a solution that only partially addresses the heart

344 20.PointerPatchingAssets

of the problem and does nothing to handle the time wasted processing the data

after each load occurs. In fact, loading individual files encourages a single-

threaded mentality that not only hurts performance but does not scale well with

modern multithreaded development.

The next iteration is to combine all the files into a giant metafile for a level,

retaining a familiar file access interface, like the

FILE type, fopen() function,

and so on, but adding a large read-ahead buffer. This helps cut down further on

the bandwidth stalls, but again, suffers from a single-threaded mentality when

processing data, particularly when certain files contain other filenames that need

to be queued up for reading. This spider web of dependencies exacerbates the

optimization of file I/O.

The next iteration in a system like this is to make it multithreaded. This

basically requires some accounting mechanism using threads and callbacks. In

this system, the order of operations cannot be assured because threads may be

executed in any order, and some data processing occurs faster for some items

than others. While this does indeed allow for continuous streaming in parallel

with the loaded data initialization, it also requires a far more complicated scheme

of accounting for objects that have been created but are not yet “live” in the game

because they depend on other objects that are not yet live. In the end, there is a

single object called a level that has explicit dependencies on all the subelements,

and they on their subelements, recursively, which is allowed to become live only

after everything is loaded and initialized. This undertaking requires clever

management of reference counts, completion callbacks, initialization threads, and

a lot of implicit dependencies that have to be turned into explicit dependencies.

Analysis

We’ve written all of the above solutions, and shipped multiple games with each,

but cannot in good faith recommend any of them. In our opinion, they are

bandages on top of a deeper-rooted architectural problem, one that is rooted in a

failure to practice a clean separation between what is run-time code and what is

tools code.

How do we get into these situations? Usually, the first thing that happens on

a project, especially when an engine is developed on the PC with a fast hard disk

drive holding files, is that data needs to be loaded into memory. The fastest and

easiest way to do that is to open a file and read it. Before long, all levels of the

engine are doing so, directly accessing files as they see fit. Porting the engine to a

console then requires writing wrappers for the file system and redirecting the

calls to the provided file I/O system. Performance is poor, but it’s working. Later,