SaladBadger

It's worth noting that all of Dr. Sleep's levels were part of what was envisioned as a 9-level episode replacement, themed after various cantos of the Divine Comedy. All of his Master Level contributions and E4M7 come from this series.

A tiny thing, but in heretic/hexen, the first pixel in a span seems to be duplicated most of the time. This is because the span drawer computes the current pixel position in the flat from the UV coordinates, then goes into the unrolled texture mapping loop. This loop draws the pixel using that position, then recomputes that pixel position from the UV, and only then increments the UV coordinates. Interestingly Chocolate Heretic doesn't replicate this bug ATM, it's super minor but maybe worth a bug report?

There's a couple of textures that are derived from Wolf3d, a thing which lasted all the way up to Quake 2 I think. One more subtle example is the set of gray stones in Doom 2, which are traced over the basic gray stones texture from Wolf

I don't think it's related to emulation, given that it's happening in this video. Of course, the guy is using way newer hardware with ethernet connectors and Pentium 4 CPUs, but it's still using IPX connections directly and its running on MS-DOS 6.22. I wouldn't be surprised if it was a Doom bug that wasn't discovered until a later release, after machines with fast enough processors became common enough, but I don't know for sure.

The reason why zombiemen can gib in Calico (and all of the jaguar derived console ports, too) is because their damage was buffed up some, for whatever reason. It's now 3r8 instead of 3r5. Here's Calico's A_PosAttack

regarding enemies shooting projectiles above or under the player, Linguica spent some time analyzing that and determined that the main problem is mostly the inaccurate nature of P_AproxDistance. The approximation will be far enough from the actual distance in some cases that the game gives the projectile either too much or too little velocity on the Z axis.

honestly this is more of a "I haven't done sufficient study" thing more than anything but I'm still not sure what it is in the mess of polar coordinates Doom does for perspective-correct texture mapping in the outer loop of the wall and floor/ceiling renderers. it's a little more clearcut in the prerelease code where everything is way more by the book, but Carmack's polar coordinate stuff for the release game proves more confusing.

Later versions added support for MIDI directly, otherwise you had to use MUS. Any MIDI had to fit the limitations imposed by the MUS format, though. As mentioned Hexen also added CD music.

for whatever it's worth, I need to make a test level to verify this (I wrote a level converter to convert the final level format into the alpha one, but it's a little annoying to get modern level editors to let you overlap sectors without being smart about it) but I think the alpha renderers would have allowed simple room over room. Kinda moot, since thing->thing collisions are in 2D so if there was a thing in the lower room it would block things in the upper room). The limitations otherwise would probably be similar to earlier Build games, like Duke Nukem 3D, where you can't see both the top and bottom of the stack at the same time.

I've finally been going back and cleaning up my Doom 0.5 reverse engineering project, for the sake of integrating the DOS systems code and perhaps also eventually do the same for 0.4. One thing this cleanup entails is reorganizing the source so that the way types are defined more closely matches what the debug information shows, seemingly the Doom source at the time, instead of having one big "doomdef.h" containing every public definition, had a bunch of smaller headers for each namespace. This cleanup is mostly done, but I need to validate that things are matching. But anyways, for the neat-ish things, while working on this I noticed a couple of structure and enum definitions I missed in my first pass. The most interesting is for psprites. In the released Doom game there's only 2 psprite layers, the weapon layer and the muzzle flash layer. But the alpha versions have 11. Only 2 are actually used anyways, but the identities of the other layers are interesting. We knew they had shell casings at some point that ended up unused, but do we really need 9 layers for it? Well, this enum clears up things... typedef enum { ps_smoke, ps_flash, ps_weapon, ps_shell1, ps_shell2, ps_shell3, ps_shell4, ps_gore1, ps_gore2, ps_gore3, ps_gore4, NUMPSPRITES } psprnum_t; Well, the shell casings are there, but now I'm super curious what the smoke and gore layers would entail, and if any sprites were ever made for them. Sadly, I suspect we'll never know for sure, the psprite sources weren't released with Romero's stuff from 2015, and it's been made pretty clear that zenimax wasn't happy with Romero distributing that stuff anyways. May be worth emailing him anyways..

I opened up a bug report for this What's happening is that objects are rendering with the wrong sector's lighting, for some reason.

PU_CACHE will tell Chocolate Doom that it's free to discard that allocation for something else if it runs out of memory. (which can potentially happen even on modern machines with lots of memory since it uses an 16 MB heap by default). PU_STATIC makes it stay in memory until explicitly freed. I think more context is needed to figure out what's going on with the allocations, since I'm not even sure why this would cause problems with C's free function

