Game Development Reference
In-Depth Information
something. Then convince yourself that maybe learning a little assembly is a good
idea.
Report Every Compiler Bug You Find
If you happen to be lucky (or unlucky) enough to find a weird compiler problem (especially one that
could impact other game developers), do everyone a favor and write a tiny program that isolates the
compiler bug and post it so that everyone can watch out for the problem. You
ll be held in high regard
if you find a workaround and post that, too. Be really sure that you are right about what you see. The
Internet lasts forever, and it would be unfortunate if you blamed the compiler programmers for
something they didn
'
'
t do. In your posts, be gentle. Rather than say something like,
“
Those idiots who
developed the xyz compiler really screwed up and put in this nasty bug
…
,
”
try,
“
I think I found a
tricky bug in the xyz compiler
…
.
”
Profiling is the act of improving the execution speed of your program and removing
any bottlenecks from the code. This can be accomplished by measuring how long
different parts of your code take to execute and rewriting the slow algorithms to be
more efficient. Bottlenecks are particularly long frames that manifest as a momentary
hitch in performance. They can occur if you have to wait for a piece of hardware, like
waiting for the hard drive after suffering a cache miss, or if you
'
re trying to do too
much in a single frame.
The first step in profiling is measuring the performance of your game. You can
'
t fix
what you can
t see. There are a number of different programs available for measuring
performance. Some are free, while others cost a lot of money. VTune by Intel is one
of the better-known tools. It
'
s extremely powerful but also very expensive. Luke
Stackwalker is a program I use on my own projects that works pretty well. It
'
s not
as powerful as VTune or other commercial applications, but it has the huge advan-
tage of being free.
Another method of measuring performance is to use a
'
This
involves measuring the time between function calls with a high-resolution timer and
logging the results. A function like
GetTickCount()
won
'
t work since it
'
s too low
resolution, causing inaccurate results. One method I
“
poor man
'
s profiler.
”
ve used in the past is to take
advantage of the ×86 Time Stamp Counter. The Time Stamp Counter is a high-
resolution 64-bit counter that counts the number of CPU cycles since the computer
was reset. You can read the value of this timer before a block of code and then read it
again afterward to find out how many CPU cycles it took to execute. This isn
'
'
t
