Restoration of a few games' EXEs versions

[NY00123]

Hey there,

While I don't have a lot of new actual contents to report about, there's still what to write.

1. To begin with, anybody who's been messing with the modified Wolf3D codebase from my repository should probably read this point. Not long ago, I've found out that Borland C++ effectively truncates too long identifiers behind-the-scenes. There's an "Identifier Length" option which tells the max. identifier length, and has to fall in the range 1-32 (at least under Borland C++ 3.0).

So it's been a good chance for me to not just shorten identifier names, but also do some other changes. A significant one is the usage of a new GAMEVER_WOLFREV macro for covering different ranges of Wolf3D codebase revisions.

Also, the project file names have been renamed. In particular, note these renames: WL1APO12.PRJ -> WL1AP11.PRJ, SODFOR14.PRJ -> SODFG14B.PRJ. There is indeed a new "SODFG14A.PRJ" project, see below.

Finally, VERSION.H and VERSION.EQU now internally used "EXEDEF" macros that match the corresponding project files. These macros are *never* directly used in any other source file (on purpose). GAMEVER_WOLFREV should be used for this, combined with macros like UPLOAD and GOODTIMES, as well as the new GAMEVER_NOAH3D macro.

2. I've added a project file for another EXE, named SODFG14A.PRJ. This is the "v1.4" release mistakenly labelled as "V1.0" in-game, which was apparently released on 1992-11-12, according to Litude. To compare, SODFG14B.PRJ (previously named SODFOR14.PRJ) is assumed to be released on 1993-01-12.

In terms of actual code found in the C and ASM sources, SODFG14A.PRJ and SODFG14B.PRJ are exactly the same. Furthermore, both EXEs were originally built using Borland C++ 3.1. However, in other ways, SODFG10.PRJ is more similar to SODFG14A.PRJ. This includes differences like the order in which objects get linked, as well as the "V1.0" sign-on screen. In fact, ignoring my addition of the "EXEDEF" macros, the exact same project file can theoretically be used for SODFG10 and SODFG14A altogether, with a bit different VERSION.H/EQU definitions.

3. For some weird unknown reason, the instructions for building SODFG10.EXE (previously SODFOR10.EXE) have changed a bit. After building the EXE, you now have to remove WL_PLAY.OBJ, re-open the project with Borland C++ 3.0 and then again press on F9 to build the removed code. Only then, LZEXE91 may be used. I really don't know why this is the case, especially since it's not required in an earlier revision of the codebase (I've verified this). It might be related to source file(s) layouts and/or the way a table of definitions internally used by the compiler is structured.

4. I've also updated the notes regarding the compression of the Activision EXEs. To summarize, you can use LZEXE 0.91e, rather than 0.91, to faithfully recreate the EXEs from 1998. These two versions of LZEXE seem to differ, a little bit, by the contents of the decompressor stub as embedded in the packed EXEs (0.91e appears to add a "push ax" and a later "pop ax", if there's no other change). Since UNLZEXE8 checks the first 232 bytes of the decompressor stub, this should explain why it fails to unpack any of the Activision EXEs, while UNLZEXE7 can do so. Of course, if any of you attempts to hide that "LZ91" string (found in the first 32 bytes of the EXE), then UNLZEXE7 will fail, too.

I'll also add a few bonus points here:

5. So now, I don't exactly have the means to build this as-is, but let's continue anyway. The file http://www.freewebs.com/choksta/wolflist.txt lists a "WOLF3D_J.EXE" executable, which comes from a Japanese localization of the game made for DOS/V (not to be confused with the PC-98 port i.e., WOLF98.EXE). It is reportedly 254046 bytes long. Well, it turns out, that when you modify WL6GT14A so the JAPAN macro is defined instead of GOODTIMES, Borland C++ 3.1 outputs an EXE with the exact same size. Again, though, I cannot confirm it's the exact same EXE. In fact, I'm quite sure it isn't, given the presence of the (wrong) GT sign-on screen, heh.

6. One may be wondering if WOLF3D.EXE, as originally bundled on 1995 along with the Wolfenstein 3D sources, can be re-created? In fact, maybe it can simply be built from the sources as released back then? Well, it turns out the answer is "yes", under a few conditions. First, you should use Borland C++ 3.0. Secondly, make sure all files have their original modification dates, not older than 1995. Otherwise, expect to get a few minor differences between the 1995 EXE build and your build.

Can the same be done from my repository? Well, if we ignore differences in debugging symbols, then again the answer is "yes". Basically, you should begin from (a copy of) WL6AC14.PRJ, then replace the Activision SIGNON.OBJ with the GT one, select "On" for "Source Debugging" in Borland C++ 3.0 (under Debugger Options) and finally make sure that GAMEVER_WOLFREV is the same as for WL6GT14B. You may wish to modify the output directory to something other than OBJ\WL6AC14, and possibly also update the Include and Library directories (so files from BC30 are used instead of BC31). Watch out, though, in case you also want to replace the GAMEVER_EXEDEF_WL6AC14 macro. Reason is, not only you should edit it under "Compiler -> Code Generation", but it also has to be manually changed for a few ASM sources (under params passed to the assembler).

