AVGN reviews Chex Quest

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.

	if ( !access (chex,R_OK) )
	{
		gamemode = retail;
		D_AddFile (chex);
		return;
	}

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.

Chex Quest, Thy Flesh Consumed!

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!

E2M2 from Chex Quest

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.

E1M8

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.

Bethesda DooM for the PC

$1.70 USD!

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:

c4fe9fd920207691a9f493668e0a2083 doom.wad

Where the Bethesda.net uses this wad file:

e4f120eab6fb410a5b6e11c947832357 doom.wad

And looking on the DooM Wiki, that means that the wad file is from the PlayStation Network version.

Now with extra hell!

And it’s true they really did change the cross to a pill for the medical kit, per the red crosses request:

iD DooM on the left, Bethesda DooM on the right.

There is a few changes here and there but overall it looks pretty standard to me. Am I missing anything else?

Degrading qemu performance in DooM Part II

ticks for demo (fewer is better)

VersionASM FixedDiv/FixedMulC
0.9.0259268
0.10.5299300
0.11.0316317
0.12.0289281
0.12.5290282
0.14.0282274
0.14.1280269
20180430192195
20190218187187

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 2.7.2.3 to build with the flags:

-m486 -msoft-float -ffast-math -O2 -fforce-addr -fomit-frame-pointer

So here we go using the versions of Qemu that I can build quickly with GCC 3.4.5 MinGW, along with the last two pre-built Win64 builds.

It’s kind of interesting just how close the performance is between the two versions.

Naturally the real test is to run it on actual hardware, and to try a few versions of Watcom C.

Maybe the real takeaway is that Qemu runs GCC built code better…?

Adding DOSBox’s MPU401 to Qemu 0.90

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.

register_ioport_write(base, 8, 1, mpu401_ioport_write, s); register_ioport_read(base, 8, 1, mpu401_ioport_read, s);

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.

static uint32_t mpu401_ioport_read(void *opaque, uint32_t addr) { switch(addr&0xf) { case 0: return(MPU401_ReadData(addr,0)); break; case 1: return(MPU401_ReadStatus(addr,0)); break; default: return(0xff); break; } return(0xff); }

Pretty simple, right?

And from there it’s a matter of mapping the DOSBox MPU code, along with the Windows interface code. Since I’m not using intelligent or IRQ mode, I just amputated the code where applicable.

If anyone wants to look at what I did to merge into anything else (and probably do a better job!) it’s on sourceforge as mpu401.c.

Otherwise the binary is available on sourceforge:

Download Qemu090b

Degrading qemu performance in DooM

Quick table… its late.

I’m using MS-DOS 5 & this benchmark suite loaded into a VMDK, and ran a few tests to check performance numbers.

version2 3d bench3 chris bencha doom ticksc quake demo
0.9.0182257.426346.4
0.10.5204247.649141.7
0.12.5305.1296.747546.8
0.13.0305.3284.351145.7
0.14.1289.6285.350945.2
0.15.0213.4176.952015.3
1197.9152.154615.5
2.4.0.1392.1340.674324.2
3.1.50405462.3149733.3

I snagged 3.1.50 from https://qemu.weilnetz.de/w64/

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.

SharpShooter3D

When the best friend becomes an enemy, and the main villain becomes you yourself and blood flows like a river, someone will definitely have to answer the main question – Who is behind the awakening of ancient evil and is there still a chance for humanity?

PUBLISHER:Dagestan Technology
DEVELOPER:HeadHuntersGames

I saw this ‘gem’ pop up on steam for $3.50 HKD (so $0.50 USD?) and thought what the hell let’s try it out. SharpShooter3D is well, a DooM mod of sorts, but it also feels a lot like Duke3D with the inclusion of vehicles and ‘moving room/vehicles’ like train cars. At it’s heart is GZDoom 3.3.2 which states in the license:

Parts of the voxel code in the software renderer use code from the
BUILD engine by Ken Silverman and are used under the terms of the
GPL v3 with permission.

Well isn’t that cool! The best of Duke3D and Doom! All in one.

It captures the imagined feel of the eastern block, old factories, nuclear power plants, lots of guys in trainers & Adidas all over the place, along with copious alcohol and milk (yes milk is the health thing here!).

Not to mention the punk sound track is pretty good for such a seemingly ‘low end offer’. Had this come out 20 years ago, it really would have set the world on fire, and probably set off quite the few controversy, but today it’s a discount mod that no doubt the devs did put a bit of work into.

I have no idea if the game is 90% off for the rest of the world, but I’d say it’s worth a look at the price.

Updated my DooM port


x68000 still won’t build on this, lots more to either separate out or just fork out.  No biggie.

The big plus is for GCC 2.x and higher that use DJGPP v2 runtimes is that the allegro music and sound work.  It tests faster than Watcom 10/11 or Open Watcom ..  probably DMX vs Allegro I suspect …

Things to do..

  • Upload my GCC 2.7.2.1 cross toolchain
  • Upload the Freedoom build chain (again)
  • Test on real machines, the 486 and the P3

So yeah.  Limited progress.

Also it’s nice being able to cross build Allegro 3.12 in 10-15 seconds vs the hour+++ in emulation.

Project is in the djgppv1 cross thing

https://sourceforge.net/p/crossdjgppv1/DooM/ci/master/tree/

git access to clone

git clone git://git.code.sf.net/p/crossdjgppv1/DooM crossdjgppv1-DooM

make with:

make -f makefile.djgpp_v2

and you should be good to go