Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Android Cellphones Games

Carmack On Mobile VR Development 60

Posted by Soulskill from the duct-taping-a-phone-to-your-eyeballs dept.
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.
This discussion has been archived. No new comments can be posted.

Carmack On Mobile VR Development More

Carmack On Mobile VR Development

Comments Filter:

  • BWAHAHAHA (Score:5, Insightful)

    by ogdenk ( 712300 ) on Friday September 05, 2014 @05:17PM (#47838179)

    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.

    • Re: (Score:2, Insightful)

      by Anonymous Coward

      One of the nice things about mobile apps is that you often have to work for performance, and the big guys generally (excluding, e.g., Carmack) don't have a leg up. At least in my field, the big guys are used to pretty much anything goes -- meaning much of their libraries would have to be completely re-written to work on mobile -- while my newer code was designed and written with efficiency in mind from the beginning. Even on the latest generation hardware, nobody's got an app out that outperforms what mine

      • Re: (Score:2)

        by ogdenk ( 712300 )

        It's not the hardware that sucks. The hardware is freaking awesome. It's the software stack that falls short. They're cool consumer handheld gaming and facebook toys as-is. As a TOOL for computer users to get work done they are pretty cumbersome and far less useful than most people would like to think.

    • Re: (Score:2)

      by tlhIngan ( 30335 )

      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.

      Actually, Apple's App Store is a perfect model for console development, because Microsoft, Sony and Nintendo have far more stringent requirements. And no, you generally don't hear of them because the

      • Actually, Apple's App Store is a perfect model for console development, because Microsoft, Sony and Nintendo have far more stringent requirements.

        But is there a good reason why these stringent requirements don't benefit the end user?

  • fucking google should adopt posix (Score:1)

    by Anonymous Coward

    Should have used POSIX instead if Java.

    Basically write code that is native, compiles on each system using standardized compilers and with full Unix compliancy. This is what POSIX is. All they would need to do is have a compatible compiler for each CPU architecture which they already have..

    Apps would be 10 to 100 times faster, with lower power utilization, more battery life, greater response and performance..

    Not surprising that the full power of these devices is also unuseable, laptops and portables are alwa

    • Well. No. The problem you'd run into is that some apps on some phones wouldn't compile in any meaningful period of time

      Dalvik solves a lot of those problems.

      (And introduces new ones to boot.)

    • 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

    • POSIX doesn't have an API for high-speed graphics, or for power management.

      Other than that, well, actually they do support POSIX. :/

  • The other thing that was a real surprise to me was how important the power management was, not just for battery life, but for performance. Because if you go ahead and fire up all four cores at the top clock rate and draw a bunch of stuff, you overheat within minutes. If you really load everything onto the system that can draw power, you will probably thermally throttle down in under a minute. So you literally just can’t use all the capabilities of the system at the same time.

    • Re: (Score:2)

      by tlhIngan ( 30335 )

      It's not an interesting quote, it's the truth.

      People rag on Apple etc., when they only do dual-core, and yet, it's the reason WHY they do dual-core.

      Quad-core (and "octacore") are a joke because the power consumption is high. Even at 100mW/MHz (=1W/GHz) which is what ARM does, the sheer speed of modern SoCs mean they dissipate a fair bit of power.

      E.g., a 2.5GHz Snapdragon with 4 cores is 10GHz or 10W of power consumption. Of power-efficient ARM at that, which is 10W of heat in a small area that has very lit

    • The human brain has an analogous limit. A healthy human being uses 100 percent of his or her brain, just not all at the same time.

  • Google still doesn't really endorse native code development

    What the heck is he talking about? Android has the NDK - native development kit - which allows development in c++ using the standard libraries and even The OpenGL ES API, which is exactly right up Carmack's alley. Plus his code will compile straight across under iOS as well. I really don't understand what he feels is preventing him from going that route, unless he wants to do a ton of UI widget stuff that is platform specific.

    • Re: (Score:3, Insightful)

      by Anonymous Coward

      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.

      • Re: (Score:1)

        by Osgeld ( 1900440 )

        NOOO how could native C++ ever be a pain in the ass

      • Yes, I most certainly have. Check out Flickitty in Google Play or the iTunes App store. 99.9% of my code is identical in both platforms, which of course is all C++.

    • Re: (Score:2, Funny)

      by Anonymous Coward
      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?

    • Android has the NDK - native development kit - which allows development in c++ using the standard libraries and even The OpenGL ES API, which is exactly right up Carmack's alley.

      He's using the NDK, but it's not really standardized. Different phones have different hardware configurations, and when you are doing 3D graphics, different phones have to be programmed differently.

      To some degree this is a problem with iPhones, but there are not nearly as many models, so there is similarly less work.

      • Re: (Score:2)

        by tlhIngan ( 30335 )

        He's using the NDK, but it's not really standardized. Different phones have different hardware configurations, and when you are doing 3D graphics, different phones have to be programmed differently.

        To some degree this is a problem with iPhones, but there are not nearly as many models, so there is similarly less work.

        The bigger difference though is the OpenGL capabilities report is more accurate on iOS, or easily worked around. Given there's only 7 (soon to be 8) different GPUs out there (of which realistica

  • Carmack FTW. (Score:5, Insightful)

    by engineerErrant ( 759650 ) on Saturday September 06, 2014 @01:17AM (#47839745)

    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.

  • Design to an appropriate platform. (Score:3)

    by ledow ( 319597 ) on Saturday September 06, 2014 @04:38AM (#47840041) Homepage

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

    • You can have the speed of native code, if you deal with the problems of native code (device compatibility, non-portability, security, etc.)

      Theoretically this has a solution: separate the model and view [wikipedia.org]. Make your model in the portable language and a view for each platform in the platform's preferred language. Then it's just a recompile to hit each instruction set. But the problem comes when a platform requires a language not shared with other platforms, such as J2ME phones requiring 100% Pure Java, or Windows Phone 7 and Xbox Live Indie Games requiring C#. (In theory it's verifiably type-safe CIL for the .NET CF, but in practice that means C#.

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

      Some persistent Slashdot users claim that if "devices that can run it" aren't already widely deployed, then the product inherently isn't "something people want". They use the example of a PC in the living room, which is currently an unprofitable niche because most people who want to play video games on a TV are allegedly better served by a PlayStation $digit, despite its lack of selection and lack of user-made game mods, as opposed to a full-size PC. If you disagree with this, I'd be interested in what you

  • Sounds like phones need some sort of thermal interface to their dock, which can then have large heatsinks to suck the heat out.

Slashdot Top Deals

"An idealist is one who, on noticing that a rose smells better than a cabbage, concludes that it will also make better soup." - H.L. Mencken

Close