Posted
by
Soulskill
on Thursday February 25, 2010 @02:53AM
from the can-i-get-a-hell-yeah dept.

An anonymous reader writes "Over the last two months I ported Quake 3 to Android as a hobby project. It only took a few days to get the game working. More time was spent on tweaking the game experience. Right now the game runs at 25fps on a Motorola Milestone/Droid. 'Normally when you compile C/C++ code using the Android NDK, the compiler targets a generic ARMv5 CPU which uses software floating-point. Without any optimizations and audio Quake 3 runs at 22fps. Since Quake 3 uses a lot of floating-point calculations, I tried a better C-compiler (GCC 4.4.0 from Android GIT) which supports modern CPUs and Neon SIMD instructions. Quake 3 optimized for Cortex-A8 with Neon is about 15% faster without audio and 35% with audio compared to the generic ARMv5 build. Most likely the performance improvement compared to the ARMv5 build is not that big because the system libraries of the Milestone have been compiled with FPU support, so sin/cos/log/.. take advantage of the FPU.''

In the story it doesn't say that it runs the best on the Phone it's developed: The Milestone/Droid.Also it doesn't say that it does not run on android 1.5 and that it again runs the best on android 2.0 and upwards.

The Milestone's based on an ARM Cortex A8 running at 600 MHz. It's probably the slowest-clocked of the "new" superphones. (For Americans, it's a Motorola Droid for Europe and Canada with some small software and SKU differences).

The Dingoo A320, according to the font of all wisdom, Wikipedia, is underclocked to 336MHz.

Last I looked, ARM seemed to have a definite edge in memory bandwidth, and had instructions aimed at handling media-rich applications much better than MIPS. I could, of course, be out of date on that.

So at an educated guess, I wouldn't expect your Dingoo to be able to touch a modern superphone. (Maybe at best a quarter of the processing power assuming Neon optimizations?) Of course if the Dingoo's screen is low enough resolution, then that may not matter as much.

The angles aren't actually the problem, the real problem is points on a Cartesian plane (x and y coordinates)... but angles suffer from the same thing that is the real problem. I'll explain as simply as I can (even for experienced programmers and mathematicians, I have found simple to be better, so don't take that the wrong way).

The exact location of every 3D object in a game is represented by X, Y and Z coordinates. These are currently stored in floating point, so that something can be at x=.5 and be comprehensible to the engine. This means that the object can be almost anywhere without rounding to an integer.

Your idea is that basically with small enough points, the player would be unable to tell the difference. While it's true that with tiny enough points this may be true, one of the big issues is movement within a 3D world. Essentially, the movement is something like this:

Your current position is (0,0) facing 0 degrees. You are getting 60 FPS. You press the forward key, moving north.

See what's starting to happen here? Floating point representations of coordinates are vital to preserving the object's exact coordinates. If you used ints for these values, you'd be forced to round and lose a lot of precision. That adds up, especially when these calculations are being performed every 34 seconds. The model would 'jitter' and seem to be very slightly spasming, which would look terrible. Unfortunately floating point numbers are required here.

Actually, with Xcode and iPhone OS you do not have to jump through all the hoops this guy did. GCC in Xcode generates ARM6 or ARM7, Thumb or non-Thumb code - no futzing with compilers, tools or worrying about taking advantage of the hardware FPU. You can also mix Objective C, C, C++ code and libraries with very little effort - no Java to NDK-level and back calling BS. Stuff like this is easier, NOT harder, on iPhone OS.

Floating point is most certainly not required. Choose a suitable coordinate system scale relative to the minimum necessary movement scale to eliminate jitter. Bonus points if you choose a power of 2 scale factor: now some divisions can be replaced with bit shift operations.

You don't have nearly the dynamic range of floating point, but you *can* implement rotation matrices, vectors, time and distance and physics calculations. You just have to be careful to keep the values in range.

3d games before Quake 1 used integer, fixed-point math and worked just fine (e.g., Doom). The trig was all done using look-up tables. Fixed-point allows you to retain enough of the precision for everything to work smoothly.

Quake 1 used floating point because they (id) found that with the introduction of the Pentium that floating-point was actually faster for the Quake 1 game engine.

For modern-day portable devices I wonder if this is still true. I also wonder how well trying to mix fixed-point math and 3d hardware APIs would work. Switching to integers could be done, but it would complicate the code and would likely be slower.