Game Development Reference
In-Depth Information
Hard Drive Ticking? Maybe You Should Listen
During development on any platform with a hard drive or optical disc, keep your ear tuned to the sounds
your drive makes while you play your game. At worst, you should hear it seek or
every few
seconds or so as new data is cached in. This would be common in an open world game, where the
player could walk anywhere on an enormous outdoor map. At best, your game will have a level design
that grabs all the data in one read, and you
tick
'
ll play an entire level without going back to the disc.
A great trick is to keep indexes or file headers in memory while the resource file is open. These are
usually placed at the beginning or end of a file, and on large files the index might be a considerable
physical distance away from your data. Read the index once and keep it around to save yourself that
extra, and very time consuming, media seek.
Data Compression and Performance
Compression is a double-edged sword. Every game scrambles to store as much con-
tent on the distribution media and secondary storage as possible. Compression can
achieve some impressive space ratios for storing text, graphics, and sound at the
cost of increasing the load on the CPU and your RAM budget to decompress every-
thing. The actual compression ratios you
ll get from using different utilities are
completely dependent on the algorithm and the data to be compressed. Use algo-
rithms like Zlib or LZH for general compression that can
'
t afford lossiness. Use
JPG, OGG, or MPEG compression for anything that can stand lossiness, such as gra-
phics and sound.
Consider the cost of decompressing MP3 files for music, speech, or sound effects. On
the upper end, each stream of 128KB stereo MP3 can suck about 25MHz from your
CPU budget, depending on your processor. If you design your audio system to han-
dle 16 simultaneous streams, a 2GHz desktop will only have 1.6GHz left, losing
400MHz to decompressing audio. Of course, you can be clever about decompressing
them only when needed and trade some memory for CPU time.
'
Keep an Eye on Your Message Queue During Callbacks
If you are working on a Windows game and your decompressor API uses a
callback, it is quite likely that the decompression will forward Windows system
messages into your message pump. This can create a real nightmare since
mouse clicks or hot keys can cause new art and sounds to be recursively sent
into the decompression system. Callbacks are necessary for providing user
feedback like a progress bar, but
they can also wreak havoc with your
message pump.
If this is happening to your application, trap the offending
messages
and hold them in a
temporary queue until
the primary
decompression is finished.
 
 
Search WWH ::




Custom Search