Game Development Reference
In-Depth Information
are on the market so far, and it limits the maximum frames per second (FPS) we can achieve
to 60. We know our code is good enough when we run at that frame rate.
Note
While 60 FPS would be nice to have, in reality it is pretty hard to achieve such performance
on many Android devices. High-resolution tablets have a lot of pixels to fill, even if we're just
clearing the screen. We'll be happy if our game renders the world at more than 30 FPS in general.
More frames don't hurt, though.
Let's write a little helper class that counts the FPS and outputs that value periodically. Listing 7-14
shows the code of a class called
FPSCounter
.
Listing 7-14. FPSCounter.java; Counting Frames and Logging Them to LogCat Each Second
package
com.badlogic.androidgames.framework.gl;
import
android.util.Log;
public class
FPSCounter {
long
startTime = System.
nanoTime
();
int
frames = 0;
public void
logFrame() {
frames++;
if
(System.
nanoTime
() - startTime > = 1000000000) {
Log.
d
("FPSCounter", "fps: " + frames);
frames = 0;
startTime = System.
nanoTime
();
}
}
}
We can put an instance of this class in our
BobScreen
class and call the
logFrame()
method once
in the
BobScreen.present()
method. We just did this, and here is the output for a Hero (running
Android 1.5), a Droid (running Android 2.2), and a Nexus One (running Android 2.2.1):
Hero:
12-10 03:27:05.230: DEBUG/FPSCounter(17883): fps: 22
12-10 03:27:06.250: DEBUG/FPSCounter(17883): fps: 22
12-10 03:27:06.820: DEBUG/dalvikvm(17883): GC freed 21818 objects / 524280 bytes in 132ms
12-10 03:27:07.270: DEBUG/FPSCounter(17883): fps: 20
12-10 03:27:08.290: DEBUG/FPSCounter(17883): fps: 23
Droid:
12-10 03:29:44.825: DEBUG/FPSCounter(8725): fps: 39
12-10 03:29:45.864: DEBUG/FPSCounter(8725): fps: 38
12-10 03:29:46.879: DEBUG/FPSCounter(8725): fps: 38
12-10 03:29:47.879: DEBUG/FPSCounter(8725): fps: 39
12-10 03:29:48.887: DEBUG/FPSCounter(8725): fps: 40
