4 ms·

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

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_tricks.php?print=1 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.

deleted 12y ago
[deleted]
fidotron 12y ago
The thing is consoles historically let you close to the metal, which means if there's a problem it's either likely to be in hardware or your code. Since the 360/PS3 era the amount of software between the game and the hardware has exploded, and on smartphones it's in a whole other league again. When you have a problem on Android establishing who or what the problem was, especially on under development firmware, is nightmarish because of how many things are going on. The inconsistency between philosophies of different components is what makes this task truly evil. 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.
Arjuna 12y ago
"I don't know how many of those ports Carmack personally worked with [...]" 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.idsoftware.com/wolfenstein3dclassic/wolfdevelopment.htm http://web.archive.org/web/20110808014701/http://www.idsoftw...
- nutjob123 12y ago
  `"At this point one of the most experienced programmers in the team, one who had survived many years of development in the "good old days," decided to take matters into his own hands. He called me into his office, and we set out upon what I imagined would be another exhausting session of freeing up memory. 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.`
  - malkia 12y ago
    Budget allocation is really the thing to do - this way on the code side, or dummy sound file, dummy texture, dummy big model on the art side. It's been done this way, and it'll be done in the future.
- bluedino 12y ago
  >> I emailed Bobby Prince, the original composer, to see if he had any high quality versions still around, but he didn't get back with me. How do you ignore an email from johnc??
  - mlvljr 12y ago
    Those composerz are always high, or drunk -- didn't you know?
AndrewOMartin 12y ago
"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.
MichaelTieso 12y ago
I'm pretty sure he's mentioned at a QuakeCon how much of a pleasure it was developing for the iPhone/iPad. Can't find the video but I think it was at 2013 QuakeCon.

deleted 12y ago

[deleted]

fidotron 12y ago

The thing is consoles historically let you close to the metal, which means if there's a problem it's either likely to be in hardware or your code. Since the 360/PS3 era the amount of software between the game and the hardware has exploded, and on smartphones it's in a whole other league again. When you have a problem on Android establishing who or what the problem was, especially on under development firmware, is nightmarish because of how many things are going on. The inconsistency between philosophies of different components is what makes this task truly evil. 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.

Arjuna 12y ago

"I don't know how many of those ports Carmack personally worked with [...]" 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.idsoftware.com/wolfenstein3dclassic/wolfdevelopment.htm http://web.archive.org/web/20110808014701/http://www.idsoftw...

nutjob123 12y ago
`"At this point one of the most experienced programmers in the team, one who had survived many years of development in the "good old days," decided to take matters into his own hands. He called me into his office, and we set out upon what I imagined would be another exhausting session of freeing up memory. 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.`
- malkia 12y ago
  Budget allocation is really the thing to do - this way on the code side, or dummy sound file, dummy texture, dummy big model on the art side. It's been done this way, and it'll be done in the future.
bluedino 12y ago
>> I emailed Bobby Prince, the original composer, to see if he had any high quality versions still around, but he didn't get back with me. How do you ignore an email from johnc??
- mlvljr 12y ago
  Those composerz are always high, or drunk -- didn't you know?

AndrewOMartin 12y ago

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

MichaelTieso 12y ago

I'm pretty sure he's mentioned at a QuakeCon how much of a pleasure it was developing for the iPhone/iPad. Can't find the video but I think it was at 2013 QuakeCon.