Restoration of differing Doom engine EXE revisions (also done for other games)

With regards to research into Heretic, I'm interested in whether the desyncs with the IWAD demos are purely down to the changed firemace spawning behavior, or if any other alterations were at play.  I know a couple other alterations to the EXE behavior took place (in v1.0 you could instakill iron liches with the tomed-up firemace, and the thing table changed slightly which is why HHE's thing listing is messed up).

@NY00123 you may want to take a look at Maraakate's works, especially DoomNEW. It recreates the Doom executable for DOS , but with Heretic system drivers. And yes, it includes DMX support. I recall that Maraakate was given these sources by John Romero.

I wonder why DMX code has been never released. Is there any strong reason why not to release DMX source? It's been so many years and many games released their source, so why not DMX? Is there anything secret or sensitive about its code? Or was the code lost? Or was it even Paul Radek's personal reasons, for example he felt too shy to release code which would be too "shitty", as it's known Doom developers said bad things about DMX?

11 hours ago, ETTiNGRiNDER said:

With regards to research into Heretic, I'm interested in whether the desyncs with the IWAD demos are purely down to the changed firemace spawning behavior, or if any other alterations were at play.  I know a couple other alterations to the EXE behavior took place (in v1.0 you could instakill iron liches with the tomed-up firemace, and the thing table changed slightly which is why HHE's thing listing is messed up).

Did anybody figure out in the past the exact original firemace spawning behavior (say by reverse engineering)?

If yes, then I suppose that one can grab some Heretic sources that you can build and are known to behave like 1.3 (say Chocolate Heretic), apply this modification, make an exe and then play back the demos; Mainly since I consider the Heretic sources to match 1.3 in behaviors at this point.

11 hours ago, Redneckerz said:

@NY00123 you may want to take a look at Maraakate's works, especially DoomNEW. It recreates the Doom executable for DOS , but with Heretic system drivers. And yes, it includes DMX support. I recall that Maraakate was given these sources by John Romero.

Thanks for the suggestion. Yes, I'm aware of the copy of the DMX files that he got. I actually used the DMX 33gs headers and the DMX 34a library, since Nuke.YKT initially tried to do this with Heretic and seemed to get quite close code. It turned out that the open-source release of Heretic is matching 1.3 (as available from Steam), although it's possible that the compiler may generate the code of one function or two a little bit differently.

Why not just use the DMX 34a headers, btw? Well, they appear to differ just in one header file, and only by the addition of 1-2 additional extern symbols (and also a couple of more macros). The addition of any function/variable declaration or definition, even if it's just a declaration of a function/variable which doesn't even exist, is enough for changing the order of global variables as present in the EXE, at least with Watcom.

For reference, the presence of these DMX files was mentioned in this issue, initially discussing MIDI sound effects: https://github.com/chocolate-doom/chocolate-doom/issues/639#issuecomment-156249500

Doomworld thread on the topic:

50 minutes ago, Hisymak said:

I wonder why DMX code has been never released. Is there any strong reason why not to release DMX source? It's been so many years and many games released their source, so why not DMX? Is there anything secret or sensitive about its code? Or was the code lost? Or was it even Paul Radek's personal reasons, for example he felt too shy to release code which would be too "shitty", as it's known Doom developers said bad things about DMX?

Getting Doom and other games open-sourced was a thing of Carmack, while working for id Software, so it obviously had nothing to do with code not belonging to id. There seemed to be disagreements from id Software's side on decisions done while DMX was developed, which obviously wouldn't assist here.

Either way, Paul may have his personal reasons, indeed. As I'm not even sure that Digital Expressions, Inc. (the company which was used for licensing DMX) still exists, it might just be simpler to do nothing. Another possible reason is that, according to the following Wiki page, Paul holds various patents related to audio in games: https://doomwiki.org/wiki/Paul_Radek

10 minutes ago, NY00123 said:

Thanks for the suggestion. Yes, I'm aware of the copy of the DMX files that he got. Its presence was mentioned in this issue, initially discussing MIDI sound effects: https://github.com/chocolate-doom/chocolate-doom/issues/639#issuecomment-156249500