[MrFlibble]

Sorry for a bit of off-topic here. I just played The Catacomb Abyss shareware with your Reflection Keen port, and I must say you're doing an excellent job. What I particularly liked is:

• correct aspect ratio (it shouldn't be surprising but not all ports of DOS games do that, sadly)
• switching between windowed and fullscreen mode
• optional bilinear filtering

Generally I like your idea of taking inspiration from Chocolate Doom. In my opinion, Wolf3D engine games lack their own "Chocolate/Crispy" ports pretty badly. Any chance you could do something similar for Wolfenstein 3-D if you have the time? Rise of the Triad also is pretty lacking in the source port department (apparently none of the available software mode ports properly deal with aspect correction), and also there's the code of In Pursuit of Greed no one has done anything with so far AFAIK.

[NY00123]

Hey there,

Thanks for your comments on Reflection Keen / Reflection Catacomb Abyss, as well as trying it out!

Generally I like your idea of taking inspiration from Chocolate Doom.

As I said beforehand, there are still enough ways in which it isn't exactly like Chocolate Doom (e.g., some efforts are required in order to emulate certain bugs, but then again this can also be a difficulty in Chocolate Doom). Nevertheless, yeah, I try to not modify original behaviors unless there's a really good reason (e.g., a crash or a hang).

In my opinion, Wolf3D engine games lack their own "Chocolate/Crispy" ports pretty badly. Any chance you could do something similar for Wolfenstein 3-D if you have the time? Rise of the Triad also is pretty lacking in the source port department (apparently none of the available software mode ports properly deal with aspect correction), and also there's the code of In Pursuit of Greed no one has done anything with so far AFAIK.

This is surely a great idea, and I can understand the sentiment. I can't really say (i.e., promise) if I'll get something done with any of the above atm, though. Also, In Pursuit of Greed looks like a really obscure game. I did get to play it, and it may be (somewhat) OK for deathmatches, but unfortunately it looks like the single player part isn't really favored (across the few players who've recently tried it). I also recall encountering a few crashes, here and there (well, maybe in the very few deathmatches I weirdly initiated about 2 year ago).

Oh yeah, this may be a bit of a surprise for the readers, but yeah: Again 2 years ago, I did get to complete the whole IPoG campaign! Truly, these respawning creatures made it difficult, but luckily there was some glitch which generally made it possible to use some kind of a rocket inventory indefinitely (i.e., its supply never really ran out).

Also, about reproducing original bugs in games, it's important to get feedback from other users who know to spot differences. This might be doable with Wolfenstein 3D, and *maybe* also ROTT, but I don't really see it happening with IPoG or even the supported Catacombs games. The availability of demo playback and/or game mods (for the original DOS versions) also has a great impact on this.

[MrFlibble]

Also, about reproducing original bugs in games, it's important to get feedback from other users who know to spot differences. This might be doable with Wolfenstein 3D, and *maybe* also ROTT, but I don't really see it happening with IPoG or even the supported Catacombs games. The availability of demo playback and/or game mods (for the original DOS versions) also has a great impact on this.

Personally I don't feel that the recreation of bugs is a top priority (in fact I would prefer this to be optional, similar to compatibility modes and options in Boom derivative ports). A functional port of Wolf3D which properly corrects the aspect ratio similar to BStone (and maybe with an option to disable the wall thumping FM sound) would be nice. AFAIK there is no way to force the correct aspect ratio in Wolf4SDL (which appears to be otherwise an accurate port), although I've read somewhere that Blzut3 made a custom patch, and ECWolf isn't exactly a very conservative port either. Same goes for ROTT where there is simply no software mode port to properly address the aspect ratio issue.

I've only completed the first episode of In Pursuit of Greed, and played a bit the other two episodes. The problem is that the enemies are generally pretty weak, and the challenge comes more from the randomly spawned pickups. Also, there seems to be a lot of Hexen style switch hunt in level design, sometimes excessively so. I think I did like the early v2.0 demo better as it certainly is more challenging in terms of enemies.

[NY00123]

OK, I want to correct a few mistakes of mine. Afterwards, I'll ask about the new macros used in the sources recreation repository.

1. First, about Blake Stone: Aliens of Gold, I mistakenly mentioned in DHW and RGB that demo no. 3 is the first to be played in version 3.00. In fact, this is the case only in the registered version. The LastDemo variable is still initialized to 3 in shareware v3.0, but the actual demo number is calculated mod 3.
2. Secondly, about the projects SODFG14A.PRJ and SODFG14B.PRJ, I mistakenly hinted that there are differences between term, in the orders objects get linked. This is incorrect. In fact, these two projects are almost identical (and hence are both similar to SODFG10.PRJ, ignoring Borland C++ version originally used). Basically, the only real difference (other than SIGNON.OBJ) is that Source Debugging is toggled "On" in SODFG14A.PRJ and "Off" in SODFG14B.PRJ.

