PEEKABOO 216

Figure 10.7: The final version: a see-through cube

appear anywhere in the code, so you substitute a larger or smaller image easily.

You can see our progress so far in Figure 10.6, on the previous page.

10.9Peekaboo

Just for fun, let’s make the cube partially transparent. Add this to

GLRenderer.onSurfaceCreated( ):

Download OpenGL/src/org/example/opengl/GLRenderer.java

boolean SEE_THRU = true; // ...

if (SEE_THRU) { gl.glDisable(GL10.GL_DEPTH_TEST); gl.glEnable(GL10.GL_BLEND);

gl.glBlendFunc(GL10.GL_SRC_ALPHA, GL10.GL_ONE);

}

MEASURING SMOOTHNESS 217

This turns off depth testing, because we want to see obscured objects as well as foreground ones. It also turns on a blending mode that lets the opacity of objects be based on their alpha (transparency) channel. The net effect is that the back faces of the cube will appear through the front faces. For the final result, see Figure 10.7, on the preceding page.

I’ll leave it to you to implement an option to turn that on and off. Try playing around with different blend modes to get cool effects.

10.10 Measuring Smoothness

How smooth is smooth? The smoothness of a game or other graphicsheavy program is defined by how fast it can update the display screen. This is typically measured by counting the number of screens or frames per second (FPS) that are displayed. Different people perceive different speeds as “smooth.” 15–30FPS is sometimes acceptable to casual gamers, but more serious players have come to expect a higher rate such as 60FPS or more. I recommend that you make every effort to reach a consistent rate of 60FPS. That corresponds to the maximum refresh rate of most LCD displays and is also the speed used on popular gaming platforms such as Sony’s PlayStation and PlayStation Portable (PSP).

Note: This won’t always be possible, because some Android phones are fill-rate limited, which means their 3D graphics hardware is underpowered compared to their display resolution. Depending on what you are drawing, they may simply not be able to write pixels on the screen fast enough to achieve 60FPS. The first generation of 800x480+ phones such as the Nexus One and Droid Sholes suffer from this issue. Faster devices are coming out that won’t have the problem.

A high frame rate is challenging, because at 60FPS you have only 1/60th of a second (16.67 milliseconds) between calls to onDrawFrame( ) to do everything that needs to be done, including any animation, physics, and game calculations, plus the time it takes to actually draw the scene for the current frame. The only way to tell whether you’re making your FPS target is to measure it.

FAST -FORWARD >> 218

To do that, try adding this bit of code to the end of the onDrawFrame( ) method:

Download OpenGL/src/org/example/opengl/GLRenderer.java

numFrames++;

long fpsElapsed = System.currentTimeMillis() - fpsStartTime; if (fpsElapsed > 5 * 1000) { // every 5 seconds

float fps = (numFrames * 1000.0F) / fpsElapsed; Log.d(TAG, "Frames per second: " + fps + " (" + numFrames

+ " frames in " + fpsElapsed + " ms)"); fpsStartTime = System.currentTimeMillis(); numFrames = 0;

}

Every five seconds it will display your average FPS number to the Android system log (see Section 3.10, Debugging with Log Messages, on page 69). If this number drops below your target rate, then adjust your algorithm and try again. Keep iterating until you reach your target. A profiler such as traceview4 may also come in handy. Note that you should avoid the temptation to display this on the screen on top of your other graphics because the act of displaying it will throw off the number.

If you try this now, you may notice that the emulator runs much more slowly than the actual device. In my tests I saw about 12FPS on the emulator and closer to 60FPS on a real phone. The lesson here is that for performance testing you can’t trust the emulator.

10.11 Fast-Forward >>

In this chapter, you learned how to use Android’s 3D graphics library. Because Android uses the industry-standard OpenGL ES API, a wide variety of additional information is available if you want to learn more. In particular, I recommend the Javadoc for the JSR 239 API specification.5 For other graphics tips, check out the developer talks at the Google I/O conference.6

4. http://d.android.com/guide/developing/tools/traceview.html

5.http://java.sun.com/javame/reference/apis/jsr239

6.http://code.google.com/events/io/2009/sessions/WritingRealTimeGamesAndroid.html and

http://code.google.com/events/io/2010/sessions/writing-real-time-games-android.html