A few other recent releases are from the democommunity at Heretic and Hexen. Perhaps it is useful. These are demo focused builds however!

• CHexen, CHeretic and SHeretic (Smart Heretic, SDL based port)
• Chocolate Heretic and Hexen (se)
• JHeretic 0.93.4 (se)
• Hexen and Heretic ''A'' versions (Also by Maraakate), rehosted by @PVS
• vvHeretic

They all link to their respective post where they can be downloaded.

NY00123
Thank you very much for this work! These sources are good, it’s very convenient to read the differences between 1.0 and 1.1 versions when the code is in one 2in1 files. I also have a technical interest in Hexen/Heretic 1.0 versions and a few years ago I tried to achieve compatibility with Hexen/Heretic 1.0, but I have no experience in reverse and I used a more primitive and incorrect way.

Can I ask you to compile your Hexen 1.0 version? I can’t do it myself, but would be interested to test it in practice. I looked at this source a little, it seems to me you also could catch a Hexen 1.0 save game files compatibility, are you sure that they are not compatible? If you can attach the compiled version here or in PM, I would be very grateful.

Have similar sources for Heretic 1.0 would be great, of course. My compatibility with Heretic 1.0 is not complete, somewhere I didn’t find/don’t know something, but I could try to remember which functions are of the greatest interest, if it helps you. I understand that your goal is different - recreated original version byte-by-byte, for me it’s like a separate mode that need to turn on/off on the fly, in the source port.

Redneckerz
Thanks for showing me this topic, I'm surprised that there are still people who are interested in old Hexen/Heretic versions.
 

Hey @PVS, thanks for your interest!

On 5/7/2020 at 1:45 AM, PVS said:

Can I ask you to compile your Hexen 1.0 version? I can’t do it myself, but would be interested to test it in practice. I looked at this source a little, it seems to me you also could catch a Hexen 1.0 save game files compatibility, are you sure that they are not compatible? If you can attach the compiled version here or in PM, I would be very grateful.

Have similar sources for Heretic 1.0 would be great, of course. My compatibility with Heretic 1.0 is not complete, somewhere I didn’t find/don’t know something, but I could try to remember which functions are of the greatest interest, if it helps you. I understand that your goal is different - recreated original version byte-by-byte, for me it’s like a separate mode that need to turn on/off on the fly, in the source port.

Redneckerz
Thanks for showing me this topic, I'm surprised that there are still people who are interested in old Hexen/Heretic versions.
 

All right, I have attached an EXE. It still requires an external DOS/4GW loader or compatible (e.g., DOS/32A). The audio output, especially the MUS tracks, is expected to sound different, due to usage of the apodmx wrapper.

I've used the following repositories with the referenced commits, and further with the Apogee Sound System matching version 1.09:

https://bitbucket.org/gamesrc-ver-recreation/audiolib/src/ad045a8d066d4f806b73b008afa134aabd3ac973/

https://bitbucket.org/gamesrc-ver-recreation/apodmx/src/9658b6c89ff27a223e456d12cf17828a4d40f0b1/

https://bitbucket.org/gamesrc-ver-recreation/hexen/src/505686ef1310fc3d22410e5674c868a75272fb52/

Personally, I only properly completed the relevant Heretic and Hexen titles once (in terms of play-throughs). However, I still have differing periods of interest in recreating sources for older versions of (generally) open-sourced games from the 90s, like these. While I still can't make any promise on Doom or even Heretic, my plan has been to start from Hexen, then continue to Heretic, and finally, if it's feasible, try to tackle Doom.

One way in which I think this work differs from ports supporting the behaviors of multiple versions (including DOS ports), as described by you, is the following. Basically, what I'm trying to do is prepare an infrastructure, which can later be used by ports like Chocolate Doom.

STRIPHEX_10_20200508.7Z

IIRC HeXen 1.0 read it's text screens from somewhere in the exe, while 1.1 read them from cluster lumps in the iwad.

NY00123
Thanks, I like exe name, nearly strip poker, heh