Now, I'm wondering if my choice of new macros (like GAMEVER_WOLFREV) is not favored by some of you? Maybe there's a better approach?

I'll say that I still want these points to apply:
- Macros shouldn't be as long as they used to be (or else the compiler may trim some of them).
- There should be one EXEDEF macro per EXE, mentioned *only* in VERSION.H and VERSION.EQU. I basically think it's (somewhat) better in terms of maintenance. It's also a good way to clarify that shareware v1.1 isn't of the the same revision as registered v1.1.

The thing is, maybe I should've used names like "GAMEVER_WOLF3D_PREREG" for shareware versions 1.0 and 1.1. But then, GAMEVER_WOLFREV can be used to (roughly) describe a range of code revisions, and not necessarily specific game versions.

There's also the special case of GAMEVER_WOLFREV being compared to 19921007L in ID_PM.C. (Yeah, I could use 19921008L, but I tried to be consistent, so I always used "<=" in comparisions, rather than ">"; Admittedly a bit of an imperfect situation.)

[NY00123]

Think it's time for another update. Let's begin with a few initial notes:

- It turned out the Blake Stone codebase had a silly typo specific to AOG. In the AOG versions of the enemy_t enum, en_goldmorphshot was mistakenly defined instead of en_arc_barrier. It was also used instead of en_arc_barrier in AOG-specific code pieces, but luckily it didn't occur that much.
Interestingly, the EXEs *still* built as expected! Thanks to Aryan_Wolf3D for reporting this.

- Following some feedback, I've changed some stuff with the Wolfenstein 3D game versions *yet again*. Basically, instead of comparing GAMEVER_WOLFREV to mere numbers, helper macros are used, prefixed with GV_WR (e.g., GV_WR_WL1AP10). Note that there's still an exception to this rule in ID_PM.C (with the AJR bug-fix).
Sorry if this has caused more mess for anybody, but hopefully it won't happen that much start.

Now, hopefully these points will be more interesting:

- I suppose at least a few users have wondered about this, especially after an earlier reference of mine in DHW. Thanks to some assistance, you can now recreate the DOS EXE from the Wolfenstein 3D 6-episodes Japanese version!
As expected, there wasn't really much code to add, since it's already found under the "JAPAN" ifdefs. I did used that old recreated FOREIGN\JAPAN\GFXV_WJ6.H file I previously referred to.
It was almost there, *really*. Only the value of CONTROLS_LUMP_END had to be corrected. Other than these points, and the different sign-on screen, WJ6IM14.PRJ is essentially the same as WL4GT14.PRJ, just with JAPAN defined instead of GOODTIMES.

- Next, there's basically a bonus. Usually, I wouldn't cover such game's versions, since they're generally not intended for public usage. However, he following version of Wolfenstein 3D apparently started to get widely accessible even in 1992, and may even be considered another "semi legitimate" shareware release (although I won't link to it here).
That's right, I'm talking about recreating the EXE from that Wolfenstein 3D March 1992 alpha/beta build! Recreated code is now in my repository. One surprise to mention is the various occasions in which S3DNA and the alpha are grouped together. There are also a few cases in which S3DNA and v1.0 (and possibly also the alpha) are grouped, but don't recall that many of these. Also, there's a somewhat(?) interesting name for some unused variable in WL_TEXT.C (present in the alpha only); Leaving for you too see it, heh.
In addition, there's this empty stub, which I originally added to ID_VH.C under the name of VW_NullStub, while recreating v1.0. Turns out, it was (almost surely) named VW_SetDefaultColors. Reason is that is called from MM_ShowMemory in Catacomb 3-D, and the code is almost the same in that Wolf3D March 92 build. Furthermore, except for VW_SetDefaultColors, this implementation of MM_ShowMemory is also present in Keen Dreams, albeit access to it from KD_MAIN.C was originally disabled in the sources (using FRILLS). There are also other cases in which some alpha code is similar to Keen Dreams and/or Catacomb 3-D code piece.

- Finally, I've added a new "HOWTO.md" file, partially describing some points about the process of recreating EXEs built with Borland C++ 2.0/3.0/3.1.

LATE POST EDIT (June 7 2017): Looks like I've forgotten to mention one more thing. Did you know that I originally started this codebase as a git repository hosted by GitHub? Well, this is what happened, basically hosting the Catacomb Abyss sources, modified to recreate CATABYSS.EXE from shareware version 1.13 (QA [0]). Just a week later, though, I moved to a Mercurial repository hosted by BitBucket, and added a few Wolf3D and SOD versions (Wolf3D shareware v1.4, SOD demo v1.0 and the Activision versions).
I did get rid of the original git repository as originally hosted on GitHub. Luckily, though, I've still had a local copy of this repository. It is now up on BitBucket in the following link (note it's still a git repository, *not* a Mercurial one): https://bitbucket.org/NY00123/game-srcc ... it-legacy/

