Quake 3 For Android 137
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.''
DUDE You're incredible (Score:5, Funny)
Re: (Score:1)
... Steal the code, kill people ...
I thought you were talking about the action in Team Fortress ...
Re: (Score:2)
Re: (Score:2)
Where's my flying car?! (Score:2, Insightful)
Re:Where's my flying car?! (Score:4, Informative)
Re: (Score:1)
I remember seeing smartphones from around 2002 or before. And handheld PDAs existed before that - it was pretty obvious that we'd get Quake 3 after a matter of time, and that it wouldn't be long.
The reasons against flying cars are to do with laws, liability, and required training, not technology.
Re: (Score:2)
I'd say, "who gives a fuck? Quake 3 sucked. When will Unreal Tournament be available?"
Re: (Score:1)
Re: (Score:2, Flamebait)
Yah. It's known as a "joke."
Thank you, though, you humorless pedantic asshole.
Great job. (Score:2, Insightful)
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.
Proves it equal to a Dreamcast (Score:2)
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"
Proving that a device is "Quake 3 complete" allows the major labels to gauge what kind of game can be sold to owners of this device. For example, a device that can run Quake 3 can in theory run other games that use id Tech 3. It can also run games ported from console platforms comparable to platforms on which Quake 3 was released, such as Dreamcast games and early PS2 games.
Hmmm. (Score:5, Informative)
Dunno why TFA didn't include it, but there is video [youtube.com].
Re:Hmmm. (Score:4, Informative)
doesnt work on Nexus One
Re: (Score:2)
Running Demos (Score:1)
Re: (Score:3, Informative)
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.
Re: (Score:1)
Re:Running Demos (Score:4, Informative)
Re: (Score:1)
Speconly?! Far too useful.
They're too busy adding bloom effects
Re: (Score:2)
Thanks for using ioquake3 :)
Re: (Score:2)
Re: (Score:3, Informative)
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 o
Re: (Score:2)
There are two big differences between the MIPS32 you'll find in the A320 and, basically, any recent ARM SoC. One is that the last two or three generations of ARM chips have hardware FPUs, while the A320's CPU does not. If you're running Debian, then the A320 will be painfully slow, because the default Debian install for it was configured for hard float, meaning that every floating point instruction (including loads and stores to the FPU registers) raises an invalid instruction interrupt. This is then cau
Not impressed (Score:1, Troll)
Re:Not impressed (Score:5, Insightful)
Re: (Score:2)
Re: (Score:2)
So what you are saying is that a open source coder could never compete with a commercial one?
I think he's saying that comparing a team of coders to one guy doing this in his spare time isn't the greatest comparison. What I took away from that post is that this is a pretty impressive achievement.
Re: (Score:2)
Re: (Score:2)
On the other hand, the GPUs you find in these phones have more in common with the current generation of PC GPUs than with those that were available when Quake 3 launched. UE3 is optimized for modern GPUs, but Quake 3 is not.
Re: (Score:3, Insightful)
Re: (Score:2)
Re:Not impressed (Score:4, Informative)
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 [szico-vii.com]
http://www.szico-vii.com/uploads/photos/17.jpg [szico-vii.com]
http://www.szico-vii.com/uploads/photos/31.jpg [szico-vii.com]
http://www.szico-vii.com/uploads/photos/42.jpg [szico-vii.com]
Re: (Score:2, Insightful)
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.
Other than that you don't have to GPL your game, which you do if you use an ioquake3-based engine. And it's likely that Epic will make Mobile Unreal available at a lower price to current Unreal engine licensees.
Copylefted engine with non-free assets (Score:2)
Re: (Score:2)
Assets get copied out no matter what you do. It happens all the time. Don't worry about it and make a game people want to buy.
Re: (Score:1)
So lets sum up here.
This kwaak3, something that runs on most android phones, works, is a game, something you can download right now...
That's less impressive then a youtube video of a game that, doesn't work on the iPhone 2G, 3G or ipod touches, doesn't have networking, etc ...
Why do I get the feeling you're shitting on this simply because it's not related to the iPhone?
Re: (Score:2)
I'm not impressed. Epic had Unreal Engine 3 running on the iPhone back in december last year...
But they have yet to ship a Linux binary. BAH!
Kudos! (Score:1)
Really! This is one of the main reasons I love open source, things like this and others would be imposible/difficult with the iPhone OS.
Re:Kudos! (Score:4, Informative)
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.
Re: (Score:1, Insightful)
I guess every platform has disadvantages. Android apps have to jump through hoops to use C libraries, and iPhone apps have to jump through hoops to get off the developer's box and onto actual hardware.
I'm going to go wash my hands.
Re: (Score:2)
You think syncing your phone with iTunes is 'jumping through hoops to get off the developer's box'?
Please to be getting a clue about the topic before you attempt to troll.
Re: (Score:3, Insightful)
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)
Re: (Score:2)
I wonder how fast... (Score:5, Funny)
> Quake 3 optimized for Cortex-A8 with Neon is about 15% faster without audio
I wonder how much faster it will be without video
Re: (Score:2)
Re: (Score:2)
You know Android doesn't run on Java, right?
Next question?
Mouse (Score:1)
Re: (Score:2)
I wonder if a bluetooth mouse could be used, maybe some sort of 10 key for the left hand and you would be set.
Re: (Score:1)
Re: (Score:2)
Android doesn't even have support for Bluetooth HID keyboards, and SPP is only supported halfway via a buggy app that refuses to stay connected for longer than 10 minutes at a time... :(
Re: (Score:2)
That's entirely possible, if they implemented a custom driver or something like that. As of now, it's not possible to just pair up a Bluetooth keyboard and call it a day... and even my stone-aged WinMo phone from 5 years ago could do that.
It's one of those things you think is a given when you buy the phone, so you don't even bother researching whether or not Bluetooth HID is supported, and the surprise comes 2 months later (after all money-back deadlines are expired), when you actually try to connect a keyb
Re: (Score:1)
I disagree, I think you should look around the world by moving the phone, then thrusting it forward to shoot. This would be awesome...for everyone else watching.
Re: (Score:1)
Re: (Score:1)
Re: (Score:1)
Re: (Score:2)
lets do video (Score:1)
What about the N900? (Score:5, Interesting)
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.
Re: (Score:1)
Re: (Score:3, Informative)
And here's the Symbian s60 port [mbnet.fi], released in November 2008. And a video showing accelerometer support [youtube.com].
Re: (Score:2)
Oh and the Symbian port is using lightmap lighting, whereas the Android video seems to show vertex lighting.
Re:What about the N900? (Score:5, Informative)
Re: (Score:1)
There's a map for that (Score:2)
If you're looking for a very nice (open) phone, I'd go with the N900.
The advantage of the port to Motorola Droid is that Verizon Wireless carries Motorola Droid. In the United States, the big three wireless carriers don't give a discount for bringing your own phone, so most people who want coverage choose a carrier first and then choose one of the phones that the carrier subsidizes. And as I understand it, Nokia has had trouble getting its Symbian-based and Maemo-based phones into Verizon, Sprint, and AT&T. So which U.S. wireless carrier do you recommend for use with the
Re: (Score:2)
T-mobile and Vodafone both carry this phone (with excellent packages I might add: I'm currently on a 2 year contract, 20 pounds per months for 300 texts, 300 callminutes and 'unlimited' internet)
But as said: If you have the chance, certainly have a look at this phone.
I decided to not go with the iPhone (though I love its intuitive interface), as I don't like their restrictions with regards to getting your own software/third party software on there. I think this motivation w
Re: (Score:2)
Just another note: (Score:1, Informative)
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.
Re: (Score:3, Informative)
Are libraries even involved (Score:2)
I'm not familiar with ARM architecture, but this bit still sounds suspicious to me:
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.''"
On x86 at least, no C compiler worth its salt would even generate a call to a library function for something like sin or cos - why bother with all the overhead of a call, if ultimately it's a single instruction in the FPU?
Now, one trick there is that it actually depends on compiler settings - whether you specify "precise" floating-point mode (which is fully standard conformant), or "fast" mode. Only the latter seem to produce
Re: (Score:1)
Re: (Score:2)
I believe most (older?) versions of ARM come without a FPU. Presumably the ARM processor on the Droid/Milestone is one of those that do have a FPU and thus can take advantage of it.
That's what I've been told, not sure whether it's correct.
Re: (Score:1)
How about integers instead of floating point? (Score:2)
Re:How about integers instead of floating point? (Score:4, Informative)
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.
Re: (Score:2)
Re: (Score:2)
Excellent description, helps explain it well.
Re: (Score:1, Informative)
http://en.wikipedia.org/wiki/Fixed-point_arithmetic
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.
Re: (Score:3, Informative)
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
Re:How about integers instead of floating point? (Score:4, Insightful)
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 [wikipedia.org].
Cheers!
Re: (Score:2)
You could also use fixed point arithmetic. :)
Re: (Score:3, Informative)
You don't know about fixed point math I take it?
Re: (Score:2)
Re: (Score:3, Informative)
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 ha
Re: (Score:2)
Also, we need a -1 factually incorrect mod. Don't mean to single you out, but quite a few posts are modded up when there's a mistake. People who seem sure of what they're saying are usually assumed to be correct (just like in real life!).
Re: (Score:2)
My apologies, you are correct. The calculations are made per frame- a simple typo on my part.
Re: (Score:2)
Because integers don't hold enough precision to be useful in modern graphics.
Believe it or not, they are currently useful for simply shaded/textured objects on phone-sized screens. You can use fixed point 16:16 numbers for that.
But they start being a hindrance after that because of the limited precision, and the amount of work you have to do to bring values back in line when doing multiplies or divides. You're generally wasting your time if the device you're targeting has a hardware FPU.
You can see for your
I thought the NDK couldn't use opengl (Score:2)
did they fix that?
Re: (Score:1)
What about the classics? (Score:2)
To heck with Quake. How about all those old 16 bit strategy games that are like made for cellphones? CIV series? MOO? StarCraft? MoM? Where are they?
Re: (Score:3, Insightful)
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.
Bad ass (Score:2)
time for RA3 (Score:2)
So when it's the Android, it's news? (Score:2)
I’m sorry, but not only does the N900 run Quake 3 (and very smoothly) [nokia-n900.com]. No, it also runs Windows 95 [dailymobile.se] and MacOS X [thenokiablog.com]!
But I haven’t seen news for this on /.
Funny that this could never ever happen with iPhone (locked down), so we’re at least safe from that. ;)
Re: (Score:2)
I agree the parent is a troll, but not a very good one. From the very second sentence of the linked post:
When you troll without even bothering to read two sentences of what's linked that's just... sad.
Moreover, the iPhone falls significantly short in one area: the N900 runs at 800x480, and the Milestone/Droid at 854x480. The iPhone is presumably pushing ~37% of the number of pixels. (Assuming the game is running at native
Re: (Score:2, Informative)
Re: (Score:3, Insightful)
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/ [taptaptap.com]
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
Re: (Score:2)
Of course, I should add, with 2.6x more pixels to paint, a DROID or Nexus One, even with a faster GPU, might well lose a frame-per-second race against an iPhone 3GS.