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

Comments

DUDE You're incredible

[linhares]

Team fortress by any chance? Steal the code, kill people, I can help with whatever task is needed.

Re:DUDE You're incredible

[BlueTrin]

... Steal the code, kill people ...

I thought you were talking about the action in Team Fortress ...

Re:DUDE You're incredible

[TheRaven64]

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.

Re:DUDE You're incredible

[cpricejones]

How about Crisis?

Where's my flying car?!

[TeamMCS]

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

Re:Where's my flying car?!

[pipatron]

Hm? Quake 3 has been available for my Nokia since 2007 or 2008 or something.

Re:Where's my flying car?!

[mdwh2]

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:Where's my flying car?!

[Blakey Rat]

I'd say, "who gives a fuck? Quake 3 sucked. When will Unreal Tournament be available?"

Re:Where's my flying car?!

[Anonymous Coward]

Good for you asshole. We don't care. Stop being a fucking wet blanket.

Re:Where's my flying car?!

[Ascagnel]

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, and DX 10), 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.

Re:Where's my flying car?!

[Blakey Rat]

Yah. It's known as a "joke."

Thank you, though, you humorless pedantic asshole.

Re:Where's my flying car?!

[Anonymous Coward]

Hey, thanks for that DX10 renderer link. I'd been using the DX9 renderer for Deus Ex but the DX10 version looks to have some nice features like automatic FOV and no more Z fighting textures. Looks like I'll be installing Deus Ex for the millionth time to check this out.

Re:Where's my flying car?!

[Anonymous Coward]

In other news, your Nokia is still a bulky unattractive euro phone, and bragging on the internet still isn't getting you laid.

Great job.

[ipquickly]

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.

Wow great job

[Anonymous Coward]

Now how about porting to a phone people actually buy (read: iPhone)?

Re:Wow great job

[Holmwood]

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 resolution on all 3 platforms). If so, fairly impressive pixel-pushing for the other two platforms.

Re:Wow great job

[Thunderbird2k]

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.

Re:Wow great job

[hazydave]

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.

Re:Wow great job

[hazydave]

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.

Hmmm.

[Anonymous Coward]

Dunno why TFA didn't include it, but there is video.

Re:Hmmm.

[ionix5891]

doesnt work on Nexus One

Re:Hmmm.

[Anonymous Coward]

Maybe the video wasn't included because it is gawdawful? 85% of screen real estate occupied by background and two hands; long, long wait before game-play starts, no closeup of control inputs.

Re:Hmmm.

[TrancePhreak]

it runs but the controls do not work. author admits this on the website.

Re:Hmmm.

[Anonymous Coward]

Yet?

Running Demos

[get quad]

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 ;-)

Re:Running Demos

[Time Doctor]

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:Running Demos

[Anonymous Coward]

1.32c is NOT based off of IOQ3. It was a security fix released a couple years ago by Id.

Re:Running Demos

[get quad]

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!

Re:Running Demos

[borl]

Speconly?! Far too useful.

They're too busy adding bloom effects

Re:Running Demos

[Thunderbird2k]

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.

Good job

[Anonymous Coward]

This is actually great news. I have been developing a game based on ioquake3 for a couple of years now. Each time someone ports the Q3 engine to a new platform, it opens up a whole new platform that I can target. Good job.

This does bring up another question. What are the features of the target ARM CPU and what clockspeed does it run at? I have a Dingoo A320 (MIPS32 based CPU with a native clockspeed of 400MHz) that seems to barely run Quake 1. If Q3 can run on an ARM powered phone, it should be able to run at similar speed on the Dingoo.

Re:Good job

[Time Doctor]

Thanks for using ioquake3 :)

Re:Good job

[Holmwood]

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.

Re:Good job

[Anonymous Coward]

How about a GP2x Wiz?

Re:Good job

[Anonymous Coward]

