Maes

Well, if he's going to try a Win32-compatible OS, there are several stripped-down "mostly" Win32 compatible OSes, for use in Real-Time systems, e.g. Phar Lap, RTOS32 and others.

And wait until you realize the HORRORS lurking in the toilet of DOOM.

Post it on The Daily WTF?

Perhaps Hard Head? It was crazy enough to include exploding lips (or at least walking dentures)

It's actually not a bad source port per se, you could think of it (engine wise) as what vanilla Doom could eventually have become, as it's pratically MBF with Room-over-Room extension (remotely related to Eternity's, from which most of cDoom-exclusive maps are converted from, BTW).

Probably also a remnant from a time when Doom was meant to run at 70 fps #inb4Blastfrog

I don't know if "vanilla compatible" maps are actually tested in Vanilla doom, or just Chocolate Doom for the same reason that prBoom/prBoom+ is preferred over the original. If they are habitually tested in vanilla, then we're looking at a kind of double standard here. Maybe we need a "Chocolate Boom" at this point? A modern-OS-friendly port of the original DOS Boom, but made in the same bug & limitations compatibility philosophy of Chocolate Doom, without adding anything to "fix" said limitations?

If there's something even more boring than cave maps, that has got to be sewer maps. Same problems exactly, plus the overall shittiness (heh) of the deal. There was a thread about a year ago about how many "Boom compatible" maps are actually "prBoom+ compatible", and wouldn't actually work with the original Boom for a variety of reasons, first and foremost being that nobody is seriously gonna whip out vanilla Boom from 1999 to test it, when prBoom+ promises to fill the deal better and more conveniently. That specific error you posted though looks more like an IWAD or game mode misconfiguration, like loading a Doom WAD in Doom II, or Boom's namespace merging not working as intended.

That's another interesting topic altogether: how efficient are those pimped-up Doom engines compared to a modern game engine for visuals of the same complexity. After all, a modern engine will be created from scratch to include what was tacked-on a-posteriori to the original Doom's engine (though it's debatable how much is really left of it e.g. in GZDoom). It's also worth noting that most Doom engines are still being developed and evolved with the mindset of being -primarily- a software-rendered engine, and that hardware acceleration is just another tacked-on afterthought, implemented with vast differences in different ports, so that not even the common ancestry of the software-based renderer remains.

Even the engines using the simplest method like overlapping sectors or the oldest ones using dummy sectors like Eternity or cDoom allowed for an arbitrary number of 3D floors (or "rooms") over other rooms. It was never limited to just one extra room. It's just that this extended 2D/2D+ style of mapping becomes increasingly clunky and unnatural the more rooms/levels you add, and at a certain point a fully 3D engine becomes preferable. Actually, if you carefully examine modern FPSs' environment, you'll find that there often aren't many environments with multiple overlapping floors per-se, but rather, complex decorative geometry. If you tried really hard, a good percentage of e.g. Quake's or even Doom 3's environments could be "Doom-ified" with little loss in gameplay value or architectural complexity. Those that don't (e.g. factories full of catwalks) can be adequately served with even basic RoR extensions. The tough part are all those decorative machines, rails, etc. and in general all decoration that is a 3D object rather than a decal or a wall/floor texture.

Bad idea. How do you know that they're not insulting your mother in their posts?

Back then, it wasn't much of a choice: unless you were aware of the NOVERT utility and knew about the WASD layout back in 1994, using the mouse with the default settings (or worse, a mouse-only scheme) was often a total trainwreck. I remember the 1st (and only) time I tried the default mouse controls in Doom back in the DOS days, only to spin uncontrollably in-place and jerk back & forth when I least wanted it. So I said nope, and went back to good old keyboard controls, which at least were predictable. I only switched to WASD when I started playing other FPS games, and that was quite late, in 2003 or so.

That's hardly the "official" default, though. It feels quite similar to the WASD+mouse controls for what regards navigation only, but the fire/use/run actions are nowhere nearly as convenient to use.

And none of them ever were official or shipped with the engine, for that matter. Or always as easy to use as Doombuilder. Try making even a simple room with two sectors in DEU and see what I'm talking about.

Heh, weird. I always thought they were far more inaccurate than other hitscanners. Perhaps it's their faster firing rate (compared to a zombie) but not near that of a chaingunner that highlights their inaccuracy? Do chaingunners and sergeants also have the same damage and precision distributions per shot/pellet?