Released in December of 1993 after an unbelievable amount of hype among PC gamers hooked up to the then-novel Internet, DOOM codified the standards of the nascent first-person shooter genre and was so popular that "Doom clone" was the way we described first-person shooters for years after its release. Gamers have put millions, if not billions of hours, into the title in the nearly 32 years since its launch, thanks to a virtual cornucopia of mods and user levels, but it's pretty unlikely that many of them have left the game running for upwards of two years straight. At least one person did, though, and the result is... that it crashed.
Posting at LenOwO, site admin Minki remarks that they have reproduced the expected crash by loading WinDOOM on what appears to be an ASUS MyPal A620 pocket PC from 2003 running the then-novel Windows Mobile on an Intel XScale ARMv5 SoC. Minki says that the device was modified to use a "DIY 18650 [lithium cell] based UPS which was itself connected to the USB port of my router for a constant 5V supply." They left the system running and mostly forgot about it until yesterday, when they noticed a pop-up appearing on the device and complaining of an application crash:
Like most source ports of the era, WinDOOM is based on the original source code release from 1997, and so it reproduces most features — and most bugs — of the original game. Like most large commercial software projects, DOOM has numerous known bugs even in its final 1.9 release. Among them is a curious quirk where, when playing back "demo" files internally, usually for the game's "attract" loop, the "gametic" value does not reset upon starting a new demo playback. This value is used for tracking game timing for various purposes, and it increments at a rate of 35 Hz, or 35 times per second, independent of the game's render loop.
It doesn't take even high school-level math to figure out that the gametic value never resetting will eventually result in an enormous value over time. Principal DOOM engine coder John Carmack was surely aware of this when he programmed it, but he likely reasoned that it simply didn't matter because the value is stored as a signed 32-bit integer. That means that it can reach a maximum value of 2,147,483,647 ticks before rolling over. Integer overflow behavior is undefined in C, but on x86 PCs it always results in a roll-over to the maximum negative value of -2,147,483,647. Unsurprisingly, the game doesn't handle this very gracefully, which is to say it crashes, at least on Windows Mobile 2003.
At 35 ticks per second, it takes about 1.95 years to overflow the gametic value. That's a bit less than Minki's estimate, but who knows how long the ASUS PDA sat before they noticed the error message on screen; from the photo, it doesn't look like the 22-year-old pocket computer gets a lot of attention. It's also possible that Doom4CE, the Windows CE port of WinDoom that Minki was likely using, reduces the game tick rate to 30 Hz for better frame pacing and reduced hardware demands; this was common in the console ports of DOOM, such as the Jaguar and Super NES versions. If that's the case, it would take around 2.26 years to overflow the gametic value, closer to the stated 2.5.
Whatever the case, the takeaway is this: don't leave DOOM running for two years — or any game, probably, at least if it's a game client and not a dedicated server. Other thoughts provoked by Minki's experiment include both an appreciation for scientific rigor (experimental testing of even irrelevant conclusions) and the clever re-use of "junk" hardware. That appears to be a theme of the Len0w0 boards, so kudos to that gang for doing what nobody else bothered to do.
Follow Tom's Hardware on Google News to get our up-to-date news, analysis, and reviews in your feeds. Make sure to click the Follow button.