And thank you for cleaning up many of the longstanding bugs in the Q3 engine. I've run through a whole laundry list of Quake based engines before settling on ioquake3. It may not have the graphical niceties of something like Xreal or Darkplaces, but it's a lot more stable and will run in many places that the others won't. Even so, I swear that every time I start writing Q3 shaders, I am able to come up with pretty close approximations of almost any effect used in more modern engines. Many people don't realize just how powerful the Q3 engine is.

In response to Holmwood, yes, the Dingoo's CPU is underclocked to 336MHz. Most of the Dingoo owners I've spoken to generally run everything at 400MHz without issue, since that is the speed that the CPU is rated for. Battery life doesn't seem to be affected much by the speed bump either. If the ARM has access to a FPU or GPU of some kind, I could understand how it is able to pull it off (the Dingoo has neither, as far as I know). It is odd that I can run Quake 2 under psx4all (Playstation emulator) and it doesn't seem that much slower than a ported game like Quake 1. Oh well, I guess there isn't much point to running Q3 on a handheld that doesn't even have network connectivity. Thanks for the info.

Re:Good job

[TheRaven64]

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 caught by the kernel, which inspects the old program counter, decodes the instruction (in software) and emulates it. This means FPU-intensive code runs at about 1% of the speed of a hardware implementation. Recompiling with softfloat support (which changes the calling conventions, so you need to recompile everything from libc up) makes it a lot faster.

The other big difference is that recent ARM SoCs all come with a GPU. The latest generation all support OpenGL ES 2.0, so you get a fully programmable pipeline (shaders and so forth), while the older ones have ES 1, which supports only the fixed-function pipeline. Even the old ES 1 GPUs are faster and more capable than anything on the market when Q3 was released.

In short, the A320 is a pretty useless machine. It's massively underpowered even by handheld standards (the Nokia 770 will be faster in most uses). The newer cheap MIPS-based use the Loongson 2F, which is a 64-bit superscalar MIPS III implementation (still little endian), and two FPUs, but a lot of them still don't come with a GPU, so you're looking at software rendering only. They're more than powerful enough for Quake 2, but Quake 3 required OpenGL hardware, so they'll probably struggle a lot.

Re:Good job

[Jarik C-Bol]

American McGee's Alice. when you told people it was the Q3 engine, jaws dropped.

Not impressed

[PommeFritz]

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

Re:Not impressed

[Anonymous Coward]

But, you forget - nokia had quake 3 before the jesus phone even existed. Where's your god now?

Re:Not impressed

[Beelzebud]

Yeah and that is Epic Software doing that. They aren't exactly a hobbyist working without pay...

Re:Not impressed

[Grey Ninja]

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.

Re:Not impressed

[Anonymous Coward]

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

Re:Not impressed

[Anonymous Coward]

So what you are saying is that a open source coder could never compete with a commercial one?

Re:Not impressed

[Narishma]

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:Not impressed

[Anonymous Coward]

One open source hobbyist coder can seldom compete with a team of paid full-time employees at a multi-million dollar company.

Re:Not impressed

[TrancePhreak]

GPUs in these phones are more common with what was around during the Q3 times. They support OpenGL ES 1.0.

Re:Not impressed

[LingNoi]

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:Not impressed

[fuzzix]

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!

Re:Not impressed

[TheRaven64]

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.

Re:Not impressed

[TheRaven64]

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.

Re:Not impressed

[tepples]

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.

Re:Not impressed

[Abstrackt]

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:Not impressed

[Anonymous Coward]

You don't have to open source your entire game if you use an engine covered under the GPL. A number of projects like World of Padman and Warsow have closed art assets. Space Trader is even a fully commercial game based on the GPL id Tech 3 source.

Personally, I have been working on a game based on id Tech 3 and do not intend to open source my resources. I will probably distribute the game for free, but I am retaining full copyright to all art, music and sound assets. My only requirement is that I don't misrepresent the license for the engine and that I provide a link to the id Tech 3 source code. I'll also probably include the names of the people who worked on the engine in the in game credits.

