Is there hope for your streaming system?
part 2: background

[This is part 2 of a series.]

Although this background is presented in the context of open-world console games, this series is relevant to any application with similar data access patterns, including other game genres, other platforms, and at least a few non-game applications.

On consoles (e.g. Xbox 360 or PS3), the data set for an open-world game is usually many times the size of available system memory. In order to make the game world appear seamless, only assets surrounding the player are loaded into memory. As the player moves around the game world, assets are streamed from media (DVD or Blu-ray) when the player approaches them (and distant ones are discarded).

The most straightforward way to stream assets is to place individual asset files on media, streaming them into memory when requested. Unfortunately, this results in very slow streaming, which often appears to the player as visual artifacts or “popping”. The primary culprit is the seek time of the device, exasperated by extra time incurred opening and closing many files.

Typically, the first optimization is to place all assets into a package file. The package is opened once when gameplay begins, and assets are streamed by seeking and reading at appropriate points within the package. This eliminates time wasted opening and closing individual asset files.

A package file is an improvement over individual asset files, but due to seeking for each asset, streaming will remain slow. The next optimization is to group assets which are likely to be requested at the same time into contiguous “blocks” within the package file. Entire blocks are then streamed into memory rather than individual assets, avoiding seeks between assets in the same block.

In order for this to be successful, the developer must determine how large blocks should be. Making blocks larger improves streaming performance, but requires larger memory buffers and limits the way art and design can place assets within the game world. A balance must be found between improved streaming performance and memory/art/design restrictions.

To make the best decisions regarding block sizes, it is necessary to estimate the expected streaming performance given a proposed block size. Existing references provide little assistance with this problem, which is where this series steps in.

Following posts will present a model of streaming performance as it relates to block sizes, device seek times, and raw media throughput. In addition to providing guidance when making block size determinations, the model is also useful for debugging, optimization, and validation of system performance.

[Continue to part 3...]

One Comment

Leave a Reply

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>