[MrFlibble]

- Next, there's basically a bonus. Usually, I wouldn't cover such game's versions, since they're generally not intended for public usage. However, he following version of Wolfenstein 3D apparently started to get widely accessible even in 1992, and may even be considered another "semi legitimate" shareware release (although I won't link to it here).
That's right, I'm talking about recreating the EXE from that Wolfenstein 3D March 1992 alpha/beta build! Recreated code is now in my repository.

Does this mean that you can produce a recreation of the original alpha executable without all that "keeper of the alpha" nonsense hacked into it? Or was the replaced text in the data files, not in the EXE?

[NY00123]

Does this mean that you can produce a recreation of the original alpha executable without all that "keeper of the alpha" nonsense hacked into it? Or was the replaced text in the data files, not in the EXE?

I don't recall encountering anything to do with the BBS or other such non-original text, so I conclude it's only the data which was changed.

What is confusing, though, is there are currently (at least) two "distributions" of the data, which are (somewhat?) commonly scattered around:
1. In one of them, VSWAP.WL1 is dated March 11 (apparently ~1 hour before the beginning of March 12); The VGAGRAPH, MAPTEMP and AUDIOT related files are all dated March 12, and so is WOLF1V.EXE. There's an additional "TEXT" file from March 26 mentioning some BBS, and the rest of the files (new or edited) are all dated April 18.
2. There's a later distribution, with all files dated "April 17 2003", except for README.TXT which is dated "April 22". The included CONFIG.WL1 files differ, as there seem to be differences in the high scores entries. HELPART.WL1 has some additional pages of text, and a couple of lines at the end of it (with a mention of Gramcracker) are gone. The file "TEXT" is also gone, with its contents moving to somewhere within README.TXT. There are additional 9 saved games. VGAGRAPH.WL1 differs (details below). WOLF1V.EXE differs as well, having 5 extra bytes appended to its very end, with the text "MsDos".

As for VGAGRAPH.WL1: It turns out that in the alpha, this file has a few 16x16 tiles of the same kind used in Keen 4-6 (and Dreams), just VGAed.

There are also two variants of these again: Unmasked, and masked. The unmasked ones appear to be used in the overhead map (F10+O in the alpha or Tab+O in v1.0). There's also similar code in Catacomb 3-D.

Both sets of tiles were apparently intended for use in TED5. However, one of the masked tiles (probably the SS pointing west, spawning on every difficulty) was mistakenly relocated to offset 0, while there's corrupted data in the tile's correct/expected offset. So maybe the mappers still used EGA graphics with TED5, as hinted by the way TED5 was offered for ROTT map editing.

Comparing again the above two distributions of the alpha: It looks like minor edits were applied to a few 16x16 tiles, unmasked and masked, in the later distribution.

WDC can reportedly be used to view the contents of VGA*GRAPH.WL1, including the tiles. I've also modified ModId (an xGAGRAPH importer+exporter based on (l)modkeen), so it can be used to import and export such tiles.

[NY00123]

Time for something new(er), although I guess my announcement has been postponed by 3.5-4 months!

OK, I shall first say the following is *not* an example of perfect recreation - There are still a few unresolved differences. However, I have a feeling it's sufficiently close to be mentioned.

That's right, we're entering Watcom C / 32-bit territory, with Rise of the Triad!

To be specific, the releases currently covered are the Shareware, Commercial/Registered, Super CD and Site License Apogee v1.3.
Note that most of the code changes were not to ROTT itself, but rather to the audio library, named Apogee Sound System (i.e., ASS) and also known as AUDIOLIB (based on a directory name).
The guessed version of ASS in question is 1.04.

Watcom C 10.0b, as well as Turbo Assembler v3.1 (the one from Borland C++ 3.1), shall be used.

Note that the builds you'll get do *not* include the built-in DOS4GW loader from the original EXEs. Furthermore, as already mentioned above, there are still differences in the outputs.
For more details, check out the "audiolib" and "rott" directories in my repo. In addition, something in the "misc" directory may assist for comparing IDA's LST outputs of LE files.

[MrFlibble]

Nice!!!

Have you found anything interesting in the ROTT code?

[NY00123]

Nice!!!

Thanks for your interest!

Have you found anything interesting in the ROTT code?

As stated earlier, most of the changes were done in the audiolib dir.

Beginning from the rott dir, the current changes can, more-or-less, be found, by looking for occurrences of APPVER_ROTTREV. It basically goes like this:
- A few different constants (_RT_ACTO.H, _Z_ZONE.H).
- Misc. code pieces marked with "MED", as released by 3DR. There are also a few additional lines in RT_ACTOR.C, commented out for v1.3.
- Version string printed from DrawRottTitle shall be "1.3", rather than "1.DFISH".
- In RT_SOUND.C, MUSIC_GetPosition and MUSIC_SetPosition are defined as macros for MUSIC functions with different names in v1.3, rather than being wrappers around these functions. Reason is, different functions' signatures.
- Finally, my few attempts to re-order global variables' occurrences in the EXE layout (RT_ACTOR.C, RT_FLOOR.C, RT_MAIN.C).

There were a few difficulties regarding the latter (*might* be partially to audiolib or any other reason). This is currently mentioned at the end of rott/notes-restoration.md.

As for audiolib, I don't think I'll list all the changes. Again, known issues are mentioned in audiolib/notes-restoration.md. I'll write, though, that ASS v1.04 has PC Speaker and AdLib sound effects support. This is accomplished by including PCFX.C and ADLIBFX.C in the code. Note that these files were released by 3DR (as a part of ASS v1.12), although they're unused.

On a related sub-note, does any of the types PCFX.H:PCSound and ADLIBFX.H:ALSound look familiar to you?

If not, compare to the types PCSound and AdLibSound from ID_SD.H (Keen Dreams, Catacomb 3-D, Wolfenstein 3D).

[MrFlibble]

Thanks for your interest!

Rise of the Triad is one of my favourite games, so that goes without saying

[NY00123]

Time for an update.

I shall first mention that, while not yet perfect, I've added two more (late) versions of ROTT. These are the Lasersoft Deluxe Edition ones, from May and July of 1995. As it turns out, the July release is the same as shareware Apogee v1.3, just with the "DELUXE" macro defined to 1. The May release has just a few differences from the July one.

Secondly, there's the following somewhat bigger update. Note that I consider this code recreation *partial*, hence you'll find it in a "bonus" subdirectory. In particular:
- This covers game code only.
- This does *not* cover engine code, audio library code* or closed-source libraries. Original binary OBJ and LIB files are used for these.

To summarize, I'm talking about the game code (and no other code piece) of Duke Nukem 3D!

Now, here's the thing. The Duke Nukem 3D sources as released by 3D Realms on 2003 are of a revision somewhere in-between versions 1.4 and 1.5. However, Hendricks266 gave me the (very great) hint of looking into the Enhanced Duke (i.e., EDuke) 2.0 sources, released by Matt Saettler later that same year. The assumption was that they should have all of the 1.5 code with very few differences, provided that macros like NAM, WW2 and EDUKE are *not* defined.

As it turned out, he was right. In fact, it's not just about the code, but also the make file. Matt's MAKEFILE as originally released must be much closer to what was originally used for v1.5 than MAKEFILE from 3DR's sources. This covers the optimizations toggled for the Watcom C compiler, as well as the EXE originally being named GAME.EXE. The latter applies for Duke3D v1.5 as well as the EXEs Matt made using the code.

Matt's sources are of EDuke 2.0 build 21 i.e., EDuke 2.00.21, though, while the original EXE is 2.00.23. I used the EDuke 2.1 sources (one of the archives) as a reference for the changes.

Additionally, I still had to copy the MACT library's headers from 3DR's sources, as these were missing from Matt's original release of the EDuke 2.00.21 sources. (I know there was a second release, but I eventually started from the first.)
I further had to copy MAKEFILE.LNK from there and adapt it. Figuring out that the EXE was originally named GAME.EXE, rather than DUKE3D.EXE or EDUKE.EXE (or anything else) was one thing, but I were also left with minor diffs of 3 bytes from the original EXEs of Matt. Eventually (thanks Watcom), adding "segment type code lo" and "segment type data lo" to MAKEFILE.LNK turned out to be the solution.
Another thing that was figured out earlier, is the usage of "file" instead of "library" for the LIB files in the LNK file. This leaded to some changes, like a different (original) order of AUDIO_WF.LIB symbols, as well as a forced presence of BUTWCD4.LIB in Matt's EXEs, even though it's unused.

These EXEs are covered in my repository:
- Duke Nukem 3D: Atomic Edition v1.5, up to differences to be described soon.
- The following EXEs originally built by Matt (recreated byte-by-byte): NAM/NAPALM Full Version 1.0, WW2GI Full Version 1.0 and EDuke 2.00.23 (the original binary EDuke release from the year 2000 mostly known as "EDuke 2.0").

Note that for any comparison you might be making, there should *not* be any (originally) unofficial patch applied, like the removal of copy protection. Digital releases (e.g., Steam and GOG.COM) may be impacted, too.

All of Matt's EXEs can be faithfully recreated byte-by-byte, provided that you're using Watcom C 10.6a. As usual, using the correct version is *very* important here. Any other version can lead to a different EXE layout!

Regarding Duke3D v1.5, well, there are a few differences. I've been a bit stuck with this for a while, initially assuming that a version of Watcom in-between 10.0b (as used for ROTT v1.3 and the Apogee Sound System v1.04) and 10.6a (Matt's EXEs) was originally used for the game code. Sadly, though, it didn't seem like Watcom 10.5 assisted here. Not being entirely sure which wcc386 parameters were originally used, and/or if I'd missed anything in the code, didn't really feel helpful.