Tons of closed source and/or commercial products use open source software without issue. It's a pro, not a con.

Re:Not impressed

[Anonymous Coward]

From what I've read the unreal 3 port used the pixel shaders, since it would only run on the opengl ES 2 devices, and not on the original and 3g iphones.

Re:Not impressed

[Anonymous Coward]

if you can do something like this, you won't be jobless for long. These are the kinds of things people would love to have on their resume.

Kudos!

[viraltus]

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!

[jo42]

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:Kudos!

[Anonymous Coward]

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:Kudos!

[BitZtream]

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:Kudos!

[Hurricane78]

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:Kudos!

[JAlexoi]

The problem is only that Objective-C is just plain horrible, and you just can't escape from using it.

licka my

[Anonymous Coward]

sucka my stroka my COCK!

I wonder how fast...

[dvh.tosomja]

> 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:I wonder how fast...

[Anonymous Coward]

Slow audio is due to Java interface, is there anything the Java is good for ?

Re:I wonder how fast...

[BigGerman]

you are right Java sucks. Oh, maybe for running of thousands of enterprise apps all over the world?

Re:I wonder how fast...

[MikeBabcock]

You know Android doesn't run on Java, right?

Next question?

Mouse

[mxh83]

The problem is that FPS like Q3 needs a proper mouse. Otherwise its no fun.

Re:Mouse

[Unending]

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:Mouse

[haystor]

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:Mouse

[Anonymous Coward]

Not true. Perfect Dark was a wonderful game. But I have to agree that the controls as is are sucky. Most people are used to movement on their left hand, and looking around with the touch screen doesn't really seem to work right now. Either the acceleration curve needs to be tweaked so you can keep your finger in one spot in the corner without having to swipe it all over the place, or looking around needs to be moved to the direction pad, possibly with some aiming assistance like most console fps games have.

Re:Mouse

[golden age villain]

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.

Re:Mouse

[mxh83]

How long can you keep "thrusting"?

Re:Mouse

[mxh83]

I find those games extremely painful to play..

Re:Mouse

[mxh83]

Imagine how stupid you would look with that..

Re:Mouse

[bemymonkey]

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:Mouse

[Stormwatch]

Indeed, because they got it backwards - it's far more comfortable if you move with the right thumb!

Re:Mouse

[Anonymous Coward]

I don't own a touch-based smartphone, but aiming with a touch screen on FPS games for the DS works quite well. Local multiplayer in Metroid Prime Hunters is a blast. Of course, with the android you're limiting by only having one screen, but perhaps a section of the screen could be designated as a "mousepad".

Re:Mouse

[Anonymous Coward]

Actually, you will find videos of the Archos 5 IT, running Android, being used with BT mouse and keyboard..

Re:Mouse

[bemymonkey]

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

lets do video

[Teque5]

here is the conspicuously missing video: http://www.youtube.com/watch?v=q9Xaz7ECI4M

What about the N900?

[anomnomnomymous]

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.

Re:What about the N900?

[WML MUNSON]

Right on. Where was the Slashdot post when that came out?

Re:What about the N900?

[kamapuaa]

If you read the article (I know, I know...) this is actually based on the N900 port.

Re:What about the N900?

[eggz128]

And here's the Symbian s60 port, released in November 2008. And a video showing accelerometer support.

Re:What about the N900?

[eggz128]

Oh and the Symbian port is using lightmap lighting, whereas the Android video seems to show vertex lighting.

Re:What about the N900?

[r0b!n]

You should also read this article on the N900 port. http://slashdot.org/submission/1180314/Nokia-N900-Hardware-failure---USB-port-falling-off

Just another note:

[Anonymous Coward]

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:Just another note:

[Thunderbird2k]

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

Re:Just another note:

[Anonymous Coward]