I tested - everything works well! Not sure if you need such information or not, tested on real old hardware (not dosbox), DOS7, Dos4gw 1.97, compare only with original Hexen 1.0. SFX/midi music - sounds somewhere at 1/3 of the usual volume, sometimes SFX is strange, but in general it’s not bad, I don’t see anything wrong with that. Recorded/playback several test demos - compatibility is there, I do not see any desync's vs original 1.0 at the moment. Save game files - compatible, I don’t know why you said that there might be a problem, everything works for me.

I understand the problem with licensed sound/music code, but I wonder how compiled CHexen, it is 1.1 version, but it sounds identical to the original for me and does not require Dos4gw, interesting. I also achieved save game files 1.0 compatibility from port, according to your sources, but only static for now, in test build. I would like to do this optionally, ideally - on the fly, but so far I don’t know how to change all necessary frame/state/mobj structures in Info.c/h on the fly, without engine restarts. I’m sure that this is possible, I’m just new to this task.

At the expense of your work/hobby plans - I understand you, in any case, thank you again, for me your Hexen 1.0 work on this project has many interesting details that can now be easily viewed. Hexen still have other PC versions, like Hexen95 - where we again see demos desync's right from iwad, according to the old Raven tradition. Shareware Demo-1,2 exe versions and Retail store beta - a lot of work ahead, heh, just kidding.

Vermil
Yes, you're right, all this text was in exe in 1.0 and older, maybe Raven move it to iwad specifically for us, so that we can easily change it, in our maps/hubs? Also, it always seemed to me that in 1.0 more corpses on the floor, now, looking at the 1.0 source - it seems that this is really so, Ettin and Afrit corpses not removed at all by engine in 1.0, I think.

And now, it will also be easier to find this small difference:

Some effects, projectiles, torches, etc. - were dim in 1.0, I noticed this for a long time, and this is comes from engine, not from iwad. Most likely, it was a small bug that was fixed in 1.1. This screens from original 1.0 and 1.1 versions. As an option, this happens with 1.0 only on my hardware, not sure. Also, on this screens visible one more original bug, if anyone notices, at the same time we check whether - there are Hexen guys here or not :)

22 hours ago, NY00123 said:

Hey @PVS, thanks for your interest!

 

 

All right, I have attached an EXE. It still requires an external DOS/4GW loader or compatible (e.g., DOS/32A). The audio output, especially the MUS tracks, is expected to sound different, due to usage of the apodmx wrapper.

So, if i get this right, this ''StripHex.exe'' (Love the name) is a reverse engineered build of Hexen 1.0, because Hexen 1.0 has not been cloned/copied yet?

Maybe i am naive here, but this kind of process seems like a perfect fit for the Chocolate line of releases to improve compatbility. I am not sure if that's the aim of your efforts, but it definitely looks like something that particular project could benefit from. :)

I’m not sure what you mean, Raven published their last 1.1 source and which code was previously in 1.0 - just were unknown until this moment (as far as I know).

This hard work by NY00123 may be of interest not only for Chocolate project - for all, who are interested in these details. I strongly doubt that Hexen 1.0 will be of interest to Chocolate team.

fixed my screens above, I hope they can be seen now, sorry.
 

10 hours ago, PVS said:

I’m not sure what you mean, Raven published their last 1.1 source and which code was previously in 1.0 - just were unknown until this moment (as far as I know).

This hard work by NY00123 may be of interest not only for Chocolate project - for all, who are interested in these details. I strongly doubt that Hexen 1.0 will be of interest to Chocolate team.

fixed my screens above, I hope they can be seen now, sorry.
 

So Raven released 1.1 source, but not 1.0 - This StripHex is effectively a reverse engineering of 1.0 to highlight the differences between Hexen 1.0 and 1.1.

Is that how i should understand it? :)

Yes, possible interpret it like that.

There's some interesting stuff on the Doomwiki about console Hexens.

Apparently the N64 one has intermission story text and the 32-bit versions have movies.

