Slashdot videos: Now with more Slashdot!

View

Discuss

Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

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 has been running on handhelds for ages, and the source code was open for all except the last few versions, although it didn't need to be because Quake ran it in a bytecode interpreter so it was cross-platform. If you mean TFC or TF2 then you should specify.

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?"

When Epic Games is nice enough to release the source code to the earlier versions of the Unreal Engine. They released the source for the renderer (which people have ported to DX 9 [cwdohnal.com], and DX 10 [kentie.net]), but not the full engine. id Software is courteous enough to release their old engines under the GPL, so ports like this happen fairly regularly.

"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.

I've been unable to get any demos to work which were recorded on the 1.32c exe, obviously because this is based off ioq3. If anyone cares to record or get vanilla demos for showcase purposes I'm all ears. OSP/mods appears to run, but being able to play match demos to show off gameplay would be the BOMB.
Also, id software should REALLY take notice here and release a spectator-only client for QuakeLive which runs on Adroid;-)

I've tried OSP with no luck (author already stated no mod support just yet), but am having a hard time finding any vanilla 1.32c demos thus far. If anyone finds them I'll certainly test and report back!

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

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

I'm not impressed. Epic had Unreal Engine 3 running on the iPhone back in december last year: http://www.anandtech.com/gadgets/showdoc.aspx?i=3695 [anandtech.com] Granted, it's a modified version and I don't think there's a working game available yet that uses it, but the engine is several generations newer than the Quake 3 one... Still, nice job. It's weird to see 'big' games appearing on tiny devices. Didn't think the mobile technology would be this advanced so soon, tbh.

Being three months later isn't exactly not competing. I'd say it's pretty good for a single freelancer competing with a massive corporation. Mind you, Quake 3 was running on S60 mobile phones back in 2008, so that makes Epic's port 18 months late, which means, by your logic, that a multimillion dollar corporate development team can't compete with a few open source coders.

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.

I highly doubt that Unreal 3 would run better than the Quake 3 engine. Modern does not equal better. Most of the things that newer engines do better are somewhat worthless on a cell phone. You want simplicity and speed on a cell phone, not abstraction and flexibility. I would think that the Quake 3 engine would knock the pants off of Unreal 3.

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.

The recent ones support OpenGL Es 2.0 (the first generation iPhones used an old, cheap, GPU to keep costs down and profits up). They're slower, but most of these devices only have an 800x480 device, so you don't need as much raw power as a desktop because you have a quarter of the number of pixels to draw (or fewer), which also means you can get away with less complex geometry and so on.

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.

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.

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.

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)

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

There are some FPS on the iPhone were you move using a virtual joystick in the lower left corner and look around using the rest of the screen. It's not perfect but it's ok to play casually on a small mobile device.

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

Sorry, I'm from the UK here:)
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

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.

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

Yes I'm compiling kwaak3 using -ffast-math but in all cases it uses libm. It is only a hypothesis on why perhaps a generic soft-float build is not that much slower than a floating-point optimized build. You would expect that a soft-float version is a lot slower because quake3 uses floats for most of its math.

How about integers instead of floating point? Without knowing anything about the code, how would integers perform here? Couldn't a static table with, eg 3600 precalculated angles simulate what you want?
.

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.

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.

Not quite true:-)
A 32-bit floating point number can't have more precision than a 32-bit integer number. The opposite in fact - you only have a 24-bit mantissa in the floating point. And worse, the larger the number becomes, the less precision you have.
That is not to say that using integer for 3D math is a good idea. It isn't, but for different reasons.

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

The original PSX didn't have an fpu. All 3d calculations were done with integers. A big part of porting PC games was the conversion from floating point to integer.

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!).

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.

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.

I just purchased a droid and I am looking into all of the things I can do -- the free apps, playing with the SDK, running a web & ftp server on the phone, etc. This project is by far one of the best projects I've seen and I can't wait until you have it available so I can put it on my phone. I'm a huge idSoftware and Quake 3 fan. Great work!

I agree the parent is a troll, but not a very good one. From the very second sentence of the linked post:

I had seen ports of Quake3 to the iphone and the N900 which have similar specifications

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