Game Development Reference
In-Depth Information
Finally,
OnInitVideo
calls the listener
OnInitVideo
(
QuakeView
in this case), which will start
the Java audio thread and start audio playback. Thus, the video initialization call stack can
be summarized as follows:
GLimp_SetMode
(width, height, mode) - C
Vid_GetModeInfo
(width, height, mode) - C
Vid_NewWindow
(width, height) - C
jni_init_video
(width, height) - C/JNI
OnInitVideo
(width, height) - Java
QuakeView
(width, height) - Java
NativeAudio.start()
- Java
What to Do When the Rendering Completes
This is the last step in the rendering cycle.
GLimp_EndFrame
fires after each frame of the game
is rendered. Here you issue a
qglFlush
call, which causes all issued OpenGL commands to
be executed as quickly as they are accepted by the actual rendering pipeline.
// gl_glx.c
void GLimp_EndFrame (void)
{
qglFlush();
}
Now you are ready to build the engine and start playing Quake II in your mobile device.
Building Quake II with the NDK
The final step is to get the native code compiled into
libquake2.so
before you can start
testing in your device. In the project source (under
ch07.QuakeII/jni
), you have three files
that drive the compilation process:
Application.mk
,
Android.mk
, and
hardlinkedq2gl.
mk
.
Application.mk
defines what modules are to be compiled. In your case,
quake2
(as
libquake2.so
) and NanoGL (from Chapter 6) will be compiled as a static library and
embedded within
libquake2.so
.
# Application.mk
APP_BUILD_SCRIPT := $(call my-dir)/Android.mk
APP_MODULES := quake2 NanoGL
Android.mk
simply includes the real compilation script
hardlinkedq2gl.mk
. This is done
because of a really annoying Android peculiarity: if you need to update the compilation script
Android.mk
(if you missed a compiler option, for example), then the compilation process will
start all over again from the beginning. This can drive you crazy when you try to compile
libraries with dozens and dozens of source files—especially in slow systems.
# Android.mk
include $(call my-dir)/hardlinkedq2gl.mk