The story text could be easily done with a mapinfo of course.  (EDIT: Was thinking of modern ports.   Of course vanilla hexen.exe has mapinfo but it's not as flexible.)

On 5/9/2020 at 9:23 PM, PVS said:

Also, on this screens visible one more original bug, if anyone notices, at the same time we check whether - there are Hexen guys here or not :)

Is it the weapon slot in HUD? It's showing Fighter's weapon instead of Mage's

Hisymak
Yes, you solved this correctly! heh. There is also a chain from Fighter, i.e. just the full Fighter status bar is displayed, instead of the desired one. This happens for Cleric and Mage on the vanilla Hexen only in demo playback mode. It's easy to see, start the game and watching the demos in the main menu, Demo-2 and 3 will be for Mage and Cleric.

Even more, these two examples from playback a solo-DM demo, engine is trying to apply patch'es for 4th Cleric/Mage weapon on the Fighter status bar, it turns out bad:

Gokuma
Not sure, that vanilla Hexen will be able to show text between maps, only hubs end's and final texts. For modern source ports - it should be possible.
 

Thanks again for the interest in this work!

Going to answer about some points raised here after my preceding post:
- First, a few examples of hardcoded texts specific to Hexen 1.0: https://bitbucket.org/gamesrc-ver-recreation/hexen/src/112c5f366158f930f9755895298195bd57370879/IN_LUDE.C#lines-156 https://bitbucket.org/gamesrc-ver-recreation/hexen/src/505686ef1310fc3d22410e5674c868a75272fb52/F_FINALE.C#lines-62
- I wasn't sure about saved games compatibility, again due to not being familiar with the codebase. I do know that in the earlier titles of Keen Dreams, Catacomb 3-D and Wolfenstein 3D, the saved game as present in the file also includes 16-bit near pointers, which clearly depend on the EXE layout. At least in Hexen, I believe that at the most, the difference between two pointers to different locations in the same array is written, and this is indeed not dependent on the EXE layout, at least not in the same manner.
- Regarding the sound library and licensing, I haven't yet checked CHexen or another port to be sure. I was just aware of Nuke.YKT's DMX wrapper using the Apogee Sound System, so I realized that it'd possibly work with the original Hexen sources after not more than a few changes. I've just looked for CHeretic and CHexen now, though, and what I can find are archives with EXE and TXT files, but not the sources?
- A short explanation about the name STRIPHEX.EXE: If you check the makefile as present in the open-source release of Hexen, you can see that the Watcom Linker (wlink) is first used to create hex.exe, then the file is copied to striphex.exe, and finally, debugging information is removed from the latter using the Watcom Strip utility (wstrip).
- What I've been doing is indeed useful for Chocolate Hexen . As usual, it's a matter of someone spending the time in preparing a patch or more, especially if refactoring has to be done due to the desire to support multiple versions from a single EXE.

Now, following a suggestion of Nuke.YKT, I did submit a (quite) small patch for Chocolate Hexen, reverting a bug fix in A_SoAExplode, so the function will behave like HEXEN.EXE as coming from Steam: https://github.com/chocolate-doom/chocolate-doom/commit/7ac729c46dd3a221f1f9665d194ed929149aa013

However, I later learnt that there are two EXEs identified as Hexen 1.1 (if not more). The EXE not coming from Steam can be found here: https://github.com/Doom-Utils/iwad-patches/tree/71eeba800e8bd021e4b756c96b93ca2064842d21/vanilla-engine/

As it turns out, this other EXE is actually matching the Hexen sources as originally released. In particular, these are the few differences that I could find between the two 1.1 EXEs:
- 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.

Of course, supporting this in Chocolate Hexen will probably require the introduction of support for differing variations of the Hexen 1.1 EXE, like the four variations of the Doom 1.9 EXE that I'm aware of: The original EXE, Ultimate Doom, Final Doom and Final Doom - id Anthology.

Thanks for confirming that there are, in fact, two different "version 1.1" versions of Hexen.  This is something I've been meaning to look into for a while but never got around to, since it explains some weird behavior with things like the Hexen EXE hacker (i.e. Hexen DeHackEd) and the Hexen downgrader patch that was released some time ago.