BTW: I tried it on an Archos 5 IT, (Android 1.6, A8 @ 800Mhz) using button mode to get access to arrow-keys.

And it doesn't really work.
UI is laggy, and in-game there's massive graphics corruption (everything but weapons (in hand or as pickups) is mostly white or flickering...).
Are there any settings that might fix it?

Are libraries even involved

[shutdown -p now]

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 an inlined implementation of sin & cos. Are you sure you're compiling with -ffast-math?

Re:Are libraries even involved

[Anonymous Coward]

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.

Re:Are libraries even involved

[Tapewolf]

AFAIK, most ARM processors do not currently have an FPU. Maybe as FPUs become more common support for using the FPU directly will be added. Just a guess.

Re:Are libraries even involved

[quadrox]

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:Are libraries even involved

[Thunderbird2k]

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.

mo3 0p

[Anonymous Coward]

things I still elected, we took dim. IfQ *BSD is

How about integers instead of floating point?

[G3ckoG33k]

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

Re:How about integers instead of floating point?

[Sasayaki]

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
New Y Coordinate = old_Y + time * Cos(angle) = 0 + .3 + 1 microsecond * 1 = 1

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:How about integers instead of floating point?

[Anonymous Coward]

Very, very new at 3D programming, but aren't those equations calculated 34 times per second, and not every 34 seconds? Asking for my own edification.

Re:How about integers instead of floating point?

[olsmeister]

You need to scale your values of X, Y, and time so that the time component is larger relative to X and Y.

Re:How about integers instead of floating point?

[MrDoh!]

Excellent description, helps explain it well.

Re:How about integers instead of floating point?

[Anonymous Coward]

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:How about integers instead of floating point?

[Jenny Z]

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.

Re:How about integers instead of floating point?

[jgostling]

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!

Re:How about integers instead of floating point?

[kyz]

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 yourself what it looks like when you try and use fixed point values for 3D calculations. Get a Playstation (i.e. Playstation 1) emulator and run a game at 1024x768 or higher. You'll now see all the vertexes pop whenever you move about, even though they're meant to be static.

It's because the PS1 hardware used fixed point values throughout, and while the programmers were careful to make sure they wouldn't pop 1 pixel on a 320x256 screen, they didn't check what happened when you had a larger screen size.

Re:How about integers instead of floating point?

[Anonymous Coward]

Actually, no. Floating point numbers don't magically store more precision than integers; they just compress it so there's more density at lower values, and a higher maximum range. There are game physics engines (the physics engine is what stores position/velocity) that use a 32 bit integer grid for all the calculations. If you've got a 1km square arena, with 32 bit ints for the coordinates, then the describable points are 200 nanometers apart. While I suppose you could count that as jitter, unless your game involves calculating the thin film interference between adjacent surfaces, you should be fine.

Re:How about integers instead of floating point?

[MikeBabcock]

You don't know about fixed point math I take it?

Re:How about integers instead of floating point?

[cecom]

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.

Re:How about integers instead of floating point?

[idealego]

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.

Re:How about integers instead of floating point?

[Anonymous Coward]

You need to scale your values of X, Y, and time so that the time component is larger relative to X and Y.

Exactly. Replace:

New X Coordinate = old_X + time * Sin(angle)

With:

New X Coordinate = old_X + alpha * time * Sin(angle)

Scale alpha as appropriate. Problem Solved.

Re:How about integers instead of floating point?

[Anonymous Coward]

Except fixed-point math can, and historically has, solved this problem. Modern games don't bother with fixed point since floating point is fast on modern hardware. Take some older games (the Descent source being the one I'm familiar with), and you'll find they used fixed point integer math to get a speed boost while retaining precision.

Re:How about integers instead of floating point?

[lolocaust]

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

Re:How about integers instead of floating point?

[Sasayaki]

You could also use fixed point arithmetic. :)

Re:How about integers instead of floating point?