For some reason, they got stuffed at the end of the episode 2/3 sprite set, no idea why. Maybe they just thought they were going to use them for e4 but ended up not doing so. Somehow the projectiles for Doom 2 monsters also ended up in there

not huge into the artstyle, but wow that remix of the original theme song is doing things for me, I'd love to have a full version of it.

The control screen in Doom 2 on the GBA has this image, which seems to be of a PC source port rather than the actual GBA port. The thing I'm curious about is what port could this be? There's an extra menu item that wouldn't be there usually. It feels like it has that ZDoom yellow tint (though it could just as easily be due to the lower color depth on the GBA, and the weird palette they used) but I don't remember ZDoom ever having a really long option in the menu right above the Quit Game option.

... Well, kinda. It only generates random player commands for player 2 so far, since I wanted to verify that it works before I actually do anything, but amazingly it seems to: Doom 0.4 and 0.5 watch for a block of memory installed at an interrupt vector 0x60 to 0x68, and if it finds it will use that to hold some of the game state, including player commands. If it includes a vector number for network callbacks, it will treat the game as a netgame and run some extra code for synchronization. This driver synchronizes the fake player 2 with player 1 and then generates a random ticcmd, but hypothetically it shouldn't be hard to get this communicating over a network. I don't know if it'll stay synced at all, but I guess there's only one way to find out. My early source code and driver are here. Put it in your alpha 0.4 directory and run "ALPHANET" to start the game. This has only been tested in Dosbox-X and may not work on a real machine. I've also had problems with the alpha constantly crashing, I think due to leaky state between sessions, you may need to restart Dosbox in order to run it again. Otherwise, watch as player 2 zips off into the sunset and then finds some obscure physics bug to vanish until they randomly reappear again. ALPHANET.zip The source code has been compiled with a recently nightly build of OpenWatcom, can't comment on whether or not it'll work in any other version. The player will probably vanish the moment they leave the starting sector since the game doesn't have any code to relink the player. Alpha 0.5 does, so I'll probably adapt this to work with it.

sheer laziness, that's about it. OpenWatcom did the job well enough and it runs in DosBox well enough (as well as the pcem virtual PC I use for further testing)

heh, honestly I'm just fine with the satisfaction of getting this nonsense working in the first place. I got it working with Alpha 0.5, though I had to make some minor patches to the binary to make it work, since some refactoring broke the starting of net games. Sadly I misremembered and things that cross sectors still aren't linked. Also looking at adapting the network code from IPXSETUP, but at some point the novelty of it's wearing off so no idea if I'll get to the actual multiplayer state. Maybe for two players only.

Some of the greebles on the toy were made into wall textures, from what I remember

well, if that's all you're looking at, then there's no way it would be shareware. Indeed, before the game was released, id software was a bit less okay with it. In any case, the later uploads at the idgames archive all mention that they were uploaded with id's blessing, and id software employees/ex-employees have discussed them before, with Romero showing them at his post-mortem and one of the more recent members of the staff sponge discussing them here.

I don't think they can be considered shareware properly, though id software has historically been okay with their distribution. No one's made a source port for the Doom Press Release Beta ever, but it's been reverse engineered multiple times so there's nothing stopping someone from doing so if they had the patience. I did reverse engineer and make a source port of the 0.5 alpha version as a research project a while back, but that's about it ATM. MBF derived ports have their "beta emulation mode", but it's not really that accurate since Killough had to make guesses at certain features since the fancy disassemblers weren't available back then.

In earlier versions, you'd need to make a little mod to do it. You can put this into a decorate lump in a wad: actor NewRocket : Rocket replaces Rocket { +OLDRADIUSDMG } This won't be generalized though so any mod that adds new explosive types won't have that effect.

Yes, it is. The core difference is that Doom uses a planar video mode commonly called mode X, whereas Heretic uses a linear video mode, the stock mode 13h. This change does have a few downsides, like removing the ability to do double buffering in hardware and the low detail mode, but is potentially faster since the drawing code doesn't need to specify what banks it should be writing to. Additionally the multiple software framebuffers scheme that Doom had isn't present at all in Heretic. Functions like I_Update are also considerably different. And now that I'm looking at it closer, the update scheme is a lot different, not using the concept of a "dirty box" like in Doom.

In a current version of GZDoom, you can go to Compatibility options -> Physics options -> Use original Doom explosion behavior. The reason for this is because Doom didn't consider Z-heights when calculating explosion damage, but ZDoom added this later down the line.