I don't suppose it's easy to tell offhand whether one version goes with the floppy disk release and the other with the CD-ROM version?  That's been my working theory so far.

NY00123
About CHexen you can ask its author, how sound and music works in this version I don’t know for sure.

I also noticed many years ago that I have 2 different 1.1 exe versions, but how exactly they differ - I found out just now, from your source code. I periodically compared them for compatibility, playback/recording demos on them - I didn’t found any differences, but I have not tried 'nomonsters' mode. In fact, finding this difference visually very difficult, because A_SoAExplode can spawn monsters in an explosion, but it is used in the main maps very far, only in Deathkings of the Dark citadel, maps 47-50, 54, 57 (numbers in wad) - Raven uses spawn monsters in A_SoAExplode. But this fix also means that version 1.1-1 (I will call it that) and all previous versions will show this error visually, I tested it - it really is. Version 1.1-1, 1.0, Retail Beta - spawn monsters from 'Suit of Armor' thing in 'nomonsters' mode.

I have this 1.1 exe versions with the same file size, but different MD5 (maybe it will help to find the third version, heh):
1. 713319E8ADBC34BCA8E06DBAFF96F86C (v1.1-1, without fix, located on Hexen 1.1 CD)
2. DFE619E8C6E3339359D62CDA11E5375B (v1.1-2, with fixed A_SoAExplode)

Both versions from 1996, but it’s interesting, that this 1.1 CD also contains Hexen95 version, and Hexen95 already has a fixed A_SoAExplode function, but DOS version from this CD is not fixed. Where I got the 1.1-2 version I don’t even remember from now, most likely from a separate Raven's patch, but I have both of them in my Hexen 1.1 folder for a long time, I rotated them, hoping to see at last - how they differ, heh

There are also at least two 1.0 versions:
1. 08F08CAD60C899CDCE784C3ADF6C5A6A (v1.0-1)
2. 435FD8C4770EDF31B62BEBD64AAE9332 (v1.0-2)

Both versions with the same file size and from 1995. I assume that version 1.0-2 was on the 1.0 CD, but not sure.
 