Surprisingly, though, it turned out the README file from 3DR's release of the code was right. Watcom C 10.0 was used. Yes, this is an EARLIER version than what was reportedly used for ROTT. As for the optimizations, they're the same as in Matt's MAKEFILE.

Note that v1.5 won't be *exactly* the same as the original. There are two reasons for this:
- The original EXE has a copy of DOS/4GW Professional. The tools can be used in a similar manner for the newly recreated EXE, but there are good chances you'll still get (another) minor difference from the original, say of 6 bytes.
- Additionally, as previously occurring with ROTT and the Apogee Sound System, some unused data gaps in the binary EXE/LE data section/segment (mostly between C strings) differ from the originals. The exact contents seem to depend on the environment in which the compiler was ran, or at least on the *exact* contents of the compiled source files. I suspect this is related to the v10.0(x) series of Watcom C, since this was not reproduced with Matt's EXEs (built with 10.6a).

Further note that some binary object and library files were used. These were made available with the sources as released by 3DR and Matt altogether. I also have *guessed* versions of Watcom originally used for some objects, based on modification dates of Watcom headers. Here's a list:
- A.OBJ, CACHE1D.OBJ, ENGINE.OBJ, MMULTI.OBJ: The Build Engine, probably built with some variant of Watcom C 10.5.
- AUDIO_WF.LIB: Apogee Sound System v1.1. I'm more-or-less convinced it was built with Watcom C 10.0b.
- MACT386.LIB: The MACT lib., with another mention of 10.5.
- BUTWCD4.LIB: The Total Entertainment Network (i.e., TEN) lib., also presumably built with 10.5.

