SaladBadger

I got news of the source dropping around 12:30 AM. by 2 AM I had it building by substituting the missing source from the editor, and went to bed. Now that I'm awake again, I'm starting to roll in my improvements I made for InjectD3, including good windowed mode (the 1.5 source had windowed mode hacked in, but it wasn't particularly usable).

Not much to show, but I'm glad this is finally happening.

weird obscure engine thing, but I just realized pain states are one tic shorter if induced by a player's hitscan weapons. player specific thinking including their weapons is done before any thinkers are run, so hitscan weapons in particular do damage before anything else can run. once it finally gets to the thinker of the thing you shot, it sees that the tic counter is not 0 and decrements it, eating one of the tics that would have been dedicated to pain. This is similar to why flash states need to be defined with a duration one tic longer than the state calling A_GunFlash to remain in sync.

Other attacks, like monster hitscan and melee, or projectiles would depend on the order of thinkers in the list, but projectiles will usually be newly created at the end of the list, and therefore the monster will have done a tic before the projectile is processed as hitting them. A quick dehacked patch seems to confirm this, giving imps a 1 frame pain sequence. If you shoot them with the pistol, they won't visibly twitch at all in pain, but if you shoot them with a plasma ball, then they will very briefly twitch.

By default, gzdoom stuffs configurations and saves in your user dir/Documents/My Games/GZDoom now. If you upgraded and had an old configuration in the dir, it would have let you create a portable configuration like the older versions. Otherwise, if you want the old behavior back you can drop a blank gzdoom_portable.ini into your gzdoom directory (though you'll probably want to copy out your ini from that dir to keep settings)

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.

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.

6 hours ago, Shepardus said:

Here is what Crispy Doom does (sourced from MBF); perhaps someone else can explain it.

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

Quote

    1) A "level:E?M?" (where ? is the episode and level) directive marks the
         beginning of each map level.  Multiple levels can be included in a single
         DWD file.

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?

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.

1 hour ago, DannyMan said:

Did the engine support audio formats more than just MIDI officially?

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.