I guess I missed all the excitement of the new DooM whatever, but Bethesda decided to dig up that N64 ‘DooM 3’ aka DooM 64. It’s a unique game unlike all the other console ports that were straight ports of the original DooM, although some like the 32x (Mars) or Jaguar versions that had a bunch of details removed from the levels to either spare the limited processors, and/or save precious cartridge space.
At $39 HKD, it’s $4 USD, so it’s a bit ‘pricy’ for something that is a 23 year old game, but at least I guess it’s out in the wild in a legal format. No idea if it made it to Bethesda.net as that whole thing collapsed quicker than Fallout 76 became a meme riddled disappointment.
Anyways I know I’m late to the party, but it’s all new to me.
And sure enough the are the latest versions of the game files to be found according to doom.fandom.com. Great! So to further the abuse I tried them under my mutilated DooM.
Ultimate Doom seems to work just fine on it’s own I tested it briefly warping to a few levels but yeah it just works! Doom2 however bombs out that the resource TITLEPIC is missing from the wad. How disappointing!
Naturally I just took the easy way out, and basically checked for the resource, and load another if it’s missing.
@@ -477,7 +477,11 @@
pagetic = 170;
gamestate = GS_DEMOSCREEN;
- pagename = "TITLEPIC";
+ /* the Doom 3 BFG EDITION version of Doom 2 is lacking the titlepic */
+ pagename = "TITLEPIC";
+ pagename = "DMENUPIC";
if ( gamemode == commercial )
Another interesting thing is that DooM 3 BFG also includes the gravis ultrasound bank data, so you could load them up into some other emulator and enjoy that gravis experience. I don’t know if it’s licensed or what, but it’s a nice touch.
Okay that was funny. I never thought of even trying Brutal DooM + Chex Quest. Sounds awesome.
Although I’d played a little with Chex Quest before, I never tried it on the DooM source. Oddly enough it’s Ultimate DooM. In d_main.c you can do some simple test for chex.wad and pass it off as the ‘retail’ version.
Or you can simply just rename chex.wad to doom.wad or doomu.wad. Many of the strings for DooM are compiled into the EXE, not taken from the WAD file (although it could have been, I guess it was to prevent people from making overtly cheeky mods?).
So firing up the wad under my crappy DooM port thing to MS-DOS (for the sane people just use some other Win64/OSX/Linux thing like zdoom), and when selecting an episode you’ll see the Ultimate DooM levels.
Wait? What? I though Chex Quest was a ‘total conversion’ WAD. Well it turns out that it is, and it isn’t. They replaced a lot of the default stuff from a retail version of Ultimate DooM. And what they didn’t replace, well it’s still there. And yes that does mean everything outside of the first 5 levels are the original DooM levels. And that includes the music as well!
Well isn’t that surprising! And yes that means that it’s possible to just replace the first 5 levels with the default DooM levels and have that reverse conversion. In the same way the menu screens are very Chexy too:
It certainly gives that kid like feeling to it. Although the replacement Barrons of Hell are a little too big so they do look kind of silly.
So as always I’m late to the party. I’m sure someone out there didn’t have the retail version of DooM and instead used Chex Quest for those LAN games. Although it does detect that the WAD has been modified so I don’t think it would just be all that fine.
Not that finding the original WAD files, or source to the maps, and just compiling them yourself is all that difficult, but I guess it is something else to load up.
With all the excitement regarding the DRM, disapearing Xbox versions and the terrible music in the Unity port, I thought I’d check out the PC version that is thankfully on sale on Bethesda.net. I really have lost track the number of times I’ve bought this game, but here we go again. The last time I went through this was back in 2014, with the aptly titled: “Just how ‘original’ is the Ultimate Doom on steam?” story.
And much to my surprise they use the same version of DOSBox, 0.71, and have the same AdLib pre-config, along with the missing SETUP.EXE to allow you to change it.
HOWEVER, there is one big difference, the WAD file.
The steam version includes this wad file:
Where the Bethesda.net uses this wad file:
And looking on the DooM Wiki, that means that the wad file is from the PlayStation Network version.
And it’s true they really did change the cross to a pill for the medical kit, per the red crosses request:
There is a few changes here and there but overall it looks pretty standard to me. Am I missing anything else?
So after the last round, I went ahead and dug out my crap version, where I had just recently found a nice abs() fix for a FixedDiv issue that the old iD code suffers from, and re-built a version of DooM that both used the assembly fixed division, and another with the C version. To compile I used my old GCC 184.108.40.206 to build with the flags:
I thought this may be something cool, if not kind of pointless. Anyways the MPU401 UART can be run like a traditional serial port with an IRQ, in intelligent mode, or just as a ‘dumb’ device you can just bit bang to talk to MIDI devices. So while playing with DOSBox I thought it’d be fun to take it’s emulation and plug it into Qemu.
And this is the end result.
It’s far from perfect, when it works it does tend to work well, although it fails to work with things like Return to Zork, but it does work with DMX’s sound code in DooM and the MPU401 driver for Windows 3.1
While doing this I was originally struggling with mapping the IO ports. Qemu has some functions to map in the memory model to assign a function that will trap read/write space. In this case base is 0x330 the base of the MPU401 device.
I was thinking that the port 0x331 needed to be mapped in the same way, but it turns out after looking through more of the source, it’s actually a word aligned access. So in that case you can use a switch to see which port is actually being accessed.
better performance than v2, sure, but for interactive stuff.. not so much.
So what is really going on here? Why is 0.90 so much faster when it comes to doom, and how is it possible that it’s the slowest in raw CPU performance. And fastest at IO? It appears that the crux of the issue is simply how it handles its IO, heavily favoring device performance VS CPU.
I’ll have to follow up with more builds and reading release notes to see what changed between releases. And what was it exactly that broke between gcc 3 and 4, and why the rip had to be.
I still like 0.90, if anything for it’s ability to run NeXTSTEP and NetWare.