* In fact, this isn't entirely accurate. I've modified the Apogee Sound System sources so you can more-or-less recreate v1.1. However, you'll still prefer to use the existing AUDIO_WF.LIB file, if only due to unused gaps between C string literals and more being filled with contents differing from the original. As in the case of the game code, this might be related to the Watcom C v10.0(x) series.

[NY00123]

Quoting from a new post of mine at the Duke4.net forums, main difference being nothing is surrounded by spoiler tags (https://forums.duke4.net/topic/10026-re ... ntry322222):

I think that it's a good time for a new post

Turning out to be quite lengthy (of course), I've decided to keep most of the details later in this post, and keep a short/medium summary on the top of it.

I should probably begin by saying that the bonus/duke3d directory was collapsed into duke3d. You should see why soon. A few build scripts were also changed again.

Before getting to actual updates in the gamesrc-ver-recreation repository itself, I'll first link to the following threads, in case you aren't aware of at least one of the covered topics:

https://forums.duke4.net/topic/10448-sh ... -released/ - Thanks to Devolver Digital, last February had a re-release of Shadow Warrior sources, this time confirmed to match versions 1.0, 1.1 and 1.2 in behaviors (some work will still be required for saved games compatibility); Additionally, thanks to Ken Silverman, the sources for the ENGINE.C/ENGINE.OBJ file as used in SW 1.1 and 1.2 are also covered, along with a renamed CACHE1D.C file from 1995 named CACHE1D.TXT.

https://forums.duke4.net/topic/10589-re ... d-sources/ - Again thanks to Ken, this covers historical Build Engine revisions, mostly in the forms of object and header files. There's also a 95 revision of ENGINE.C which covers the abandoned groudraw feature.

It is now the time to list some additions to gamesrc-ver-recreation. As usual, I cannot guarantee that I'll do more than what's listed here in the future.

A summary is following:

- The repository has a new "kenbuild" directory. Among other things (a portion of which to be mentioned soon), you can use it to recreate the version of Ken-Build's GAME.EXE as originally released by Ken on June 2000, using Watcom C 11.0. Note that this should *not* be confused with minor edits done by him on Nov 2002.
- Using the ENGINE.C code which is matching SW 1.1/1.2, SW 1.0's revision could be recreated. Turns out it differs from 1.1/1.2 just by a few constants in drawmapview, clippoly and fillpolygon (unless I've missed something).
- Nuke.YKT came in and used the above SW 1.1-1.2 revision of ENGINE.C in order to recreate Duke3D 1.5's. In fact, originally he wanted to do something similar for Redneck Rampage, but eventually it turned out to pave the way for the Duke.
- A bit later, I came in and took the Ken-Build 2000 revision of A.ASM, in order to recreate the one common to Duke3D 1.5 and SW 1.0-1.2. Unlike the 2000 revision which should better be built with WASM, the older revision requires MASM 5.10.
- As for CACHE1D.C, both Nuke.YKT and me confirmed that the Duke3D 1.5 revision isn't that different from the 2000 one. The former is also the same revision as in SW 1.0-1.2.
- No change was required for MMULTI.C: It's the same as in the Ken-Build release, and also in a source archive of Ken's 2DRAW engine.
- Later, I got to take care of Duke Nukem 3D: Atomic Edition 1.4. This covers the game code and Build Engine code altogether, with a few bits of very important help from Nuke.YKT. I think that most of the changes were in the Build Engine. 1.4 and 1.5 don't differ as much, and the GPLed release's "source" dir is closer to 1.4 than 1.5.
- Finally, following the Shadow Warrior sources re-release, I faithfully recreated almost all of the Apogee Sound System revision used in SW 1.0-1.2 i.e., version 1.09 of AUDIO_WF.LIB. Only actual code difference after compiling, is that the recreated FX_SetupCard code has a bit different register read, although the behaviors should be equivalent.

