Game Development Reference
In-Depth Information
52 z_bmalloc.h
131 z_zone.h
13460 total
As I've noted, I chose to use the PrBoom Doom engine. Even though the game
was created by id Software and released under the GNU license in 1993
(see http://en.wikipedia.org/wiki/Doom_(video_game ) ), there are many Doom
engines out there. I did try a few engines before settling on PrBoom.
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
When the user starts the game, the main activity, org.doom.DoomClient , will start
(see Figure 5-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 plays
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.
 
Search WWH ::




Custom Search