SaladBadger

modern CPUs still heavily use cachelines that favor a column major transform like this, when drawing vertical columns. at 320x200 on a modern CPU it doesn't matter much, but Gooberman, in an effort to make the Doom renderer run way faster at high resolutions, has determined that making the framebuffer column-major always significantly increased the speed, since rendering of walls and things (floors/ceilings cause a bit of trouble there, though) is done vertically.

Seemingly it's "fast water" and "splashing water", the SWATER flats are in the press release beta, but they're also in Romero's art dump:

If anyone's interested, I threw together a quality of life release by rolling in my patches from InjectD3 and adding some new ones. Plays nicely in multiplayer and I've been running the campaign for a while and it seems fine. It's available here. It's still a little rough around the edges, I feel, but hey if you want your Descent 3 fix in ultrawide with expanded fov, I've got you

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.

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)