Game Development Reference
In-Depth Information
shm->samples = 2048 * shm->channels;
shm->samplepos = 0;
shm->submission_chunk = 1;
shm->buffer = NULL;
snd_inited = 1;
return true;
}
// Get
int SNDDMA_GetDMAPos(void)
{
return shm->samplepos;
}
Fixing the Game Loop
Thus far, you have custom video, movement, and audio handlers for Quake. The final piece
is to modify the main Quake loop slightly to work nicely with Android. This is necessary
because of the way
GLSurfaceView.Renderer
works. When Android creates a
GLSurfaceView
,
you must set a renderer by implementing
GLSurfaceView.Renderer
. When this renderer kicks
in, the following sequence of events will occur:
OpenGL initialization occurs, including creating a GL context with drawing
information such as pixel format, depth, stencil, buffers, and others.
GLSurfaceView.Renderer.onSurfaceCreated
is called when the surface
is created. This is where you must fire the Quake main function to start
the game. Note that you must also send the plethora of arguments that
Quake will expect from the command line.
GLSurfaceView.Renderer.onSurfaceChanged
is called whenever the
surface changes due to some event, such as when the phone goes to
sleep, wakes up, or receives a call, and so on.
GLSurfaceView.Renderer.onDrawFrame
fires for every interaction of
the renderer thread. This is where you must perform all the OpenGL
operations. When this method completes, the OpenGL buffers will be
swapped and the frame will be rendered on-screen.
Take a look at Quake's main function in Listing 6-16. It loops forever, rendering a frame at the
end of each loop interaction. If you start
main
from
onSurfaceCreated
, then the Android thread
will hang forever on the
while
loop. Therefore, you must comment this loop (as shown in
Listing 6-17) to let
onSurfaceCreated
complete normally.
Tip
sys_android.c
can be found in
ch06.Quake/jni/Quake/android
in the topic source.