SaladBadger

Ah, I was hoping to have all the code commited to the repo by now, but I noticed there's a bunch of functions that slipped through my fingers with regards to clean up, so I'm busy finishing that up. I did commit some of it though. As a cop out, I decided to see if I could make the demos play in sync correctly, and I seem to have managed it. here's a video.

https://github.com/InsanityBringer/Doom05RE I've finally gotten my Doom 0.5 RE project to a point where it's basically feature complete, so I've created a repo for it. The port I've developed is extremely barebones, and mostly exists just to verify that things are functional, but it does the job. I dunno what else to do with this. My main intentions are to write an article similar to Fabien's article on how the BSP based Doom renderer works, and try to delve deep into why the original recursive algorithm was so slow. Additionally, I'd like to also possibly port it on top of Chocolate Doom's gameplay code and see if it would be possible to make it work with features like Build-like moving sectors. In practice, any serious port would be better off adopting Eternity like portals and clever use of portals and polyobjects for complicated moving things, but it might be neat to see what was originally possible. Beyond that, there's not much of interest in an engine derived from alpha-quality game code, beyond being a time capsule of what Doom's code was once like.

indeed, from what little I understand of the Build architecture it's fairly similar. find visible portals, recurse into them keeping a list of subsectors that it wants to check out, using clipping to restrain them to the bounds of that portal. It's pretty cool that the limits of the rendering code allow for perfect clipping during the recursion, but it's also not hard to see why a new algorithm for iterating sectors was desired. Build had way more time to beat at it to make it perform well.

