Slashdot Mirror
Carmack On Mobile VR Development
An anonymous reader writes: After surprising everyone by demonstrating Samsung's new VR headset at IFA yesterday, John Carmack spoke with Gamasutra about the difficulties of developing virtual reality in a mobile environment. He also had some interesting comments on developing for Android: 'Okay, there's the normal hell of moving to a new platform — and I gotta say, Android was more hell to move to than most consoles I've adopted. Just because of the way Google has to position things across a diverse hardware spectrum, and because Google still doesn't really endorse native code development — they'd still rather everyone worked in Java. And that's a defensible position, but it's certainly not what you want to be doing on a resource-constrained VR system. So brace yourself: Android setup and development really does suck. It's no fun at all.' He also had insights on building compute-intensive software — if you go to full speed on all CPU and GPU cores, you can expect overheating and thermal throttling in less than a minute.
Mobile development is a joke in general. Unless you're a very established big name, you get lost in a sea of copycat apps. And then you have the piss poor performance, fragmentation and mutant java stack issues with Android. The iOS app store is run by goosestepping nazis who are happy to ruin years of development to reject your app because they might be thinking of doing something similar or because they simply don't like it. Or because it actually does something useful and the UI is "too complex" for teeny-bopper facebook junkies.
I wouldn't waste my time on developing for the current crop of smartphones if somebody put a gun to my head and a $5,000 check in front of me. NewtonOS and Windows CE were actually far more USEFUL platforms than the current game machines with dial pads.
Google strongly encourages the use of Java rather than the NDK. And have you ever *used* the NDK? It is a gigantic pain in the ass to work with, presumably because Google hasn't put a whole lot of effort into it.
Pfft, this Carmack guy. He just don't know what he's talking about. Who does he think he is, the creator of Unreal or something?
Wow you sound very knowledgeable, do you have a website or mailing list I could subscribe to?
Mod me down, my New Earth Global Warmingist friends!
I think your misunderstanding the scope of POSIX. Posix handles a number of unix type contingencies but its somewhat mute on a lot of I/O. For instance there isn't any standard for Audio. There ALSA, AudioKit (on macs, its a unix too!) , Jack, OSS, FFADO, Pulse, GStreamer and so on.
Then for graphics you've got framebuffers, GL, X windows, Mir and so on.
And pretty much no standards for driving Phone hardware, and no your favorite open source "One day a phone will use this" impleentation doesnt count.
Most of which are somewhat unsuitable and overbloated anyway.
You are right in some sense in that Androids weak point has been traditionally situating drivers in the davlik core making C/C++ coding have to loop back into java to access it , although as time goes on Google has gotten wise to this. I worked on a project maybe 4-5 years ago porting SIP software to the android and it was nearly impossible to get any sensible latency due to the fact there was no native audio driver we could find and the JNI davlik ones where just terrible. Apparently this isn't the case anymore, and newer android doesnt really have this problem.
The problem for App developers though, is that unlike iPhone where apple has tight control over loadout and has made it silky smooth to upgrade (Well compared to reflashing most droid models) Androids tend to end up stuck on the OS revision it shipped with meaning theres a hell of a lot of Android 2.x phones out there that are next to useless for cutting edge development.
Excuse the Unicode crap in my posts. That's an apostrophe, and slashdot is busted.
I have been an Android developer for two years and a Java developer for almost 15, and even a former Google employee, and...in my estimation, Carmack is 100% right.
Despite how much more I like Java than lower-level languages, Google's software stack is a complete disaster. It's poorly designed, bug-riddled garbage that I have actually considered re-writing parts of, even in the middle of a high-pressure project. What makes matters so much worse is Android's distribution model: rather than the direct-to-consumer approach that Apple takes, Google distributes Android indirectly via its device vendors, who can provide arbitrarily modified or out-of-date versions of the infrastructure that you're expected to support when dealing with angry customers who don't understand why their network stack mysteriously doesn't work.
The NDK is not an answer. It's a wreck because JNI is a wreck. I've been using JNI since 2002, and almost nothing has evolved since then - it was never anything more than a token olive branch to luddite C++ developers in 1995, and probably never will be. Ultimately, Java is excellent for mature devices (like servers), but is not suitable for emerging devices (like all the mobile devices we're seeing now) because of its runtime overhead.
Despite Apple's many shortcomings, one of the key points they get right is that mobile development needs natively compiled, non-runtime (or thin-runtime) languages. And, of course, libraries that work. Apple isn't exactly the gold standard on that either, but at least they're miles ahead of "beta early, beta often" Google.
It's back to the age-old arguments.
You can have the speed of native code, if you deal with the problems of native code (device compatibility, non-portability, security, etc.)
Or you can have the security and cross-platformness of some standardised intermediary language that basically runs as a VM at a slightly slower pace.
To be honest, I think Carmack's best work is long behind him, but there's also a need to develop on appropriate devices. If you need a device to be that fast and powerful, then aiming at smartphones and tablets probably isn't the best idea at the moment - they aren't the cutting edge of the market and won't be for a long time. In the same way that aiming at the 286 probably wouldn't have been the best idea for Doom, or that aiming only for software rendering probably wasn't the best idea for Quake.
Get the code going and providing something people want, and they will either buy devices that can run it, or ask you what you need for a port to work. By the time you're finished, the speed you're after will be available in the next device to launch.
Isn't this how cutting-edge development has always worked? Had to have huge resources and powerful machines totally unlike those seen before to make the software run at the speeds you need while you're developing it. Then a year after release, everyone has those devices and soon people are calling your code "old"?