7 ms·

"he calls out Android for being so bad, multiple times", but only in the context he's using it. See my quote from the article, he's not saying Android is bad, j

"he calls out Android for being so bad, multiple times", but only in the context he's using it. See my quote from the article, he's not saying Android is bad, just it's necessarily "no fun" if you're going to support diverse hardware. 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."

sbierwagen 12y ago
Well, obviously he's talking about it in the context of VR. Printing "Hello World" to the screen is trivial on any platform, doing realtime 3d graphics is something else entirely.
- xsmasher 12y ago
  Doing any native development (C, C++) on Android is a hassle, because all of the android lifecycle events, os calls, etc. are through Java (JNI). That sounds like exactly the hassle he's talking about. 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.
  - kllrnohj 12y ago
    > because all of the android lifecycle events, os calls, etc. are through Java (JNI). NativeActivity: http://developer.android.com/reference/android/app/NativeActivity.html http://developer.android.com/reference/android/app/NativeAct... No need for any Java/JNI whatsoever.
    - pjmlp 12y ago
      Which just shows your NDK experience. 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.
      - kllrnohj 12y ago
        No, there's also controller input, touch, asset manager, and a handful of other stuff. <insert snide personal attack here> If you are writing a game, everything you need is available through NativeActivity without JNI.
        pjmlp 12y ago
        Have you ever bothered to look at the code for the NativeActivity? 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.
Pxtl 12y ago
Idunno, I think his criticism of Java as the official language on a platform that's intended to support gaming is legit. Java can be used for gaming, obviously, but it's hardly ideal.
- juliangamble 12y ago
  Agree with this - he has ranted about how he doesn't like Java before: http://armadilloaerospace.com/n.x/johnc/Recent%20Updates http://armadilloaerospace.com/n.x/johnc/Recent%20Updates
flohofwoe 12y ago
I think he's mostly talking about the Android NDK (Native Development Kit), which is required for C/C++ development and makes use of Java's JNI (Java Native Interface). On the Java side everything is nice and shiny, but the NDK is notorious for being hard to setup (especially getting debugging to work is a nightmare), it has a funky non-standard build system, and instead of an executable, a DLL must be created, which is then embedded into an Java application. Also, for all somewhat high-level features, the native code must call back into Java because most of the Android APIs are not mapped to C. All this is as far removed from a standard GCC style cross-compiling toolchain as possible, and a lot of work to integrate into an existing engine (and every couple of NDK versions something in their build system will change and the engine build system integration must be fixed up.
- izacus 12y ago
  "Funky non-standard build system"?! 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.
  - duaneb 12y ago
    I think he was referring to the build scripts and ecosystem, not the compiler.
  - flohofwoe 12y ago
    The compiler tools are fine, the problems are: (1) ndk-build scripts instead of Makefiles (2) C++ headers not in standard locations, (3) the Java build stuff which is still needed to build the final APK (ant, maven, gradle or whatever it is at the moment). All of this together qualifies as a 'funky non-standard build-system' in my book ;)

sbierwagen 12y ago

Well, obviously he's talking about it in the context of VR. Printing "Hello World" to the screen is trivial on any platform, doing realtime 3d graphics is something else entirely.

xsmasher 12y ago
Doing any native development (C, C++) on Android is a hassle, because all of the android lifecycle events, os calls, etc. are through Java (JNI). That sounds like exactly the hassle he's talking about. 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.
- kllrnohj 12y ago
  > because all of the android lifecycle events, os calls, etc. are through Java (JNI). NativeActivity: http://developer.android.com/reference/android/app/NativeActivity.html http://developer.android.com/reference/android/app/NativeAct... No need for any Java/JNI whatsoever.
  - pjmlp 12y ago
    Which just shows your NDK experience. 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.
    - kllrnohj 12y ago
      No, there's also controller input, touch, asset manager, and a handful of other stuff. <insert snide personal attack here> If you are writing a game, everything you need is available through NativeActivity without JNI.
      - pjmlp 12y ago
        Have you ever bothered to look at the code for the NativeActivity? 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.

Pxtl 12y ago

Idunno, I think his criticism of Java as the official language on a platform that's intended to support gaming is legit. Java can be used for gaming, obviously, but it's hardly ideal.

juliangamble 12y ago
Agree with this - he has ranted about how he doesn't like Java before: http://armadilloaerospace.com/n.x/johnc/Recent%20Updates http://armadilloaerospace.com/n.x/johnc/Recent%20Updates

flohofwoe 12y ago

I think he's mostly talking about the Android NDK (Native Development Kit), which is required for C/C++ development and makes use of Java's JNI (Java Native Interface). On the Java side everything is nice and shiny, but the NDK is notorious for being hard to setup (especially getting debugging to work is a nightmare), it has a funky non-standard build system, and instead of an executable, a DLL must be created, which is then embedded into an Java application. Also, for all somewhat high-level features, the native code must call back into Java because most of the Android APIs are not mapped to C. All this is as far removed from a standard GCC style cross-compiling toolchain as possible, and a lot of work to integrate into an existing engine (and every couple of NDK versions something in their build system will change and the engine build system integration must be fixed up.

izacus 12y ago
"Funky non-standard build system"?! 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.
- duaneb 12y ago
  I think he was referring to the build scripts and ecosystem, not the compiler.
- flohofwoe 12y ago
  The compiler tools are fine, the problems are: (1) ndk-build scripts instead of Makefiles (2) C++ headers not in standard locations, (3) the Java build stuff which is still needed to build the final APK (ant, maven, gradle or whatever it is at the moment). All of this together qualifies as a 'funky non-standard build-system' in my book ;)