[Sasayaki]

My apologies, you are correct. The calculations are made per frame- a simple typo on my part.

I thought the NDK couldn't use opengl

[Punto]

did they fix that?

Re:I thought the NDK couldn't use opengl

[Anonymous Coward]

As of NDK 1.6 OpenGL is supported.

Re:I thought the NDK couldn't use opengl

[Thunderbird2k]

As of NDK 1.6, OpenGL is supported.

Re:I thought the NDK couldn't use opengl

[Anonymous Coward]

Yes.

Look carefully now slashdot... This is news!

[Anonymous Coward]

for a change

Accelerometers

[Anonymous Coward]

Wow I can't believe there is so much trouble over the controls, just use the accelerometer to control panning then you can play with just one hand on the dpad for movement and shooting. That would be amazing.

Caution: Rickroll

[Anonymous Coward]

Parent link is a Rickroll.

See yesterday's NS

[Anonymous Coward]

Or a magnet-powered natural gesture interface.

What about the classics?

[jonr]

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:What about the classics?

[Sir_Lewk]

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.

Re:What about the classics?

[Anonymous Coward]

yep, go ask the owners of those games to release the source code under AN FREE AND OPEN SOURCE license.

Proves it equal to a Dreamcast

[tepples]

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.

There's a map for that

[tepples]

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

Re:There's a map for that

[Anonymous Coward]

There's really only one US wireless carrier to use the N900 with. That's T-Mobile.

The phone will work with any US GSM carrier just fine, but it only supports the AWS 3G frequencies of T-Mobile in the USA.

I get about 800kbps down and 300-400kbps up around Washington DC on my N900.

Re:There's a map for that

[tepples]

So I guess people who live in the gray areas on this map are out of luck.

Re:There's a map for that

[anomnomnomymous]

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 was a blessing in disguise as the N900 is the same, if not better than the iPhone with regards to interface. With its 4 desktops, plenty of customization possibilities, this is every tinkerer's dream-phone.
Damn, reading back this post, I -should- get paid by Nokia: I look like a damn ad! ;-)

Re:There's a map for that

[Anonymous Coward]

That seems like a very good deal since the n900 costs around £450 unlocked and the two year contract only costs £480. Which provider are you with? I couldn't find anything about the n900 on T-Mobiles's site, and the only plans that Vodafone seems to offer with the n900 are at £40 a month.

Bad ass

[SphericalCrusher]

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!

modg up

[Anonymous Coward]

eto be about doing

Copylefted engine with non-free assets

[tepples]

I see three drawbacks of the approach of using a copylefted engine with non-free assets:

1. It's easier to crack the encryption protecting your GPL game's assets from being copied than the encryption protecting a fully proprietary game's assets from being copied.
2. In online multiplayer games or in single-player games with online score rankings, it's far easier to cheat in a GPL game.
3. The gatekeepers of some platforms, such as Sony and Nintendo game consoles and Sony and Nintendo handhelds, prohibit all copylefted code. This came up when the developers of the Wii version of Pajama Sam started from ScummVM, a copylefted clone of the game engine that powered the original PC version, and Nintendo objected to the release of the source code of the Wii version. This will only become more widespread as projects under GPL version 2 or later shift to GPL version 3 or later, whose "Installation Information" requirement appears to conflict with the developer agreements for even semi-open platforms like the iPhone.

Re:Copylefted engine with non-free assets

[MikeBabcock]

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.

time for RA3

[pak9rabid]

The next logical step, of course, is RA3 =D

Allright

[Anonymous Coward]

Got it working, using vertex lighting and newer pk3's.
Except of course, it's pretty unplayable, as the software/touchpad keys don't suit themselves for this kind of usage..

So when it's the Android, it's news?

[Hurricane78]

I’m sorry, but not only does the N900 run Quake 3 (and very smoothly). No, it also runs Windows 95 and MacOS X!

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