Game Development Reference
In-Depth Information
fourth edition, storing games in memory rather than hard disk was becoming more
popular. That
'
s fine with me because I don
'
t want anything sitting in my lap spinning
at 20,000rpm. For a 15,000rpm device, the CPU must wait an average of 2ms for a
desired piece of data to be located in the right position to be read, assuming the read/
write head doesn
t have to seek to a new track. For a modern day processor operating
at 3GHz or more, this time is interminable. It
'
'
s a good thing processors aren
'
t con-
scious because they
d go mad waiting for hard disks all the time. Seeking time is
much slower. The read/write head must accelerate, move, stop, and become stable
enough to accurately read the magnetic media. For a CPU, that wait is an eternity.
Optical media is even worse. Their physical organization is a continuous spiral from
the inside of the disc to the outside, and the read laser must traverse this spiral at a
constant linear velocity. This means that not only does the laser read head have to
seek an approximate location instead of an exact location, but also the rotational
velocity of the disc must change to the right speed before reading can begin. If the
approximate location was wrong, the head will re-seek. All this mechanical move-
ment makes optical media much slower that their magnetic brethren.
The only thing slower than reading data from a hard drive or optical media is to have
an intern actually type the data in manually from the keyboard.
Needless to say, you want to treat data in your files like I treat baubles in stores like
Pier One. I do everything in my power to stay away from these establishments (my
wife loves them) until I have a big list of things to buy. When I can
'
t put it off any
longer, I make my shopping trip a surgical strike. I go in, get my stuff, and get out as
fast as I can, avoiding as many candles as possible. When your game needs to grab
data from the hard drive or optical media, it should follow the same philosophy.
The best solution would completely compartmentalize game assets into a single block
of data that could be read in one operation with a minimum of movement of the
read/write head. Everything needed for a screen or a level would be completely cov-
ered by this single read. This is usually impractical because some common data
would have to be duplicated in each block. A fine compromise factors the common
data in one block and the data specific to each level or screen in their own blocks.
When the game loads, it is likely you
'
ll notice two seeks
—
one for the common data
block and one for the level-specific block. Once the common data is in memory, you
leave it there and only load data for new levels or streamed areas as needed.
'
Know Your Hardware
Knowing how hardware works is critical to writing any kind of software. You don
t have to be a guru
writing device drivers to crack the topics and learn exactly how everything works and how you can take
advantage of it. This same lesson applies to the operating system and how the hardware APIs work
'
