nukeykt

Hi, To celebrate 30th anniversary of Raptor, gamesrc-ver-recreation project now covers all known EXE revisions of Raptor. As a reminder, gamesrc-ver-recreation is a project which aims to reconstruct EXEs of various games accurately as possible using their released source codes as a base. Like with Doom engine games EXE restorations, this release does not include proprietary DMX code. This project started in November 2021, when copy of source code of Raptor and parts of surrounding code (GFX library) were received from original developer, Scott Host. Using code we got and copy of DMX code we already had, me and @NY00123 starting piecing them together to get functioning DOS exe. Eventually we managed to compile it, but as expected, there were few differences compared to original v1.2 EXE. With some more effort we found and fixed all the differences, and got EXE that matched original EXE byte-by-byte. Using this, I immediately started reconstructing sources for earlier releases. v1.1 release was reconstructed fairly easily within a day or so. Reconstruction of v1.0 though, proved to be quite difficult, as the DMX version used in this version was much earlier than any version we had (for example, Gravis ultrasound code was completely different, and still was using hardware mixing like Doom 1.3 and earlier did). We weren't able to finish this at the time. Shortly after this we moved to the Doom and Strife source code restoration, and DMX restoration we did for Raptor v1.2, turned out to be useful there. Specifically, we found out that Doom 1.7/1.7a uses exact same DMX revision. Much later though, in September 2023, I was trying to reconstruct Doom 1.2 executable. As it uses DMX version quite close to Raptor 1.0, I decided to look at this again. This time I had much more luck, and thus Raptor v1.0 finally was reconstructed. Shortly after this, branch of v1.2 reconstruction was published on github by skynettx as official GPL release of Raptor source code. Based on this, @NY00123 put together this repository for public release. https://bitbucket.org/gamesrc-ver-recreation/raptor

as suspected by judging from sources timestamp, this is indeed sources for "1.0r2" EXE revision. DMX and DEFS.INC are missing, but matching version of it can be found in the leaked DMX archive (headers from dmx33gs, lib from dmx34a), DEFS.INC can be taken from open-source release (which was confirmed to match to "1.1r2" by @NY00123). Source code itself need very minor modification to match released exe: just commenting out RANGECHECK define in H2DEF.H. Watcom 10.0 and TASM 3.1 should be used as a toolchain. Resulting exe on my side had only 29 differing bytes compared to released EXE, all differences are in garbage data between C string literals.

Played cooperative game with @NY00123 using reconstructed doom v0.99 sources NY00123's video (uses APODMX) my video (uses DMX):

To celebrate upcoming doom's 30th anniversary gamesrc-ver-recreation now covers original shareware v0.99/v1.0 release https://bitbucket.org/gamesrc-ver-recreation/doom

Doom v1.2 restoration WIP https://bitbucket.org/gamesrc-ver-recreation/doom/src/doom12/

Checked Doom II 1.7.sit archive, which appears to have v1.7 source code. And indeed after compiling it with right DMX version, I got exe that matches original v1.7 EXE byte-by-byte. @NY00123 a while back figured out that v1.7 and v1.7a have only one difference: startup screen version number. https://bitbucket.org/gamesrc-ver-recreation/doom/src/0e7f5b2cfa495f6675abdad7a3780107603f4fbc/d_main.c#lines-990 So I tried to correct header by appending "a" and recompile, and sure enough, I got exe that matches v1.7a byte-by-byte.

can confirm that DOS doom sources are legit. DMX (dmx37lib), makefile/newdoom.lnk, DEFS.INC are missing but can be grabbed from elsewhere, e.g. gamesrc-ver-recreation. Using watcom 9.5b and then removing debug data and appending dos4gw I got exes that are identical to original ones, byte-by-byte.

Bumping a thread with some news. Recently I started reverse engineering of the Doom 95 exe. Wanted to do this for a long time actually, mostly because it is directly derived from the DOS doom code and its exe was build using the Watcom compiler(same compiler used to build DOS Doom) and it included debug symbols(!!!). Now when we have perfect DOS doom sources recreation, it can be used as basis for this effort. Reverse engineering process is pretty starightforward: compile dos doom C modules with the right compiler settings and compare to the doom 95 code disassembly, then modify C code until compiled code matches byte by byte (or at least by behaviour). And of course windows/directx related code needs to be written purely based on disassembly. Today I finished first pass of reverse engineering and finally built exe. With some more bugfixing it is mostly working now.

You probably can check gamesrc-ver-recreation's doom repository to see how things worked in original DOS version(s): https://bitbucket.org/gamesrc-ver-recreation/doom

DMX adds end of track event at the memory chunk end for single track midi formats and thus overwrites some of doom's heap data. You can either convert midi file to multitrack MIDI (format 1) or just add 3 extra bytes at the end of file in any hex editor.

Doom's OPL patches (well, actually Scott Host's patches) were in fact derived from stock OPL patches, that, for example, was used in Windows 3 adlib/sb drivers. While majority of patches were heavily edited/made from scratch there are still few patches that didn't change much or remained unchanged. I recorded few Doom midi files with both Doom and Windows 3 patches if you want to compare. Especially D_BUNNY and D_E2M7 are good examples. https://drive.google.com/drive/folders/1YgoFaf4lsssJlZqgKH54sgmpqumbJFTU?usp=sharing

Update to the Strife restoration A couple more revisions of the Strife executable are covered now: registered v1.1(aka v1.0) and registered v1.2. Both reconstructed EXEs are identical to the original EXE files (up to garbage data between string literals and differences due to the __LINE__ macro). Thus gamesrc-ver-recreation now covers all known registered versions of Strife. The next obvious step is to try to cover the demo versions of the Strife, but I expect much more differences because both demo versions use much earlier revisions of the executable, so I guess I'll leave this for later.

I don't recall changing any setting in my config file. DM me in discord, you can find me in chocolate doom server

I used vanilla dosbox 0.74-3 myself. Maybe you need reset disk cache in dosbox? (ctrl+f4) EDIT: btw, which revision of Doom you're building?

relative to DOBUILD.BAT. In my setup I have 2 folders: one for watcom and one for doom. In watcom folder I have 9.5b + TASM.EXE in BINW folder. In doom folder I have 2 folders: doom tree and dmx. Watcom is mounted on C drive and Doom on D drive. Thus DOBUILD.BAT is located at D:\DOOM\DOBUILD.BAT, dmx_r.lib is at D:\DMX\DMX37\LIB\DMX_R.LIB