Game Development Reference
In-Depth Information
Droid (2.1.1):
12-28 00:35:48.242: DEBUG/FPSCounter(1681): fps: 61
12-28 00:35:49.258: DEBUG/FPSCounter(1681): fps: 62
12-28 00:35:50.258: DEBUG/FPSCounter(1681): fps: 60
12-28 00:35:51.266: DEBUG/FPSCounter(1681): fps: 59
Nexus One (2.2.1):
12-28 00:27:39.642: DEBUG/FPSCounter(1006): fps: 61
12-28 00:27:40.652: DEBUG/FPSCounter(1006): fps: 61
12-28 00:27:41.662: DEBUG/FPSCounter(1006): fps: 61
12-28 00:27:42.662: DEBUG/FPSCounter(1006): fps: 61
No, that is not a typo. The Hero really achieves 60 FPS now. A workaround consisting of five
lines of code increases our performance by 50 percent. The Droid also benefited a little from
this fix.
The problem is fixed since Android 2.3. However, there are still many devices running Android 2.2,
so you should keep this workaround to maintain backward compatibility.
Note There's another, even faster workaround. It involves a custom JNI method that does the
memory move in native code. We'll look into this in Chapter 13.
Sprite Animation
If you've ever played a 2D video game, you know that we are still missing a vital component:
sprite animation. The animation consists of keyframes , which produce the illusion of movement.
Figure 8-25 shows a nice animated sprite by Ari Feldmann (part of his royalty-free SpriteLib).
Figure 8-25. A walking caveman, by Ari Feldmann (grid not in original)
The image is 256×64 pixels in size, and each keyframe is 64×64 pixels. To produce animation,
we just draw a sprite using the first keyframe for an amount of time—say, 0.25 s—and then
switch to the next keyframe, and so on. When we reach the last frame, we have a few options:
we can stay at the last keyframe, start at the beginning again (and perform what is called a
looping animation ) or playback the animation in reverse.
 
Search WWH ::




Custom Search