Carmack reveals the challenges of mobile VR game development
gamasutra.com
gamasutra.com
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.
Note that official Doom platforms include the Atari Jaguar, (Three CPUs! 2 MB of ram! Can't execute code stored in system ram!) Sega 32X, SNES, PS1, (No hardware support for floating-point math!!) (http://www.gamasutra.com/view/feature/4111/dirty_coding_tric...) Sega Saturn, GBA...I don't know how many of those ports Carmack personally worked with, (I think he did the SNES, and Jaguar ports, at least) but it's safe to say he's got experience with weird consoles. It's significant that he calls out Android for being so bad, multiple times.
That said, the problems of handling screen size diversity and just getting your C++ OpenGL code with touch input wired up and working are greatly exaggerated by many.
Although it's not Doom, he personally ported Wolfenstein 3D for iPhone. You can read his write-up here [1]. Wayback Machine, FTW... it's no longer on id software's site, and I couldn't locate it in Google's cache, either.
"Rather than having a big confrontation over the issue, I told them to just send the project to me and I would do it myself."
[1] http://web.archive.org/web/20110808014701/http://www.idsoftw...
Instead, he brought up a source file and pointed to this line:
static char buffer[1024 * 1024 * 2]; "See this?" he said. And then deleted it with a single keystroke. Done!
He probably saw the horror in my eyes, so he explained to me that he had put aside those two megabytes of memory early in the development cycle. He knew from experience that it was always impossible to cut content down to memory budgets, and that many projects had come close to failing because of it. So now, as a regular practice, he always put aside a nice block of memory to free up when it's really needed.`
It's been done this way, and it'll be done in the future.
How do you ignore an email from johnc??
To support that kind of hardware without Android's SDK is worse than "no fun" it's practically impossible.
"Carmack: [..] Android was more hell to move to than most consoles [..] Just because of the way Google has to position things across a diverse hardware spectrum, and because [..] 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."
There are some applications that don't require native development (if you don't care about speed or portability) but this isn't one of them.
NativeActivity: http://developer.android.com/reference/android/app/NativeAct...
No need for any Java/JNI whatsoever.
Outside of frame buffer, OpenGL, sensors and sound APIs, everything else is only available via JNI.
Even the Play Games API only got a C++ wrapper after lots of pressure from the gaming community. At first, Google just posted a DevBytes video how to build a basic JNI wrapper for it.
If you are writing a game, everything you need is available through NativeActivity without JNI.
NativeActivity is a Java Activity that calls into C code via JNI. This C code then makes use of UNIX IPC to send the said events back and forth to the C/C++ code that runs in a separate thread.
Every time Android OS calls into the Activity there is JNI involved.
This only gets worse, if the developer plans to do a portable application, and not just a plain game.
Just because you don't write the JNI code yourself, it doesn't mean it isn't there.
While you do have the ndk-build script, NDK is just GCC (or clang, they're both included) preconfigured for cross-compiling. You can easily use ANY C/C++ build system with it, just set CC, CXX, LD, etc. environment variables to point to the GCC build in NDK folders. That way you can practically compile anything from Linux (which uses only available libc calls), not the least ffmpeg, openssl, curl, whatever you need. The JNI rules are exactly the same as JNI rules are for any desktop Java app that uses native code. There is nothing special or "funky" in NDK - it's all standard stuff you know from Linux if you ever used Java.
I'm noticing incredible amount of issues people have (at least in my sample helping them out in Freenode/#android-dev) due to not understanding this simple fact that NDK is just GCC and simply not understanding ANYTHING about how C/C++ app compiling works or not willing to learn basics of how JNI works.
All of this together qualifies as a 'funky non-standard build-system' in my book ;)
On all Apple devices only one GPU is used: PowerVR - and only one texture format for it - PVRTC
On all Android devices many different GPU's are used, and you have to ship at least TWO different formats: one DXT-like (ETC?) and one PVRTC
This can duplicate the size of your Android game compared to even PC.
But he is way over stating the problem of latency. It is certainly a problem, and lower latency is always better, but it's an engineering problem, one that will eventually be solved. We have the necessary hardware to do this right now, the problem is our current state of the industry puts hardware and software developers way too far apart, and puts startup programmers and mathematicians too far apart, too.
Of far more concern is the UX issue. NO ONE has any clue how to design intuitive UI metaphors for VR yet. Oh sure, first person shooters are obvious. But what about everything that isn't a game? Speaking from experience here [1], it is a pain in the ass to be constantly taking the head set off to switch between apps, to fiddle with the phone, to have to take it out of the headset rig to use the touch screen. What is first and foremost needed is a VR window manager.
Carmack is an excellent mathematician who understand how hardware works almost intuitively. He is not a designer; just look at Doom 3. And he does all of his work in the dark. If we were talking about web technology, people would dismiss a project for being so closed and inaccessible. We've come to expect open source for web tech, but for some reason we still have a view that default state of game tech is closed source. If VR is going to have the adoption rates necessary to have a healthy app ecosystem for users, it needs the low barrier to entry that open source provides for developers. It needs parallel, competing framework development. I don't want Oculus and Samsung to be the only arbiters of how to design VR code. I don't want users with $500 burning a hole in their pocket to be the only users who can experience VR. We can't even get people to pay $3 for a smartphone app now, adding extra hardware cost is just going to make that worse.
We need creative people hacking away at the problem in their bedrooms and garages. Carmack is pursuing a model that requires startup capital just to get to play around. I'd rather reserve that level of effort for real content, so we can eventually have real content.
[1] I'm doing this open source and I'm interested in collaborations. Please check it out and consider contributing: https://github.com/capnmidnight/VR
With a bit too much latency in VR your users will not only loose immersion, they will start vomitting and suing the maker. Google glass was ready for >20 years, but nobody dared to sell it. 20 years all the VR industry only cared about were the various UX tricks (speech, motion, position, floating windows, tiles, ...) but still latency, i.e. HW brought it to a halt. Even with special GL HW.
VR window managers were amongst the biggest projects out of Xerox Parc. Everybody had tons of ideas how to design intuitive UI metaphors for VR then. Creative people will play around nifty interfaces for sure as they did during VR times, but we still need the cheap, reactive and not overheating HW first.
Do you know where I could read more about those?
Why are we bringing VR to mobile when it still has great challenges on the PC?
"The ability to put it on your head and walk around" ? Into walls? Why?
Second, price-wise, you can sell the VR device a lot cheaper if you rely on the user's existing phone to power it, making it more affordable.
So it looks that it's going to be the other-way around: get a more basic mobile version first that will finance the more more tech-savvy (and more demanding) desktop audience.
The rest of the team feels like they were duped into the deal, and then fed some BS that they then told everyone else, too, about how much they "needed" the deal and how great Facebook is going to be for them.
Am I the only person on Hacker News that doesn't have this pathological hate of FB?