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.
 
 
Search WWH ::




Custom Search