Honestly, I should have done this the moment I started this project all the way back in 2020, but I've finally decided to go back and do two things to the code. The first is code cleanup, I realized that since the code was compiled without any optimizations and full debugging information, I can get something very close to the exact statements that would have been on Carmack's monitor 30 years ago, you can basically see it in the assembly. This means I finally have an accurate version of MergeSort, rather than some barely functioning monstrosity cobbled together from ghidra beating at 3 different versions of it, and all local variable names are accurate. A lot of this has been committed to the github, but I've been dragging my feet on the rest of it.. Secondly, I've finally brought the code back to DOS. It's functioning, and about 99% complete. I mostly need to get two routines back to assembly (the high color span drawer, which is unused since the high color column drawer is bugged in the 5/22 alpha and goes into an infinite loop, and the assembly version of IO_BlitBlocks which since it is unrolled I want to set up a macro for). Other than that all the DOS specific code has been reconstructed. The build environment is currently using Open Watcom since I've been too lazy to find the version originally used, and TASM 3.1 since Open Watcom's assembler is basically unusable for me. The dos4gw stub program is also compiled using the 16-bit compiler, but it seems like the one the alphas actually used was compiled with Borland C. I would like to try to get a perfect executable like with the gamesrc recreations, but I dunno if I will. It's a lot of work for a half finished prerelease version of a game, and it would involve poking at DMX a lot. The version of DMX included in Alpha 0.5 is very different than any other version of DMX seen, and isn't represented anywhere within the leaked DMX sources. This version doesn't contain any device-specific code in the library itself, instead it defined a driver interface where a real mode driver would perform the device specific functions and communicate with the DMX library in the protected mode library with a block of memory registered in a real mode interrupt vector... so pointless exposition aside, the only way I could get an accurate executable would be to somehow extract those functions out of the executable and stuff them back into a static library (I've seen it done before), or reverse engineer all of that version of DMX and recompile it. Even though I can't test it without any of these driver programs which were never released or leaked.

Honestly I wonder if there's any evidence of that. The particular message didn't exist in any of the alphas except for the press release beta, I think, and every alpha was running in protected mode. It is still a really weird thing to have an error message for, though, and I can potentially understand thinking it would be to ensure any texture can fit in a EMS page.

What I find weird is that I remember Wolfenstein had a screen that looked like the DOOMERR screen in Alpha 0.4/5. So they must have had a few different iterations of it. no idea why they even bothered updating the screen when every extant version of Doom used protected mode where most of this doesn't matter, but they did.

Are there any recommended programs for opening the HFS-formatted ISO? I was kinda hoping 7-zip could do it, but it seems to be unable to. edit: why didn't I just try a few google queries it seems that "HFS Explorer" works just fine.

This screenshot does seem to correspond to the files listing that was included in the original source release, showing the state of the directory before Bernd worked on it. -rw-r--r-- 1 b1 prog 0 Jan 18 15:08 FILES -rw-r--r-- 1 b1 prog 5799 Jan 18 15:07 Makefile -rw-r--r-- 1 b1 prog 1943 Jan 18 15:07 am_data.h -rw-r--r-- 1 b1 prog 20263 Jan 18 15:07 am_map.c -rw-r--r-- 1 b1 prog 2494 Jan 18 15:07 am_map.h -rw-r--r-- 1 b1 prog 1499 Jan 18 15:07 am_oids.c -rw-r--r-- 1 b1 prog 338 Jan 18 15:07 am_oids.h -rw-r--r-- 1 b1 prog 14005 Jan 18 15:07 d_french.h -rw-r--r-- 1 b1 prog 25287 Jan 18 15:07 d_main.c -rw-r--r-- 1 b1 prog 15586 Jan 18 15:07 d_net.c -rw-r--r-- 1 b1 prog 744 Jan 18 15:07 defs.inc -rw-r--r-- 1 b1 prog 3569 Jan 18 15:07 dither.c -rw-r--r-- 1 b1 prog 355 Jan 18 15:07 dither.h -rw-r--r-- 1 b1 prog 4234 Jan 18 15:07 doomdata.h -rw-r--r-- 1 b1 prog 32779 Jan 18 15:07 doomdef.h -rw-r--r-- 1 b1 prog 192 Jan 18 15:07 drcoord.h -rw-r--r-- 1 b1 prog 22377 Jan 18 15:07 dstrings.h -rw-r--r-- 1 b1 prog 6582 Jan 18 15:07 dutils.c -rw-r--r-- 1 b1 prog 1821 Jan 18 15:07 dutils.h -rw-r--r-- 1 b1 prog 14072 Jan 18 15:07 f_finale.c -rw-r--r-- 1 b1 prog 7357 Jan 18 15:07 fpfunc.S -rw-r--r-- 1 b1 prog 34770 Jan 18 15:07 g_game.c -rw-r--r-- 1 b1 prog 5394 Jan 18 15:07 hu_lib.c -rw-r--r-- 1 b1 prog 2878 Jan 18 15:07 hu_lib.h -rw-r--r-- 1 b1 prog 12040 Jan 18 15:07 hu_stuff.c -rw-r--r-- 1 b1 prog 934 Jan 18 15:07 hu_stuff.h -rw-r--r-- 1 b1 prog 6238 Jan 18 15:07 i_cyber.c -rw-r--r-- 1 b1 prog 18324 Jan 18 15:07 i_dga.c -rw-r--r-- 1 b1 prog 2499 Jan 18 15:07 i_header.h -rw-r--r-- 1 b1 prog 32815 Jan 18 15:07 i_ibm.c -rw-r--r-- 1 b1 prog 1867 Jan 18 15:07 i_ibm_a.asm -rw-r--r-- 1 b1 prog 121 Jan 18 15:07 i_main.c The filesizes are different, but it seems like the mac is showing it in terms of filesystem blocks rather than how many bytes are actually being used by the file's data? Someone with more classic Mac OS experience would have to chime in there.

This appears to only fix the tutti-frutti generated by tiling textures that aren't 128 units tall, using something similar to what I mentioned (though by replacing R_DrawColumn entirely with a much more optimized version that Lee Killough wrote). Though Crispy may have another solution for the using a masked texture on a 1S wall case. It uses an & for textures that are powers of two, but avoids using a modulo for textures that aren't, since doing that divide would probably have been slower.

https://doomwiki.org/wiki/File:Doom-development-1994.jpg We have this ancient, low resolution, crusty as all hell image which shows an early version of Doom being ran on NeXT. The version of Doom being run resembles a post-Press Release Beta development version. As the description on the wiki states, it is showing early Doom source code and the game does seem to be running in gdb, so it seems likely that it's been running on both platforms. I don't get anything here.. Doom isn't particularly optimized for bitplanes in general. The framebuffer code (though mostly bypassed by the 3D renderer in the released version of Doom) works with linear framebuffers that need to be munged on transport, and the image format used by the release game, compared to that of the alphas, doesn't have any particular optimizations for chunky graphics. Maybe it was once true? The framebuffer was generally munged in the alpha releases, as I can see from my reverse engineering efforts, but the function IO_BlitBlocks could unmunge it on the NeXT. (worth noting that the press release beta did run in linear mode 13h, compared to the final game which runs in mode x, similar to how heretic and hexen would eventually work)

There's two types of tutti-frutti really. The kind that appears when you use a texture with transparent bits on a 1S wall or on the upper or lower textures should in theory be fixable by filling the cache with a known color value before drawing the data onto it by R_DrawColumnInCache. The other is caused by vertically tiling textures less than 128 pixels tall. R_DrawColumn is hardcoded to wrap at intervals of 128 pixels. This would require presumably a new global to store the texture height and replace the fast &127 with a generic modulo by that height.

idbsp isn't a 100% straight port of doombsp, for whatever reason the author added a feature where you have to put a map label in the DWD file that wasn't there originally. From the docs

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