@PVS Good to read about this information. Being quite unfamiliar with general id Tech 1 modding, albeit still having a copy of SLADE, I found myself searching for suits of armor in maps, while using DoomWiki pages as references; Emphasis on suits of armor from which monsters can spawn. Of course, this was done (at least initially) without being 100% sure that "Suit of armor" was indeed what I was looking for, again due to lack of familiarity (well, mostly with Heretic and Hexen; I'm way more familiar with Doom terminology e.g., the names of monsters).

I still want to investigate differences between revisions of Hexen identified as 1.0.

As for CHeretic/CHexen, I've had a look at a few strings in CHEXEN.EXE with a hex editor, and compared it to HEXEN.EXE (v1.1 without the A_SoAExplode fix). My conclusion is that CHexen is using DMX. The same applies to CHeretic as well.

Sadly, but I don't know much about original dos sound code at all. I sometimes work with win ports quite a bit, there is already it's own sound/music implementation.

About Hexen terminology specifics (or even about other games) - you can try to ask here, it is quite possible that someone will tell you the necessary information and it will somehow help. Differences between Hexen 1.0 it would be interesting to know, but I'm not sure - how much time and effort this process requires. There may not be differences in code, maybe Raven just recompiled exe for some reason? Commented out unused functions, etc., exe size is the same, that's strange, but this is possible if there are not many changes in code. I never tried to compare 1.0 versions on practice, tried only compared 1.1.

The difference which you found between 1.1 versions - I recorded for myself in a demo on a small test map, possible easily see it visually. This is 1.1-1 demo and will not playback correctly on the latest version. I’m also included the 1.1-1 exe itself, renamed it as Hexen111, so that someone wouldn’t accidentally erase its latest version. This demo can also be interesting for guys who really like the game itself, and who thinks - that everyone knows about it for a long time. I recorded here some rare behaviors of original engine, like broken Mage/Cleric statusbar, mystical flights of projectiles and the most interesting Mage trick with 4th weapon, about which another person told me about a year ago. I was shocked that the original engine behaves like this, I never would have guessed it myself to do these crazy actions in the game, heh

For demoplayback put exe, wad, lmp files from the archive into your Hexen 1.1 folder, run game with command line:
Hexen111 -file Xscrolls.wad -nomonsters -playdemo 111jXscr
Have fun!
 

111jXscr.zip

8 minutes ago, PVS said:

Sadly, but I don't know much about original dos sound code at all. I sometimes work with win ports quite a bit, there is already it's own sound/music implementation.

About Hexen terminology specifics (or even about other games) - you can try to ask here, it is quite possible that someone will tell you the necessary information and it will somehow help. Differences between Hexen 1.0 it would be interesting to know, but I'm not sure - how much time and effort this process requires. There may not be differences in code, maybe Raven just recompiled exe for some reason? Commented out unused functions, etc., exe size is the same, that's strange, but this is possible if there are not many changes in code. I never tried to compare 1.0 versions on practice, tried only compared 1.1.

The difference which you found between 1.1 versions - I recorded for myself in a demo on a small test map, possible easily see it visually. This is 1.1-1 demo and will not playback correctly on the latest version. I’m also included the 1.1-1 exe itself, renamed it as Hexen111, so that someone wouldn’t accidentally erase its latest version. This demo can also be interesting for guys who really like the game itself, and who thinks - that everyone knows about it for a long time. I recorded here some rare behaviors of original engine, like broken Mage/Cleric statusbar, mystical flights of projectiles and the most interesting Mage trick with 4th weapon, about which another person told me about a year ago. I was shocked that the original engine behaves like this, I never would have guessed it myself to do these crazy actions in the game, heh

For demoplayback put exe, wad, lmp files from the archive into your Hexen 1.1 folder, run game with command line:
Hexen111 -file Xscrolls.wad -nomonsters -playdemo 111jXscr
Have fun!
 

111jXscr.zip

So if i get this correctly, this is a modified build you made and recorded a demo with, but what does this Hexen111.exe do differently?

By the way, love seeing these things and other Hexen/Heretic stuff - I will have something coming up soon that might be beneficial for the demo community (Nothing new, just a summary of things, sort to say)

Redneckerz

Not, this is original 1.1-1 exe without fixed A_SoAExplode function. Versions differ only in hash and with the same file size, I renamed it so that it would be easier to use in the main Hexen 1.1 folder, and most importantly, so that someone would not accidentally erase their latest exe version, considering that they are the same. Everyone can have their own exe time stamp, especially if you use the original patch'es, you can’t focus on the time stamp.

NY00123
Noticed a little moment in your Hexen source: Sv_save.c, SV_MapTeleport() contains a number of changes for 1.1, but look at the 'boolean playerWasReborn' var here, it remained initialized in the function header for 1.0, but used only in 1.1. I can be wrong, but logically - it should not be at all here for version 1.0, because this boolean never used at all, not?
 

@NY00123 have you tried running Striphex with Ravmouse.exe? Its an external hack that allows freelook in Hexen/Heretic and Hexen/HereticP. You need to disable mouse handling in the Setup program though. It might be interesting to see if your reverse engineering supports it. More info about it here.
 

On 5/21/2020 at 11:54 PM, PVS said:

Redneckerz

Not, this is original 1.1-1 exe without fixed A_SoAExplode function. Versions differ only in hash and with the same file size, I renamed it so that it would be easier to use in the main Hexen 1.1 folder, and most importantly, so that someone would not accidentally erase their latest exe version, considering that they are the same. Everyone can have their own exe time stamp, especially if you use the original patch'es, you can’t focus on the time stamp.

Understood :) PS: Perhaps the above Ravmouse is also useful for you or in demo's? Give it a whirl :)

heh, ok, hold my whirl, everything further is just my personal opinion. Any attempts to make a mouselook on original renderer looks like shit. For normal +-90 degrees mouselook - need have normal 3D renderer, take any Doomsday and you will see there what should be a normal mouselook for vanilla Doom-engines.