=====================================

More details for the interested:

- As stated above, the repository has a new "kenbuild" directory. Initially, it had the open-sourced Ken-Build release, as uploaded by Ken on June 2000 and later edited on Nov 2002 (just minor edits). I confirmed that the June 2000 GAME.EXE file can be recreated with Watcom C 11.0. I'm not sure about the Nov 2002 revision, but I *guess* that it comes to a Watcom C 11.0c beta, or alternatively another early Open Watcom revision preceding 1.0.
- The SW 1.1/1.2 revision of ENGINE.C should be covered as well. Evidence shows that their OBJ files were originally made with Watcom 10.6, rather than 10.5 as used for the rest of the non-ASM objects; For reference, all objects other than ENGINE.OBJ are the same as in Duke3D 1.5. A.OBJ and MMULTI.OBJ are further the same as in Duke3D 1.4.
- The SW 1.0 revision of ENGINE.C is also in. Turns out it differs from 1.1/1.2 just by a few constants in drawmapview, clippoly and fillpolygon (unless I've missed something).

* The following is the very first significant contribution to the repository from Nuke.YKT:
- According to him, initially, he tried to reconstruct Redneck Rampage's revision of the engine, just by comparing function sizes. He then compared RR's engine to Duke3D 1.5's and figured out that the sizes matched. In fact, the only remaining differences were things that he missed. Afterwards, the Duke3D 1.5 / RR revision of the engine was perfectly reconstructed by him.
- As expected, most of the work was on ENGINE.OBJ. Both of us confirmed that 1.5's CACHE1D.OBJ, also used in SW 1.0-1.2, didn't differ a lot from the open-sourced release of 2000. As stated above, MMULTI.C was the same code as in Ken-Build and 2DRAW.
- I took some looks at A.OBJ. While the Ken-Build revision should be built with WASM, it turned out that the revision from Duke3D 1.5 and SW 1.0-1.2 would better be built with MASM 5.10. Ken's released A.ASM file even has hints about this. I further had a bit of important assistance from Nuke.YKT at some point.

* The next step was recreating the game and Build Engine code used in Duke Nukem 3D: Atomic Edition 1.4. On the game-side of things, this more-or-less started using the GPLed release's "source" dir, after reverting changes applied for the release (like making it compatible with the bundled Build Engine files, which turned out to match 1.5).

Regarding the Build Engine, initially an October 96 revision of ENGINE.OBJ was used. It's really close to 1.5's revision. Later, a few portions of the aforementioned 95 revision of the ENGINE.C code were used. Towards the end of the Build Engine recreation for 1.4, there were what were presumably minor issues, for which I got very important help from Nuke.YKT, mostly to do with the way global variables are ordered in ENGINE.OBJ's layout (and eventually the EXE layout).

As previously stated, Duke3D 1.4 isn't that far from 1.5 in terms of game code, while there are clearly more differences in the Build Engine. Also, again, he GPLed release's "source" dir is closer to 1.4 than 1.5.

Currently identified e.g., by grepping AV_DR_DN3DGPLSRC in the sources, you can spot differences related to sound management, as well as file handles. The most interesting, though, is that 1.4 doesn't have some SE40 code which is found in 1.5.

Wait, SE40 code? Isn't that some unused code found under that extras/se40.c file? Well, this is true, but it's essentially a bit different revision of code in version 1.5 of game.c. As figured out by Nuke.YKT later, Duke3D 1.5 does have quite partial and incomplete SE40 ROR support!

Regarding the libraries, only the Build Engine changed between 1.4 and 1.5. The Apogee Sound System, MACT and TEN remained unchanged.

Some examples of changes in Build Engine code, not just between versions 1.4 and 1.5 of Duke3D:
- Some revision preceding the public Ken-Build revision from 2000 had CACHE1D.C:MAXCACHEOBJECTS increased from 6144 to 9216. According to BUILD2.TXT, the Oct 4 97 revision had BUILD.H:MAXTILES increased in a similar manner for Xatrix. Both were presumably done for Redneck Rampage Rides Again.
- CACHE1D.C:allocache had a replacement of a call to copybuf with copybufbyte, fixed for Plutonium Pak as described in BUILD2.TXT.
- ENGINE.C:drawvox was still under development before the release of Duke3D 1.5.
- Red-blue stereo mode (this info isn't actually based on inspecting the code): Duke3D 1.4 still has the functionality at a level similar to 1.3d's, although you should choose mode 6 instead of 7, as in 1.5.

* Finally, following the Shadow Warrior sources re-release, I faithfully recreated almost all of the version of the Apogee Sound System used in SW 1.0-1.2 i.e., version 1.09 of AUDIO_WF.LIB. The recreated FX_SetupCard code still has a bit different register read after compiling, although the behaviors should be equivalent. This also applies to the mostly complete recreation of version 1.04 (used in ROTT 1.3), btw. There wasn't that much code to recreate, anyway, since 1.09 is in-between 1.04, which was recreated for most, and 1.1, which was completely recreated.

Interestingly, according to strings in the EXEs, it turns out that SW 1.0-1.2's revision of AUDIO_WF.LIB, 1.09, is actually a bit *older* than the one used in all of Duke3D 1.1+. Apparently, Duke3D 1.0 is also using 1.09, while the leaked 19960104 build is using 1.08. When it comes to SW, sw960611 and later use 1.09, while sw950115 and sw950210 use 1.00 (the /ASSVER parameter is also functional for certain older builds).

[NY00123]

Hey there,

Given the availability of the forums, it's probably a good chance to bring an update.

To begin with, as of early 2020, I converted the repository from Mercurial to git, and also took the chance to split it into separate submodules.

As a consequence of the latter, I changed to the following URL: https://bitbucket.org/gamesrc-ver-recreation/

Around that time, I was also done with adding recreated code for a tool. This tool is basically Duke3D's Build editor.
For a bit of a background, like the rest of the Build Engine, most of the editor's source code was unavailable for the game devs.
However, they got hooks that could be used for extending it. The file with the hooks in question was originally named BSTUB.C. It was renamed ASTUB.C for Duke3D.

Regarding the covered versions of the editor:
- I first started with the editor from Duke3D v1.4, also re-used for v1.5. Most of the changed code was in ASTUB.C (i.e., Duke3D-specific), but it also turned out that there were a few differences in the engine, compared to Duke3D v1.4 (the game).
- I later moved on to the editor as coming with Duke3D v1.3d. I actually had a guess that the GPLed ASTUB.C file was matching v1.3d. As it turned out, except for the version string being "DUKE NUKEM BUILD: V032696" instead of "DUKE NUKEM BUILD: V041996", as well as changes presumably done by Charlie for compatibility with Duke3D v1.5's engine for most, it actually was matching v1.3d.
- As expected, most of the work on v1.3d's editor was engine-side. I made use of earlier efforts of Nuke.YKT, along with a 1995 snapshot of ENGINE.C which was open-sourced (https://forums.duke4.net/topic/10589-re ... d-sources/).

The following covered games were Heretic and Hexen, beginning with the latter.

The open-source release of Hexen turned out to match one revision identified as version 1.1, out of two. I basically found out that an earlier 1.1 revision differs just in A_SoAExplode, the VERSION_ID macro and the date in the VERSIONTEXT macro. It wasn't initially obvious that, in fact, it wasn't just one of these that was actually released as "v1.1".

The A_SoAExplode fix involves checking the "nomonsters" option, as well as the lack or presence of an mobjinfo's MF_COUNTKILL flag, before spawning a monster after breaking a suit of armor.

I later recreated the behaviors of Hexen v1.0, for which there turned out to be two virtually-identical revisions again. They differ just in a CD music check within P_SetupLevel.

At some later point, I started to work on a 4-level demo of Hexen from Oct 18 1995.
Following this, I continued with Heretic, covering versions 1.0 and 1.2. It turned out that the released sources match 1.3, and as confirmed by PVS of Doomworld, that 1.2 is usable with maps from all episodes within the Shadow of the Serpent Riders' IWAD.

As of the last day, I've gotten another addition for the Hexen repository. To make this short, it should now cover code which is more-or-less fully equivalent in behaviors to the 4-level beta (Oct 2 1995).

There's probably too much to write about the code itself, so I'll simply mention the following examples of information:
- This revision has code for the removed fly creature (https://doomwiki.org/wiki/Fly).
- The 4-level demo from Oct 18 1995, previously named HEXDMO10 in my repository, was renamed HEXDM10B, while the earlier demo was named HEXDM10A.
- I considered renaming HEXDM10B back to HEXDMO10, while HEXDM10A would be renamed using (a subset of) the EXE's original modification date; Reason being, the latter is identified as a beta in-game, and I already did a similar thing with a Wolf3D proto. beforehand.
- However, both versions are referred to as demos in the README.TXT files from 1995. I also don't currently recall any mention of a version number, like 1.0. For now, I just keep using the names of HEXDM10A and HEXDM10B.
- I originally started to inspect the 4-level beta as a possibility after finishing with Heretic 1.0-1.2. I eventually returned to the beta more recently. What's clear is that it required more work to recreate the code than the previously covered versions of Hexen; Maybe even more than all previously covered versions of Heretic and Hexen, combined.
- In addition to the previously known issue of global variables not being fully ordered as in the original EXE, there are also a few functions that I couldn't get their compiler-generated layouts to fully match. Unless I missed anything, they should still match in behaviors. The functions in question are A_Quake, P_XYMovement and P_ZMovement. The latter's C code was actually not changed by me at all.