Game Development Reference
In-Depth Information
Other Issues
The following are other differences between OpenGL and OpenGL ES:
OpenGL ES does not render polygons as wireframe or points
(only solids).
There is no GLU (OpenGL Utility Library) in OpenGL ES. It is possible,
however, to find implementations of GLU functions on the Internet.
GL_QUADS, GL_QUAD_STRIP
, and
GL_POLYGON
primitives are not
supported.
The
The attribute stack used to save OpenGL state is not supported. This
essentially means that calls such as
glPushAttrib
and
glPopAttrib
are
not supported, including their associated constants
GL_COLOR_BUFFER_
BIT
,
GL_CURRENT_BIT
,
GL_ENABLE_BIT
,
GL_HINT_BIT
, etc.
Quake uses OpenGL standard extensions not supported by ES; for
example
GL_ARB_multitexture
, which is an Architecture Review Board
(hence ARB) standard introduced in OpenGL version 1.2.1 is not
available on OpenGL ES.
These are some of the things to watch for when you decide to port your OpenGL game to
an embedded device. When thinking about a powerful game engine like Quake (or any other
engine, for that matter), there are two basic paths when it comes to graphics rendering:
software or hardware (OpenGL). Each has its advantages and disadvantages. Let's take a
look at each one and the reason I chose to use hardware acceleration.
Is the Software Renderer a Possible Solution?
It certainly is. You could drop the Quake OpenGL (hardware) renderer and use the software
renderer also provided with the source; however, this will make the game painfully slow,
playable to around 15-20 frames per second (FPS) in a mid-size device. On the positive
side, it will also be simpler to compile. Ultimately, this is not a good solution because you
can achieve over 50 FPS if you use a hardware renderer.
NanoGL: The Life Saver
So let's definitely drop the software renderer. But what can you use to fix the big problem of
of software written by Oli Hinka for the Nokia N97 hardware. It is available under the GNU
General Public License. (You'll just have to get past the fact that it was written for Nokia. No
matter.) You can get this library up and running for Android in no time. Because it is very well
written, you can actually keep about 98% of the original C++ code. The only thing you need
to do is some initialization and dynamic loading logic, as shown in Listing 6-1.
Tip
The entire NanoGL project is available from this topic's source in the NanoGL folder.