About ravmouse - this is an interesting program, interesting hobby, if this mouselook is enough for anyone - good, why not. I do not use any mouselook for game/recording, I do not need it at all in this games, I continue to use mouse +-Y strafe, and this is not possible to do comfortably with active mouselook. In any case, if you run ravmouse like this 'ravmouse -?' - you see the compilation date, on your link this is Aug 21 2016, I have version from Jul 22 2017, but don’t remember where I get it. If you want it in your collection - take it, but I recommend contacting with xttl, he's still here, maybe he has a newer version for a long time.
 

RavMouse2017.zip

9 hours ago, PVS said:

About ravmouse - this is an interesting program, interesting hobby, if this mouselook is enough for anyone - good, why not. I do not use any mouselook for game/recording, I do not need it at all in this games, I continue to use mouse +-Y strafe, and this is not possible to do comfortably with active mouselook. In any case, if you run ravmouse like this 'ravmouse -?' - you see the compilation date, on your link this is Aug 21 2016, I have version from Jul 22 2017, but don’t remember where I get it. If you want it in your collection - take it, but I recommend contacting with xttl, he's still here, maybe he has a newer version for a long time.
 

RavMouse2017.zip

Thanks for this updated version.

Ironically i have sent a message to xttl yesterday (Last active in April) on a lot more of his works because a lot of his exe hacks have been defunct:

• S131mlk
• Doom32
• F2DoomPP

to name a few.

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.

On 5/22/2020 at 12:54 AM, PVS said:

NY00123

 

Noticed a little moment in your Hexen source: Sv_save.c, SV_MapTeleport() contains a number of changes for 1.1, but look at the 'boolean playerWasReborn' var here, it remained initialized in the function header for 1.0, but used only in 1.1. I can be wrong, but logically - it should not be at all here for version 1.0, because this boolean never used at all, not?
 

 

Thanks for informing me! I've finally changed Sv_MapTeleport to define this variable, as well as other local variables, just for the versions that need them.

On 5/23/2020 at 4:32 PM, Redneckerz said:

@NY00123 have you tried running Striphex with Ravmouse.exe? Its an external hack that allows freelook in Hexen/Heretic and Hexen/HereticP. You need to disable mouse handling in the Setup program though. It might be interesting to see if your reverse engineering supports it. More info about it here.

Thanks for telling me about Ravmouse.exe. Looks like it's compatible with an old copy of STRIPHEX.EXE that I built around the end of April.

While I have no idea about the way Ravmouse.exe is working at all, I assume that it's using Vanilla Heretic/Hexen's -externdriver option, which should be similar in idea to Vanilla Doom's -control option.

Thanks again NY00123, this is interesting update for me. In last time I was able to integrate in my hobby nearly all important and detailed differences between 1.1 and 1.0 versions according to your sources, just for my own interest. It even works well and almost everything I was able to switch in real time, to my surprise, heh.

I already have some work for Shareware versions based on information from Chocolate Hexen sources and some of my observations, but now there is an opportunity for me to clarify everything thoroughly, according to your work.

A small suggestion: it would be nice if you could show in documentation checksums of the versions that you used in work, I think - MD5 or CRC32 is enough. Because as of the 'exe' date, I don't quite understand which Shareware Demo exe version you were using.

I have this Shareware Demo exe versions (MD5):
1. C2DDA1704B8E302E05C26F69433729F3 (Shareware Demo v1, 1995/10/02)
2. 458D3FF08D32FC50ABB55A5B68660B6B (Shareware Demo v2, 1995/10/18)

I look at dates by the exe themselves, but the exact same dates are listed in their documentation (Readme.txt). If I understand correctly, you used a Shareware Demo exe with a date 1995/10/16, it turns out - is there a third version?

Also, the earliest version of HeXen remains, if you are interested, of course:
3A6603328F832314A4054E005DA087C6 (HeXen Retail Store Beta, 1995/09/27).
 

Hi,

On 10/30/2020 at 2:11 AM, PVS said:

Thanks again NY00123, this is interesting update for me. In last time I was able to integrate in my hobby nearly all important and detailed differences between 1.1 and 1.0 versions according to your sources, just for my own interest. It even works well and almost everything I was able to switch in real time, to my surprise, heh.

