Game Development Reference
In-Depth Information
The first engine I tried was the original code from id Software—after all, it is the original creator. But
I had a lot of trouble with id Software's Linux implementation of the game, due to two main issues:
•
Color palette
: The Linux flavor supports an 8-bit color palette, which looks pretty
bad on 32-bit machines. This code was written for old machines (it has not been
updated for a long time). There should be a more modern implementation out
there.
•
Sine and cosine tables
: These are used for ray casting. I had many compiler
idiosyncrasies (using the CodeSourcery GCC 4.3.
x
compiler) where these tables,
which have hard-coded values, were not filled in correctly, making sprites go
through walls or move in the wrong way and creating many other display
problems.
PrBoom is a modern Doom engine. It is highly portable, although it is much bigger than the original
game. I found it to be the best choice due to the plethora of platforms it has been ported to and the
powerful support available for it from the developer community.
Game Architecture for Doom
Doom's game architecture is a bit similar to the architecture of Wolfenstein 3D. When the user starts the
game, the main activity
org.doom.DoomClient
will start (see Figure 7-1). This activity is bound to the other
pieces in the following manner:
The main activity is bound to the device UI through an XML layout (
doom.xml
).
This layout defines an image buffer used to display the graphics and a set of
controller buttons for navigation (see the “Game Layout” section for details).
•
The Doom engine is written in C and compiled as a DSO (
libdoom_jni.so
). All
communication with the DSO goes through the JNI layer (or native interface class
Natives.java
). Events are cascaded back to the main activity, which dispatches
them to their respective handler. Game files are read from the SD card by the DSO,
which handles all game aspects except sound.
•
•
Sound requests are delegated by the native library to the native interface class to
the main activity, and finally to the sound classes, which play them using the
Android
MediaPlayer
.
•
Video buffers (pixels) are cascaded by the native library to the native interface
class to the main activity, which renders them into the
ImageView
of the layout
XML.
