## Measuring Smoothness

How smooth is smooth? The smoothness of a game or other graphics-heavy 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.

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

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.

0 0