I already have some work for Shareware versions based on information from Chocolate Hexen sources and some of my observations, but now there is an opportunity for me to clarify everything thoroughly, according to your work.
 

Nice to see that you're making use of my work! Have you really aimed at getting anything similar to a source port, in which you can select behaviors of version 1.0 or 1.1 while using a single EXE? This sounds like no little work at all.

On 10/30/2020 at 2:11 AM, PVS said:

A small suggestion: it would be nice if you could show in documentation checksums of the versions that you used in work, I think - MD5 or CRC32 is enough. Because as of the 'exe' date, I don't quite understand which Shareware Demo exe version you were using.

I have this Shareware Demo exe versions (MD5):
1. C2DDA1704B8E302E05C26F69433729F3 (Shareware Demo v1, 1995/10/02)
2. 458D3FF08D32FC50ABB55A5B68660B6B (Shareware Demo v2, 1995/10/18)

I look at dates by the exe themselves, but the exact same dates are listed in their documentation (Readme.txt). If I understand correctly, you used a Shareware Demo exe with a date 1995/10/16, it turns out - is there a third version?

Also, the earliest version of HeXen remains, if you are interested, of course:
3A6603328F832314A4054E005DA087C6 (HeXen Retail Store Beta, 1995/09/27).
 

Documenting executable checksums is a good idea. I didn't always know where to find information about specific versions.

I'll quickly write details about the currently covered versions of Hexen for now:

+----------------------+--------------+----------------------------------+------------------------------------------+----------+     
|      Description     | Size (bytes) |                MD5               |                  SHA-1                   |  CRC-32  |
+----------------------+--------------+----------------------------------+------------------------------------------+----------+
| Hexen late demo v1.0 |    875885    | 458d3ff08d32fc50abb55a5b68660b6b | 0770db81c175f0470e7c61e54f0c8b7addb59d1c | 031d5117 |
+----------------------+--------------+----------------------------------+------------------------------------------+----------+
|   Hexen early v1.0   |    931829    | 08f08cad60c899cdce784c3adf6c5a6a | 8efd52454de3ca04e14e7ca6f6ac7d25bf7a1d69 | 92d2fd31 |
+----------------------+--------------+----------------------------------+------------------------------------------+----------+
|   Hexen late v1.0    |    931829    | 435fd8c4770edf31b62bebd64aae9332 | 4bc2504d53b06244a7c043bf9a4c7ccfcd87f066 | 32d27bdf |
+----------------------+--------------+----------------------------------+------------------------------------------+----------+
|   Hexen early v1.1   |    923019    | 713319e8adbc34bca8e06dbaff96f86c | b0b99b13a2d4f7987d1e918e2289deb9c421e561 | bbc55df2 |
+----------------------+--------------+----------------------------------+------------------------------------------+----------+
|   Hexen late v1.1    |    923019    | dfe619e8c6e3339359d62cda11e5375b | 049bb269018a79a090cb37171c554cfd89a1c42b | 741bb161 |
+----------------------+--------------+----------------------------------+------------------------------------------+----------+

I occasionally saw a hint about the existence of more than one demo version of Hexen, but I eventually found myself working just with the one which is currently covered.

What does help, at least when it comes to the Doom Wiki, is looking for exe names. Here is one example: https://doomwiki.org/wiki/HEXEN.EXE

It currently lists the two exes mentioned by you, albeit it links just to a ZIP file with the latter one in the idgames archive. There are also files named hexdemo1.zip...hexdemo4.zip, albeit given the common date of 10/13/96, I had a guess that these might actually contain another copy of the later demo exe.

I decided to start with one demo version for now, either way.

As for the beta, this is something that I've also had in my mind. Naturally, prototype builds can be even more of a gray area. As an exception, though, I did work on the March 1992 prototype build of Wolfenstein 3D. Reason being that it covers just the shareware episode, and it was probably leaked before the initial shareware release, so this was long enough.

As for Hexen, I assume that the beta was similarly out for a long while, just not sure how much; Either way, as long as only the exe is covered and no game data is needed, this might be ok.