Slashdot Mirror
Quake 3 For Android
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.''
Team fortress by any chance? Steal the code, kill people, I can help with whatever task is needed.
I thought by the time we would have Quake 3 on a phone I'd be flying to work in my hover car. Imagine taking a trip back in time a few years and telling your younger self that Quake 3 would be [almost] playable on a cell phone - hopefully you wouldn't reply with a "whats a cell phone?"
Q3 is still one of my favorite games. The first thought that came to my mind when I read this was
"Do we have to hear about every case of someone porting something like this(doom,quake, etc)to a new device"
But considering all the effort that you put into doing this, I must say that I admire your dedication and attention to detail.
Great job.
Dunno why TFA didn't include it, but there is video.
demos recorded on any 1.32 should work with ioquake3, you may need to run them with the demo command manually. I can't verify that they'll work or not with this android fork.
Check out ioquake3.org for a great, free, First-Person Shooter engine!
> Quake 3 optimized for Cortex-A8 with Neon is about 15% faster without audio
I wonder how much faster it will be without video
Yeah and that is Epic Software doing that. They aren't exactly a hobbyist working without pay...
The N900 has also recently received a port of IOQuake3: Have a look at their site for more details.
If you're looking for a very nice (open) phone, I'd go with the N900. No, I'm not from Nokia, just a -very- satisfied customer.
When you shoot a mime, do you use a silencer?
If that is "Unreal 3", then it's a very, very stripped down version. It doesn't even look like it has pixel shaders, which removes all benefit to using it over the Quake III engine.
By the way, the Quake III engine is capable of handling visuals that look better than the screenshots you linked to. Here are a few examples of what the Quake III engine can do.
http://www.szico-vii.com/uploads/photos/16.jpg
http://www.szico-vii.com/uploads/photos/17.jpg
http://www.szico-vii.com/uploads/photos/31.jpg
http://www.szico-vii.com/uploads/photos/42.jpg
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.
On my project page I mention that Android 1.6 is required since I used the Android 1.6 NDK (previous versions didn't support OpenGL).
GPUs in these phones are more common with what was around during the Q3 times. They support OpenGL ES 1.0.
-]Phreak Out[-
The iphone 3gs has one other advantage it uses the PowerVR SGX 535 instead of the 530 which is used in the Milestone and N900. The 535 is about twice as fast.
Demos should run well but from the main menu they don't work for some reason. During development I always ran them from the quake3 console (so 'demo four') and that works fine.
Those games (at least starcraft, I've never heard of the others) are not open source. The Quake 3 engine is. That is one of the benifits to open sourcing your old engines like iD does, your games will get ported to every platform in existance that can even remotely handle them.
"linux is just DOS with a UNIX like syntax" -- Galactic Dominator (944134)
I don't know anything about the code either, but I can take a stab.
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.
New X Coordinate = old_X + time * Sin(angle) = 0 + .3 + 1 microsecond * 0 = 0 .3 + 1 microsecond * 1 = 1
New Y Coordinate = old_Y + time * Cos(angle) = 0 +
You are now at (0,1), which is as you'd expect. Let's mess things up a bit.
Your current position is (3, 6) facing 146 degrees. You are getting 34 FPS. You push the forward key, moving at the angle 146.
New X Coordinate = old_X + time * Sin(angle) = 3 + 0.566666667 * .75011107 = 3.42506294
New Y Coordinate = old_Y + time * Cos(angle) = 6 + 0.566666667 * 0.661311865 = 5.62525661
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.
Check out my sci-fi book "Lacuna" at http://goo.gl/MVxX8
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.
You can still use integer math to represent fractional values. For example, using the upper 16 bits as the integer part, and the lower sixteen as the fractional part.
Something like this only implemented with inline assembly:
Int32 fMult( Int32 a, Int32 b)
{
return (Int32) (((Int64) a * (Int64) b)>>32);
}
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.
Unfortunately floating point numbers are required here.
Not quite. When doing this stuff on a platform with limited or non existent floating point support you can always use fixed point arithmetic.
Cheers!
You don't know about fixed point math I take it?
- Michael T. Babcock (Yes, I blog)
Well, the iPhone 3GS sure outperforms the older PowerVR MBX-Lite use in all previous iPhones. The MBX-Lite used in the older iPhones does about 1Mpolys/second at the iPhone's 50-60MHz GPU clock speed.
Some real benchmarks: Tap Tap (a big iPhone developer) found the 3GS about 4x faster in 3D applications:
http://www.taptaptap.com/blog/iphone-3gs-blows-away-iphone-3g-in-3d/
There is a THEORY that the GPU is an underclocked PowerVR SGX 535 (Intel calls this the GMA500), largely based on some #defines in the Apple SDK. And also because they include the VXD370 media accelerator, which has usually been coupled with higher-end SGXs. Of course, TI didn't need this, they have had their own media acceleration technology going back to before the DaVinci SOCs (what you find in most higher-end PMPs going back some years). This is a chip custom-made for Apple by Samsung, so in truth, unless Apple's talking, we may not know. The Anandtech article also postulates the SGX 520, but again, any number of core + clock speed combinations lead to the same answer.
http://www.anandtech.com/gadgets/showdoc.aspx?i=3579
But a full SGX 535 runs at 200MHz and does 28 MPolys/s. Pretty good chance that's not what the iPhone 3GS is running -- there are no benchmarks showing even half of that performance. Most benchmarks show the 3GS running 3x to 7x faster at 3D, an assuming the faster CPU isn't part of that, you could get with an SGX 535 at 50MHz, an SGX 530 at 100MHz, or an SGX 520 at 200MHz. The real answer might be known to developers: the SGX 520 has a single Universal Scalable Shader Engine (USSE) pipeline, the others add multiple pipelines for additional performance. Not that you'd necessarily have this exposed in OpenGL.
It is not debatable about the DROID/Milestone.. it contains OMAP 3430, which contains the PowerVR SGX 530 GPU core. TI quotes a peak of 10Mpolys/sec. which this chip at normal clock speeds; it's programmable, typically run in the 100-160MHz range (14Mpolys/sec is the peak you can expect with 200MHz clock). Of course, there are all sorts of folks boosting their DROID to much higher clock speeds, but this what you'd expect in stock performance. And it's quite possible there are still optimization issues in Android that no longer apply to the slightly more mature iPhoneOS.
-Dave Haynie
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.
Then again it’s completely useless, since >99% of the iPhone users could not install it anyway because of the lock-in. ^^
The iPhone would be a cool phone... If it at least had half of the freedoms you have with any other smartphone on the market... (exchange the battery, install all software, run java (j2me+) apps, tons of small functions)
Any sufficiently advanced intelligence is indistinguishable from stupidity.