Game Development Reference
In-Depth Information
Using the Android NDK to Compile Libraries from Chapters 6
and 7
In this section, we will compile the library from Chapter 6 (Wolf3D) using the NDK 1.5 as well as the
Chapter 7 library (Doom for Android) using the NDK 1.6. Knowing how to use the NDK is important for
you and can be a time saver if you have a slow system (such as a laptop/VMware combination). When I
started writing the games in Chapters 6 and 7, the NDK didn't yet exist. That was the reason I used the
CodeSourcery G++ toolkit; then along came the NDK 1.5. All in all, I don't advocate the use of the NDK
1.5, particularly at this early stage. The reasons I don't like to use the NDK 1.5 are simple:
•
Limited support for the C runtime
: The NDK includes only bare bones support for
the stable portions of the C runtime (the portions that are very unlikely to change
in the future). This limitation is stressed by Google in the documentation. The
components supported are the C runtime (
libc.so
), Math library (
libm.so
), and
Compression library (
libz.so
), and there's minimal support for C++. This level of
C support is fine for a game like Wolf3D or Doom but is not enough for the
advanced graphics, like OpenGL, that are required for more advanced games such
as Quake. If you find yourself in the latter situation, you are forced to either
translate all code to Java or hack the NDK to add support for OpenGL as explained
in the section “Adding OpenGL Support.”
•
Poor integration with the Eclipse workbench
: The NDK is a cumbersome and
difficult tool to use at this point. For example, the output folder, where the library
is compiled, is independent from your Eclipse workspace, and this disconnect
forces you to copy the file every time you make changes. Although the output
folder includes space for your Android project, this will force you to switch the
workspace to every location instead of centralizing the workspace as we are used
to with eclipse. The bottom line is that this tool needs to be integrated within the
workbench so you can add native libraries and compile them on the fly along with
the Java code, similar to the way the C Development Tools (CDT) work with the
workbench.
•
Limited firmware support
: According to Google, the NDK supports only versions
1.5 or later of the firmware. This can be a problem if you wish to support other
firmware versions, because 1.5 is fairly new and not supported in every device.
Although Google claims that the NDK only supports firmware 1.5, I have been able
to run native libraries in firmware 1.2 and 1.1 on the emulator.
•
No support for the media player, logging, and OpenGL
: Google has omitted the
libraries that are likely to change in future releases. This omission makes sense but
leaves many users in the dark when needing support for an advanced graphics,
audio, or logging mechanism. If you're in this boat, you will have to install the
header files and libraries manually.
Despite these caveats, the NDK is a very useful tool for working with native code that is worth using:
•
It provides a fast compilation environment for Windows users that rely on
VMware for compilation. This feature is very important, and the NDK is more than
enough to replace your slow VMware Linux image (especially if you run it in a
laptop) with the fast NDK, Cygwin, and Windows combination.
