nce upon a time, game programmers had to write code in assembler and make many other optimizations to deliver games that ran well even with the slow processors and small memory address spaces available then. Today, processors running at gigahertz speed and hundreds of megabytes of RAM help programmers climb out of the Black Programming Art Tower—a place where only a few could survive.

In fact, the power unleashed by modern PCs is so huge, even compared to computers only ten years ago, that programmers began ignoring the optimizations and creating high-quality games that require increasing amounts of processor power, memory, and disk space. These less-optimized games have proven at least as addictive as the earlier games. In other words, the massive increase in computing power simplified game programming by removing the need for the very knowledge and optimizations that once made game programming an arcane art. For a while it seemed as if the Black Programming Art Tower was closed for good. Only a small number of game companies still push our desktop computers to the edge.

But history repeats itself. The handhelds and mobile devices gaining devotees today have characteristics very similar to the less-powerful desktop computers of the past. Small-footprint devices are back—but if you want great games-to-go, they bring with them the need to master obscure optimization techniques. One such optimization involves fixed-point math.

Fixed-point Math
FP math is a great optimization technique, particularly for math-intensive applications such as 3-D games; but instead of showing you how to perform arithmetic operations on FP numbers, a topic already covered in many other places, this article focuses on how to optimize FP operations to achieve a greater performance.

FP Libraries
One of the easiest ways to implement FP math in your program is to use one of the free FP libraries available. You substitute standard arithmetic operations with calls to the FP library. While this works well in most cases and lets you use fractions in your program, making large numbers of calls to methods in another class, the FP class, eats precious CPU cycles.

This is a direct consequence of the way the Java Virtual Machine works. For every method call, the JVM builds a new stack frame and copies method parameters to that newly created stack frame. Upon completion, it must copy the method's return value to the previous stack frame. Finally, it must destroy the current stack frame. That's a lot of work!

To reduce that workload, you have to remove the calls to the FP class methods in your code.