I was at QuakeCon 2019’s keynote. This year marks the 20th time I’ve gone to QuakeCon – I went to QuakeCon ’99 because I won a contest on Blue’s News, I wasn’t able to go to QuakeCon 2000, and I’ve been to every QuakeCon since 2001 in one capacity or another. Usually staying the whole time and participating in the BYOC, but a few years in there I was only able to make a brief appearance.
During the keynote they announced that DOOM and DOOM II were being re-released on iOS, released on Android for the first time, and that they were being released on the Xbox One, PlayStation 4 and Nintendo Switch as well, along side DOOM 3.
So naturally my first thought was curiosity – namely did they use my updated code at all. It had been my original intention that they would use the pull request I did on GitHub and put the original 2009 iOS releases of Wolfenstein 3-D and DOOM back on iOS, so if they used any of the work I did I thought that would be cool. Or maybe just the articles I wrote on it. And I initially misunderstood the commercial and thought they were putting DOOM 3 on iOS as well, however this wasn’t the case. And as a result I may be the only person in the room not that concerned about whatever the Battlemode thing was in DOOM Eternal, which looks to be badass as expected.
After the keynote I looked for “DOOM” on the App Store and couldn’t find it. Likely a consequence of the game being unavailable past the 32-bitpocalypse, I did a search on Google and saw a link for it and got to it on the App Store that way. I thought they might not update the older one and instead have everyone re-purchase it, but instead they did update the existing game on iOS so everyone who bought it before could download it again, so that’s cool.
However I couldn’t re-download it because it was over 200MB and I was on a non-Wi-Fi connection. I thought this was odd – the port I did of the original was sitting on my phone at 24MB, what could they have done to make this thing be over 200MB? Specifically it was 448MB.
Before I had a chance to get to a Wi-Fi spot to download it though, the Internet caught on fire about a different aspect of it – that it forced you to log in with a Bethesda.net account to play the game and it wasn’t working or reliable. The average person doesn’t care about how big the game is, it was just the principle of this ancient early-90’s game now requiring an online login. Bethesda claims this was a mistake and that they intended to make the login optional in order to claim “Slayer’s Club” rewards later but in any event it launched this way.
Later that evening when I found some Wi-Fi, I was able to download it and try it out. After logging in to the Bethesda thing it became clear they had not used my updated code, or Carmack’s original port, or possibly any other port at all.
Based on a combination of observations from myself and others, it looks like id/Bethesda essentially contracted out Nerve Software to make these ports and they chose to use Unity, the cross-platform game engine. I’m familiar with Unity, concept-wise, but I’m not versed in its actual usage. Unity is made in .NET, originally the specific Mono project variant of .NET whose goal was to be cross-platform but in the years since Microsoft has bought the company that was developing Mono and made .NET proper be open source so I’m not completely sure where that all shakes out but long story short, Unity has wound up being the go-to engine of choice for cross platform game development. When a company like Blizzard, who writes engines in their spare time, chooses it for a game like Hearthstone because it lets them be on everything from the iPad to the PC and Bethesda chooses it for Fallout Shelter which is on everything from Android to the Nintendo Switch, you know what it provides is valuable.
But obviously DOOM from 1993 isn’t in Unity or .NET or C# or any of those things if for no other reason than none of them existed back then. So how is it running on Unity?
Some people think the game’s code was translated to C#, which is something that’s been done before in a neato academic project capacity. Others thought maybe the game had been recreated in Unity.
I have no evidence one way or another but I suspect that they got the original DOOM code working under Unity and .NET, possibly recompiled as a Managed C/C++ thing (not sure if Unity would call it a module or a plugin or what) and Unity is just handling the output of the framebuffer to the screen and handing the inputs to the engine.
And the simple and convenient answer as to how they got around the differences of OpenGL vs OpenGL ES is that they avoided it entirely by using the software renderer.
Here’s a screenshot from a location in E1M1 in my update of the original 2009 port
Note the texture smoothing, completely wonky aspect ratio, and bar thing at the bottom
Here’s a screenshot of roughly the same place in the recent re-release
Note the chunky pixels, pillar boxed aspect ratio, and… wait how did they get rid of the bar thing?
Depending on your viewpoint this is either a downgrade or an upgrade.
It’s a downgrade in the respect that texture smoothing niceties are common features of modern source ports but it’s an upgrade in the respect that this is what the game originally shipped as.
It’s been said that one of the things that gave the iPhone an advantage early on was that they always shipped the devices with a GPU. The main reason they did this was that it allowed for smoother animations and a better user experience. Part of that “magic” it was known for. It’s why everyone was going ga-ga over this phone that in 2007 was only shipping with a subset of then-standard features and couldn’t copy/paste. But look at it scroll through the photos! Many low end Android devices shipped without a GPU to save money and the result was that they often had real slow, shitty experiences.
However it very well could have been a deal where Carmack picked a 3D-accelerated port of DOOM, not because he thought it would necessarily look better, but rather because it was the only way DOOM was going to run worth a damn on a device with a pitiful CPU by today’s cell phone standards. Or it could be that it had been so long since he or anyone else had worked with anything not reliant on a GPU that it was just not in the equation to even consider such a thing.
But id and Carmack’s DOOM port for iOS never came to Android. Like I said before, as hard as it is to believe now, back in 2009 it wasn’t a given that Android would be the other player in the field. Smartphones had gone from an overly complicated luxury item few people ever had to a simplified luxury item people were lining up for with the introduction of the iPhone and despite Microsoft and RIM owning the tiny niche market for years it was a complete unknown who was going to give Apple a run for their money. In hindsight it seems obvious that the free, open source platform from an advertising magnate would win but Microsoft literally spent billions trying to be #2, as did RIM/BlackBerry. By the time it shook out and Android was not only the other player but the clear favorite amongst the technically elite, id had decided to abandon the mobile market in favor of putting all their efforts behind finishing RAGE.
Consequently in a modern push to make the older DOOM games as available as possible, porting the game to run under Unity makes sense since Unity runs everywhere. To some extent it’s like how if you get a program running under Java then it can, to some extent, run anywhere there’s a Java Virtual Machine. So you focus on writing the Java program and Sun or Oracle focuses on getting JVMs running everywhere. Write once, run everywhere and all that. To use more of a gaming analogy, back in the day Infocom would write their text adventures like Zork and Leather Goddesses of Phobos to run on a fictitious computing platform called the “Z-Machine” and then they would write “Z-Machine” emulators or interpreters for every computing platform of the day, like the Apple ][ or the Commodore 64. To some extent today’s modern mobile and console landscape is very much like the heterogenous scene back in the 80’s.
As a result there’s now an official port of DOOM and DOOM II on Android for the first time. And it’s now on Nintendo Switch, PS4 and Xbox One for the first time (though technically Xbox One could run the ports included in DOOM 3: BFG Edition which was backwards compatible).
Like I said, these ports for iOS are not using the previous code at all – they don’t have hardware acceleration which is the big giveaway but they also have different control options. They no longer automatically open doors in the game and they also require you to tap in order to shoot, which I think would get annoying but I haven’t played them too much.
The more interesting thing to me is the DOOM 3 port. Like I said I initially thought that they were putting that on iOS as well which really made me curious but it turns out they didn’t put that on mobile, but they did put it on Switch as well as PS4 and Xbox One. Honestly I never thought they’d touch that one again since it’s pretty orthogonal to where they took the series with DOOM 2016. Instead of being about fast action it’s about survival horror and puzzle elements.
Back when I did the DOOM 3 port for iOS, I initially struggled with whether or not to port the original vanilla DOOM 3 or do the DOOM 3: BFG Edition first. Or at all. One of the reasons I was conflicted on this was that the BFG edition was the only one on GOG.com, but I ultimately got moving on the regular version faster so that won out. And if I hadn’t stumbled across that WebAssembly port, I’m not sure how well that one might have gone.
However something that didn’t hit me until later was that there might be a reason DOOM 3: BFG Edition might not be possible on iOS – its size. I’ve thought about writing to id Software about open sourcing id Tech 5 (and I still may) but an issue that a game like RAGE would have would be its size. It’s over 20GB and the iPhone has an upper size limit on the App Store of 4GB. I don’t know if that limit applies to apps you push via Xcode (which is all I’d be doing) but it hit me – DOOM 3: BFG Edition on the PC is like 11GB. DOOM 3 vanilla, with expansion pack, is like 2.2GB. Fits just fine. I suppose you could have part of the game come with the app and the rest download later and store the content via the documents folder but either way that’s going to be a hurdle for something of this size. I’ve postulated that if the Nintendo Switch can do an admirable job of handling DOOM 2016, surely the iPhone X could too but that game has a 70GB footprint on my PC so that’s not happening easily on the iPhone any time soon. Even the pared down 24GB or so on the Switch is huge.
So it’s interesting to note, then, that the versions of DOOM 3 on the Switch, Xbox One and PS4 say that they’re DOOM 3, but they’re really the BFG versions of the game. The giveaways are that they have the extra episode that the BFG edition had, they have the same menus/look/feel, they have the upgraded texture quality, and they put the number “3” centered under the “DOOM”, as opposed to being on the right side like a superscript. I suppose one reason why they’re dropping the BFG Edition moniker might be that the original version on PC and consoles also included the original games and these don’t. These were also handled by Panic Button, the guys who made DOOM 2016 work on the Switch as well as it does, which is a good call as these guys know their shit.
Nvidia has used the name “Shield” for a handful of items over the years. Initially it was the name for a device which consisted of an ergonomic game controller with a fold-up screen that ran Android. It was a neat little device but I never bought it – it was $250 and I never could find $250 that didn’t have a better purpose in mind. Later they used the name for an Android tablet with a separate game controller, the Shield Tablet. At $199 this was actually a pretty powerful Android tablet for the money. One of the games it got was DOOM 3: BFG Edition, which looks to be a deal where it’s a co-production between id/Bethesda and Nvidia. They likely wanted a showcase piece for their hardware (they did something similar with Valve on the handset thing). It’s listed on the Google Play store but only for Nvidia Shield devices.
I don’t remember what order they occurred in but Nvidia went on to make a device called Shield TV which was set top box that hooks up to your TV, and they discontinued the Shield Tablet, taking with it any rumors of there being a Shield Tablet 2 (there had also been a Shield 2 handheld tablet rumored – basically confirmed to be in the works when a prototype surfaced). But when the Nintendo Switch came out, people noticed it had the same or similar hardware as the rumored Shield Tablet 2 and it had a very similar screen to the original Shield Tablet. So the theory is that the Shield Tablet didn’t sell like they wanted it to, so they basically sold the hardware for what would have been the Shield Tablet 2 to Nintendo who made it the Switch.
The reason I point this out is that I wonder if that port of BFG to the Shield is the original basis for this Switch port. That wouldn’t necessarily explain the origins of the Xbox One and PS4 versions, though both the Xbox 360 and PS3 saw releases of the BFG edition so it’s possible they just built off of those. But all of this is just speculation on my part, I have no idea what they started with. I do remember that there was an article saying one of the advantages of trying to port to Nvidia Shield was that since there was a full OpenGL stack, no OpenGL ES nonsense like you usually experience on Android, that made things much easier.
One thing people are wondering is what this means for open source releases of any of this. I have no idea, and one of the things I’ve learned about open source licenses like the GPL in the course of working on this project and the subsequent coverage by Shacknews, Touch Arcade, Ars Technica and Slashdot is that very few people really know what they’re talking about when it comes to the GPL, even people who think they do.
There is a school of thought that says the GPL is incompatible with the Apple App Store. One of the tenets of the GPL is that there can’t be restrictions on redistribution of the binary executables. As in, if you have a word processor that’s under the GPL and ultimately you run WordProcessor.exe, there can’t be anything stopping you from getting WordProcessor.exe and sending it to someone else. So in the case of a game, if Quake was an open source game there can’t be anything stopping you from distributing quake.exe to someone else. That doesn’t mean that PAK0.PAK which has all the game assets is fair game, but the program code itself can’t be limited.
Well for one thing, the iPhone doesn’t have a user accessible file system. So you couldn’t even get to quake.exe (or more likely, a file in Quake-iOS.app) in the first place. But even if you could, the second thing is that iOS runs signed code and so even if you could get to the file and hand it to someone else, it wouldn’t work because it’s not signed for their device. When you submit an app to the App Store, you send two versions, one signed and one unsigned. The App Store does some stuff on their end to make sure nothing’s been tampered with but assuming that passes, when someone downloads your app, the App Store signs a copy of the unsigned version you submitted and signs it just for the device downloading it.
Back when the App Store first got going, as a test of this the Free Software Foundation submitted an app, a version of GNU GO, a port of a game they wrote a while back. Once it got on the App Store, they demanded Apple lift their restrictions on redistribution or delist the game. Apple delisted the game since they weren’t going to change their restrictions, definitely not for one game from one developer. This led to a widespread conclusion: that GPL licensed code was incompatible with the App Store.
A while later, the VideoLAN organization put up a version of VLC, their cross-platform video player app, on the App Store. However, one of the contributors to VLC took issue with the potential GPL violation and, long story short, Apple pulled VLC from the App Store. Several years, negotiations and a few licensing changes later it re-appeared but these two incidents combined led to the belief that GPL software was banned from the App Store.
And yet, GPL’d versions of Wolfenstein 3-D and DOOM were on the App Store for years. WordPress’ iOS app is also GPL-licensed code, also on the App Store. The reality is that there is no hard and fast ban on GPL code on the App Store, and the FSF’s interpretation of the GPL isn’t wrong if for no other reason than they wrote the thing themselves they surely know what it is, it’s just a matter of whether or not the parties involved want to make a stink about it. And presumably none of the parties here do.
That all said, I think a key thing about the GPL is derivative works. id Software wrote the games so they own the source code for the games. They then took that source code and released a version as open source. Later source port authors took those open source versions and made their source ports, and so since those are derivative works, those source ports are themselves now open source. Carmack in 2009 took source ports from the community and made the iOS apps for Wolfenstein 3-D and DOOM, and since those were now derivative works of derivative works, those ports were now open source, too, which is why he put out the source code for them as well.
However, you can likely argue that if you make a new port from the original, pre-open-source version of the code you own (even if it’s identical to the open source version you released), that it’s not considered a derivative work of an open source version and therefore you don’t have to release the source code. And in this case since it’s intermingled with Unity source code and also has Bethesda.net login hooks, I suspect they have incentive to not release that if they don’t have to. I could be wrong and they will release the source but I don’t think they will. A side effect of not being able to use a community source port is that there’s a smattering of things these ports do that were issues with the original games on modern hardware that were fixed ages ago by the community, but they have to do a clean-room version and not use any of that.
I’ll admit, when I first saw they were putting these on mobile devices I was a little bummed since I figured fewer people would give a crap about my ports but a strange thing has happened and I’ve seen an uptick in hits and views to my site, and emails asking me about the ports, especially DOOM 3. I find myself wondering if the coverage on places like Shacknews caused me to rise to the top of SEO results when people search for “DOOM iOS” or something similar. So far from making my work pointless, it’s actually introduced more people to it. That’s cool.
I’m working on a new thing right now I hope to have some progress on soon and between it being more difficult than I anticipated and also some real life distractions it’s taken longer than I had hoped (and I really thought it would be easier than DOOM 3). But after that (or before, depending on how it goes) I want to get to my planned “phase 2” wherein I go in and make a second pass at these ports. Making them more consistent with regards to menus and options and so forth. Possibly getting the SDL parts of Quake III: Arena working, possibly switching to an SDL port for Quake, etc. One of the design goals I had with DOOM and Wolfenstein 3-D was to change as little as possible in case someone fixing them up was the hurdle on getting them back on the App Store. However, now that DOOM has been updated and they clearly went a different direction, that frees me up there – I no longer need to maintain the look/feel of the old apps, making it to where someone can just drop in the official resources, etc. I can also attempt to do other things I’ve threatened to do in the past like (re)add functioning local multiplayer or bot matches.
So anyway, after a week that’s my thoughts on these new DOOM ports to iOS and other platforms.