Game Development Reference
In-Depth Information
sometimes faster than C. It is common to code the most speed-critical sections of
a game (typically the lowest-level matrix and vector mathematics) in assembly lan-
guage to take advantage of the architecture of the processor it will be running on.
This is well beyond the scope of this topic and should only be attempted if you have a
decent code profiler telling you that a speed-up would be useful.
If you are developing in a language other than C++, then you will need to translate
the code. Appendix C gives some guidance for efficient ways to convert the code into
a selection of common languages—ways to ensure that the language features run at a
reasonable speed.
I have used an object-oriented design for the source code and have always tried to
err on the side of clarity. The code is contained within a cyclone namespace, and its
layout is designed to make naming clashes unlikely.
There are many parts of the engine that can be optimized, or rewritten to take ad-
vantage of mathematics hardware on consoles, graphics cards, and some PC proces-
sors. If you need to eke out every ounce of speed from the engine, you will find you
need to optimize some of the code to make it less clear and more efficient. Chances
are, however, it will be perfectly usable as is. It has a strong similarity to code I have
used in real game development projects, which has proved to be fast enough to cope
with reasonably complex physics tasks.
There are a number of demonstration programs in the source code, and I will
use them as case studies in the course of this topic. The demonstrations were created
to show off physics rather than graphics, so I've tried to use the simplest practical
graphics layer. The source code is based on the GLUT toolkit, which wraps OpenGL
in a platform-independent way. The graphics tend to be as simple as possible, calling
GLUT's built-in commands for drawing cubes, spheres, and other primitives. This se-
lection doesn't betray any bias on my part (in fact I find OpenGL difficult to optimize
for large-scale engines), and you should be able to transfer the physics so that it works
with whatever rendering platform you are using.
The license for your use of the source code is liberal, and designed to allow it to
be used in your own projects, but it is not copyright-free. Please read through the
software license on the CD for more details.
It is my hope that, although the source code will provide a foundation, you'll
implement your own physics system as we go (and it therefore will be owned entirely
by you). I make decisions throughout this topic about the implementation, and the
chances are you'll make different decisions at least some of the time. My aim has been
to give you enough information to understand the decision and to go a different route
if you want to.
We will build our physics engine in stages, starting with the simplest engine that is
useful and adding new functionality until we have a system capable of simulating
almost anything you see in a modern game.
Search Nedrilad ::

Custom Search