Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

SaladBadger

Members
  • Content count

    1474
  • Joined

  • Last visited

About SaladBadger

  • Rank
    Senior Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. SaladBadger

    Doom 0.5 reverse engineering project

    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.
  2. SaladBadger

    Doom 0.5 reverse engineering project

    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.
  3. SaladBadger

    Doom 0.5 reverse engineering project

    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.
  4. SaladBadger

    Is this Mac/PC Doom source code on ebay legit?

    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.
  5. SaladBadger

    Is this Mac/PC Doom source code on ebay legit?

    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.
  6. SaladBadger

    Is this Mac/PC Doom source code on ebay legit?

    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.
  7. SaladBadger

    Is this Mac/PC Doom source code on ebay legit?

    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.
  8. 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.
  9. SaladBadger

    Things about Doom you just found out

    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)
  10. 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.
  11. SaladBadger

    idbsp not working

    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
  12. SaladBadger

    Things about Doom you just found out

    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.
  13. SaladBadger

    Things about Doom you just found out

    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?
  14. SaladBadger

    Things about Doom you just found out

    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
  15. 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.
×