Restoration of Hexen 1.0 and other games' EXE revisions

[NY00123]

Hi all,

Let me introduce you to the following collection of repositories: https://bitbucket.org/gamesrc-ver-recreation/

Basically, most of this work involves reverse-engineering of code related to games. However, rather than REing a whole game, what I usually do is RE a different version of an already open-sourced game. The success rates vary greatly, due to the technicalities involved.

I got this idea after the open-source release of not just one, but multiple DOS versions of Softdisk's Keen Dreams title. In particular, I had a look at the revision matching shareware v1.13. Using what I assumed to be the exact process for making the EXE, I got precisely the original EXE from the 90s, byte-by-byte. This process includes usage of the right compiler version, as well as packing the EXE with LZEXE 0.91.

Back to the above-mentioned collection of repositories, a more successful example that you may find is the code for Wolfenstein 3D and Spear of Destiny. With minor exceptions for certain Spear of Destiny EXEs, this should cover EXEs that may be perfectly recreated, byte-by-byte.

Examples are the Apogee versions (shareware/registered versions 1.0, 1.1, 1.2 and 1.4(g) without disabling the cheats), as well as the Activision versions. With the assistance of earlier REing work done by Blzut3, I also added the DOS version of Super 3-D Noah's Ark, which can be perfectly recreated, minus the debugging information. I further have a separate tree for Blake Stone, similarly building upon Blzut3's work for REing Aliens of Gold (the open-source release covers just Planet Strike).

Now, my most recent addition is Hexen 1.0, with version 1.1 also being covered. You can find these under the "hexen" submodule.

In the case of Hexen, especially version 1.0, the EXE isn't exactly matching in layout, although there are great chances that it's otherwise identical in behaviors. Saved games compatibility might be an exception; I'm not sufficiently familiar with Hexen's saved game format to know for sure.

More notes to add:
- Like the original open-source release of Heretic and Hexen, this is not including the proprietary DMX sound library. I've added a GPL-compatible replacement, albeit it won't sound exactly the same, especially the music (excluding CD Audio). Some of you may recall Nuke.YKT's PCDoom port. As a part of his work on it, he created a DOS-compatible DMX wrapper which is backed by the Apogee Sound System. So, I've made a few changes to the wrapper and then uploaded it. You'll need to have the submodule subdirs of "audiolib", "apodmx" and "hexen" residing in the same directory.
- As usual with public repositories, there might be changes later, like using output directory names differing from "10" or "11". Just for one example of an explanation, I've recently learnt that there might actually be two original Hexen DOS EXEs identified as 1.1, with one of them possibly including the following A_SoAExplode bugfix for DK, which I've disabled for now: https://bitbucket.org/gamesrc-ver-recre ... lines-1161
- What about other id Tech 1 games, like Doom or Heretic? Well, Doom is expected to be quite more difficult, since we don't have access to original DOS sources. Heretic should hopefully be closer to Hexen, in case I get to it; Although, while working on Hexen 1.0, I occasionally used Heretic code as a reference (even bringing a few functions from Heretic as-is). I might not have this privilege for older versions of Heretic. What I can say, though, is that an earlier inspection of Nuke.YKT and me shows that the Heretic sources appear to match version 1.3.

[Blzut3]

I've recently learnt that there might actually be two original Hexen DOS EXEs identified as 1.1

Given the name of the macro, are you speculating that this second 1.1 exists or has it been found in the wild?

[NY00123]

Given the name of the macro, are you speculating that this second 1.1 exists or has it been found in the wild?

The usage of this macro was added near the beginning, and was technically the first usage of any such macro in the git log for Hexen. So, I just used AV_HR_OPENSOURCEREV, in a similar manner to the Duke3D tree having AV_DR_DN3DGPLSRC for the "source" dir of the GPLed release from 2003 (excluding changes which were probably done by Charlie Wiederhold before releasing the code).

I found an alternative 1.1 EXE, which differs from the one available from Steam, in this repository: https://github.com/Doom-Utils/iwad-patc ... la-engine/

A short while after my original post here, I verified that this other EXE is indeed matching the Hexen sources as originally released. In particular, these are the few differences that I could find:
- The A_SoAExplode bugfix being present in the EXE from the above repo (not fixed in the EXE from Steam).
- VERSION_ID is set to CBI in the earlier 1.1 EXE from Steam, and to BCP in the later one.
- The expanded __DATE__ string differing as expected.

[NY00123]

The Hexen repository has been updated.

- First of all, albeit this dates back to the end of last May, the repository should now cover two variations of version 1.0, as well as two variations of version 1.1.
- As previously stated, the two EXEs identified as 1.1 differ just by the A_SoAExplode -nomonsters bug fix and the VERSION_ID string.
- Regarding the two EXEs identified as 1.0, they differ just by making the call to S_StartSongName from P_SetupLevel conditional, depending on the value of i_CDMusic.
- Finally, a major addition to the repository is Shareware Demo v1.0.

Due to the lack of a preprocessor macro for the demo, I had to manually figure out which definitions are missing. At the least, there wasn't a lot of new code to add.
Examples of differences:
- Various sprite, state and map object definitions are omitted.
- A_ACTION.C:A_SoAExplode is not present in the demo.
- SB_BAR.C: The cheat codes differ, and so does their encryption.
- R_DATA.C:R_InitTextures: ST_Progress is called once per 8 textures in the demo, instead of once per 32 textures.
- H2_MAIN.C: It looks like the DoTimeBomb function was repurposed for the demo.
- P_SETUP.C: DEFAULT_SKY_NAME was changed from "SKY1" to "SKY2" for the demo.
- A_SmokePuffEntry and A_SmokePuffExit were (probably) moved to the end of P_ENEMY.C in the demo version. As a side-note, A_SmokePuffEntry itself isn't present in v1.1, and there's currently no use of it in the codebase at all.
- I_IBM_A.ASM:I_ReadJoystick_: pushad and popad were replaced with pusha and popa, respectively.
- HEX.LNK, HEX_DMO.LNK: i_cdmus.obj is the first obj file to be listed for the demo.
- P_ENEMY.C:A_Explode: For an actor of type MT_HAMMER_MISSILE, damage isn't explicitly set to 128 again in the demo. For MT_ZXMAS_TREE, distance is set to 40 in the demo, instead of 64.
- P_ENEMY.C:A_DemonAttack2: P_SpawnMissile is called with a hardcoded mobj type of MT_DEMONFX1 (MT_DEMON2FX1 isn't present in the demo).
- P_SPEC.C:P_ExecuteLineSpecial: If the input special value is 74 (Teleport_NewMap) and all conditions required for calling G_Completed in non-demo versions hold, then G_Completed may be called only if args[0] <= 4. In case args[0] > 4 and &players[consoleplayer] == mo->player, an "ACCESS DENIED -- DEMO" message is prepared to be shown.