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

ok, with checksums I'm now sure which versions you used, thanks

About Hexen/Heretic versions you can always ask me for example, I have enough information about them and all they I have (I hope). HeXen Retail Store Beta this is the full game version, has enough differences from 1.0 release, iwad also has differences in resources and a little on maps themselves. Reverse Store Beta exe will be the most difficult, as it seems to me, just like Shareware Demo v1, they are close in time.

One funny moment I found in HeXen Retail Store Beta version: demo loop mode in main menu is disabled in it, but 3 demos themselves are present in iwad and they are playback with desync on Store Beta. For a long time I thought that these demos were simply recorded on an earlier working version of the engine, but recently discovered - that these are still old Heretic 1.0 demos! Apparently Raven really loved these 3 demo files, have never changed them since Heretic 1.0, they almost got into Hexen release, heh

For completeness, the last exe version remains - this is HeXen95, this is a Windows port, we can say - another program, but it works with 1.1 iwad, but demos are in desync compared to 1.1 DOS engine, apparently there are some differences inside.

 

On 2 ноября 2020 г. at 1:10 AM, NY00123 said:

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.

Of course, I do it on one exe/port, but this engine is already a museum exhibit - this is beta Doomsday version by Jaakko Kerдnen from 2000. For example, a few years ago - I added support for all Hexen iwads, including 1.0, Shareware Demo v1,2 and Store Beta, I know that no one is interested in this and does not need, but this does not bother me much, because it's interesting to me, just a little hobby.
 

5 hours ago, PVS said:

 

Of course, I do it on one exe/port, but this engine is already a museum exhibit - this is beta Doomsday version by Jaakko Kerдnen from 2000. For example, a few years ago - I added support for all Hexen iwads, including 1.0, Shareware Demo v1,2 and Store Beta, I know that no one is interested in this and does not need, but this does not bother me much, because it's interesting to me, just a little hobby.
 

A Doomsday build that supporte all Hexen versions does interest me.

Is this the same build as the one that you released already?

Hi all,

I'll first add a little reminder that what I did with Hexen can't be easily done with Doom; Reason being that we got original DOS sources for Hexen (which turned out to match a later "v1.1" variant), while for Doom, we got linuxdoom-1.10.

On the other hand, I've added a new repository for Heretic. It may currently be found in the same location as beforehand (i.e., where apodmx and hexen are present).

As I wrote earlier, the open-source release of Heretic essentially matches version 1.3. What I did was recreating the code for version 1.2, which isn't very different from 1.3, and then also for shareware and registered v1.0. The latter two EXEs are again similar to each other. The most significant differences are between versions 1.0 and 1.2/1.3.

I also updated the apodmx repository, so you can now generate a library which is compatible with the Heretic sources as originally released. All I did was replacing the _dpmi_lockregion and _dpmi_unlockregion macros with equivalent functions.

Regarding Heretic, as of writing this, you can still find in P_PSPR.C, INFO.H and INFO.C recreated Phoenix functionality (including an mobj type) that I'm not sure what was its purpose. It's actually possible that it's unused in v1.0, thus explaining its later removal.

Another unused function in which ones may have interest, is the one which I called A_Flash for now. It's very similar in structure to A_Raise, and is the only one making use of weaponinfo_t's "flashstate" field. In practice, this field never differs from NULL in v1.0, so it's probably just another case of incomplete or removed functionality.

My setup of the scripts for the modified Heretic source tree may seem a little bit more convoluted. It basically turned out that the output of Watcom C, at least with version 9.5a and/or close enough, can be impacted by setting an environment variable which should otherwise not be related at all. Even without that, there's still the problem where the compiler inserts environment and/or source code dependent data between C string literals.

On the other hand, we're more lucky than in the case of Hexen v1.0 in one important manner: Assuming DMX is used, I could get the global variables to be ordered exactly as with the original EXEs. This means that their addresses matched the originals. Additionally, at least in my case, each generated binary wouldn't differ from the matching original one (minus the DOS/4GW loader) by more than 600 bytes.

Now, since there might be the ones interested in this, I attached builds that make use of the APODMX wrapper again. For GPL-related references, these are the commits on which it's based:
https://bitbucket.org/gamesrc-ver-recreation/audiolib/src/ad045a8d066d4f806b73b008afa134aabd3ac973/
https://bitbucket.org/gamesrc-ver-recreation/apodmx/src/848d85cd2015b7df0b3dbd26e3be3da429282786/
https://bitbucket.org/gamesrc-ver-recreation/heretic/src/b970a58325caad81fb520f8af247b670496f52f6/

23 hours ago, PVS said:

One funny moment I found in HeXen Retail Store Beta version: demo loop mode in main menu is disabled in it, but 3 demos themselves are present in iwad and they are playback with desync on Store Beta. For a long time I thought that these demos were simply recorded on an earlier working version of the engine, but recently discovered - that these are still old Heretic 1.0 demos! Apparently Raven really loved these 3 demo files, have never changed them since Heretic 1.0, they almost got into Hexen release, heh

Now, what you've written about the beta's demos is a very interesting find! I guess that it kinda makes sense, given that the demos would have to be replaced anyway if they were recorded earlier in development.

What about Shareware Heretic's demos, though? Versions 1.0 and 1.2 have the same demo files, and they don't seem to desync in 1.2 for me, at least not in a game breaking manner.

23 hours ago, PVS said:

Of course, I do it on one exe/port, but this engine is already a museum exhibit - this is beta Doomsday version by Jaakko Kerдnen from 2000. For example, a few years ago - I added support for all Hexen iwads, including 1.0, Shareware Demo v1,2 and Store Beta, I know that no one is interested in this and does not need, but this does not bother me much, because it's interesting to me, just a little hobby.

 

Well, looks like you're now using the recreated sources in order to extend the idea from the data to the code!

STRIPTIC_20201104.7Z

24 minutes ago, NY00123 said:

Regarding Heretic, as of writing this, you can still find in P_PSPR.C, INFO.H and INFO.C recreated Phoenix functionality (including an mobj type) that I'm not sure what was its purpose. It's actually possible that it's unused in v1.0, thus explaining its later removal.

I think they had planned to have the mummies, before they decided they were golems, to drop shredded wrappings when hurt -- kind of like how the chickens drop feathers.

My evidence for that are the SHRD sprites, which you can find in HERETIC.WAD between the MUMM sprites and the FX15 sprites. (MUMM being the sprites of the golems, and FX15 being the sprites of the nitrogolems' screaming flaming head projectiles; heavily implying the SHRD sprites were also for the same enemy.)

From your post it seems they also removed something from the Phoenix Rod?

Redneckerz
On the forum I attached jHeretic, jHexen is a separate project from him, at the moment I am not ready to show it. If you are interested in working with old Hexen iwads, then this part is already in my Chocolate version, you have this. Chocolate 2.3.0 is even better because can work on Win7 or even 10, while this old jHexen is limited only to XP. I remember that you collect old ports, if with this jHexen I'm ever be ready to show something - I'll do it.

NY00123
You did what I dreamed of for a long time, Heretic 1.0! Some time ago I already did everything I could for 1.0, everything that I could see visually, knowing the engine mechanics and it features, but this is not 100% enough. Now I have the opportunity try do it correctly and accurately, thank you very much, AGAIN! heh

At the moment I do not see your sources and which Heretic exe versions did you use, because to tell the truth - I can't never open your site from my old PC, I always ask a friend to download and send them to me. So, in a couple of days I will look at your sources and I will already be better oriented.

About Shareware Heretic's demos - that they seem to be played the same way on versions 1.0 and 1.2 is normal, they even playback on 1.3, but in fact - there are some differences, although they do not lead to desync.

The main difference between 1.0 and 1.3 is the FireMace weapon, that spawns on different slots on maps in these versions, plus - 1.0 on the remaining free slots will spawn monsters, 1.3 will not. I.e. we have a different monsters quantity on maps with FireMace on versions 1.0 and 1.3, if the player is not far from active area of the map, where there are such additional monsters in 1.0, this immediately takes demo to desync. Also, in 1.0 big FireMace ball can kill IronLich in one touch, like an ordinary monster, he is not a boss for FireMace in 1.0, in 1.3 IronLich is already a boss.

Shareware contains only the first episode, in which there are no FireMace weapon, so there are fewer problems. On maps without FireMace, also remains problem - different speed of changing player look up/down in 1.0 vs 1.3. I recorded enough test demos where on E1M1, E1M7 I actively used look up/down, shot monsters from different angles - this is enough for a demo recorded on 1.0 to go into desync on 1.3, and vice versa. As far as I remember, I also found other minor differences between 1.0 and 1.3, but something I could not be understand and find, now this is no longer a problem, everything will be visible in your sources, I hope.

P.S. I test again HeXen Retail Store Beta version today and saw that I was mistaken - demo loop mode in main menu is works in it, not disabled, and prerelease Hexen engine tries to play Heretic 1.0 demos, it turns out bad, heh
 

22 hours ago, Gez said:

I think they had planned to have the mummies, before they decided they were golems, to drop shredded wrappings when hurt -- kind of like how the chickens drop feathers.

 

My evidence for that are the SHRD sprites, which you can find in HERETIC.WAD between the MUMM sprites and the FX15 sprites. (MUMM being the sprites of the golems, and FX15 being the sprites of the nitrogolems' screaming flaming head projectiles; heavily implying the SHRD sprites were also for the same enemy.)

That's an interesting find. The SHRD sprites seem to be unused, even in v1.0.

22 hours ago, Gez said:

From your post it seems they also removed something from the Phoenix Rod?

 

It seems to be the case, at least in the code. Since I'm not that familiar with Heretic/Hexen terminologies (e.g., monsters' names) again - and more generally - I'm just not aware of the unused code's purposes, I can simply write what I currently have for v1.0 regarding the Phoenix and more.

P_PSPR.C: There are some code changes. P_RepositionMace was modified, and P_CloseWeapons also has in v1.0 code related to Maces; I'm wondering if these are the Firemace changes mentioned by PVS. There's the aforementioned function which I called A_Flash; And then, there's another unused function, which I called A_UnnamedPhoenixFunc, and it simply multiplies the actor's momz field by 2.

diff --git a/P_PSPR.C b/P_PSPR.C
index aa8da28..03847fc 100644
--- a/P_PSPR.C
+++ b/P_PSPR.C
@@ -259,16 +259,20 @@ void P_AddMaceSpot(mapthing_t *mthing)
 void P_RepositionMace(mobj_t *mo)
 {
 	int spot;
+#if (APPVER_HERETICREV >= AV_HR_TIC12)
 	subsector_t *ss;
 
 	P_UnsetThingPosition(mo);
+#endif
 	spot = P_Random()%MaceSpotCount;
 	mo->x = MaceSpots[spot].x;
 	mo->y = MaceSpots[spot].y;
+#if (APPVER_HERETICREV >= AV_HR_TIC12)
 	ss = R_PointInSubsector(mo->x, mo->y);
 	mo->z = mo->floorz = ss->sector->floorheight;
 	mo->ceilingz = ss->sector->ceilingheight;
 	P_SetThingPosition(mo);
+#endif
 }
 
 //---------------------------------------------------------------------------
@@ -282,17 +286,37 @@ void P_RepositionMace(mobj_t *mo)
 void P_CloseWeapons(void)
 {
 	int spot;
+#if (APPVER_HERETICREV < AV_HR_TIC12)
+	static mobjtype_t enemyType[] = { MT_WIZARD, MT_BEAST, MT_SNAKE };
+	int i;
+#endif
 
 	if(!MaceSpotCount)
 	{ // No maces placed
 		return;
 	}
+#if (APPVER_HERETICREV >= AV_HR_TIC12)
 	if(!deathmatch && P_Random() < 64)
 	{ // Sometimes doesn't show up if not in deathmatch
 		return;
 	}
+#endif
 	spot = P_Random()%MaceSpotCount;
+#if (APPVER_HERETICREV < AV_HR_TIC12)
+	if(!deathmatch && P_Random() < 64)
+		spot = -1;
+	for(i=0; i<MaceSpotCount; i++)
+		if (i == spot)
+			P_SpawnMobj(MaceSpots[spot].x, MaceSpots[spot].y, ONFLOORZ, MT_WMACE);
+		else if (!nomonsters)
+		{
+			int episode = gameepisode;
+			P_SpawnMobj(MaceSpots[i].x, MaceSpots[i].y, ONFLOORZ, enemyType[episode-1]);
+			totalkills++;
+		}
+#else
 	P_SpawnMobj(MaceSpots[spot].x, MaceSpots[spot].y, ONFLOORZ, MT_WMACE);
+#endif
 }
 
 //---------------------------------------------------------------------------
@@ -767,6 +791,23 @@ void A_Raise(player_t *player, pspdef_t *psp)
 	}
 }
 
+#if (APPVER_HERETICREV < AV_HR_TIC12) // VERSIONS RESTORATION: Unused function
+void A_Flash(player_t *player, pspdef_t *psp)
+{
+	P_SetMobjState(player->mo, S_PLAY_ATK2);
+	if(player->powers[pw_weaponlevel2])
+	{
+		P_SetPsprite(player, ps_flash,
+			wpnlev2info[player->readyweapon].flashstate);
+	}
+	else
+	{
+		P_SetPsprite(player, ps_flash,
+			wpnlev1info[player->readyweapon].flashstate);
+	}
+}
+#endif
+
 /*
 ===============
 =
@@ -1596,6 +1637,13 @@ void A_FirePhoenixPL1(player_t *player, pspdef_t *psp)
 	player->mo->momy += FixedMul(4*FRACUNIT, finesine[angle]);
 }
 
+#if (APPVER_HERETICREV < AV_HR_TIC12)
+void A_UnnamedPhoenixFunc(mobj_t *actor)
+{
+	actor->momz *= 2;
+}
+#endif
+
 //----------------------------------------------------------------------------
 //
 // PROC A_PhoenixPuff

INFO.H (v1.0):

- The following states are present right after S_PHOENIXFXI1_8: S_PHOENIXUNKNOWN1, S_PHOENIXUNKNOWN2, S_PHOENIXUNKNOWN3.

- S_PLAY_FDTH19 and S_PLAY_FDTH20 don't exist.

- The following mobj type is present right after MT_PHOENIXFX1: MT_PHOENIXUNKNOWN

INFO.C (v1.0): There's a full struct definition for MT_PHOENIXUNKNOWN and other differences in states, present here:

@@ -71,6 +71,9 @@ void A_InitPhoenixPL2 ();
 void A_FirePhoenixPL2 ();
 void A_ShutdownPhoenixPL2 ();
 void A_PhoenixPuff ();
+#if (APPVER_HERETICREV < AV_HR_TIC12)
+void A_UnnamedPhoenixFunc ();
+#endif
 void A_FlameEnd ();
 void A_FloatPuff ();
 void A_FireCrossbowPL1 ();
@@ -81,7 +84,9 @@ void A_NoBlocking ();
 void A_AddPlayerCorpse ();
 void A_SkullPop ();
 void A_FlameSnd ();
+#if (APPVER_HERETICREV >= AV_HR_TIC12)
 void A_CheckBurnGone ();
+#endif
 void A_CheckSkullFloor ();
 void A_CheckSkullDone ();
 void A_Feathers ();
@@ -639,6 +644,11 @@ state_t    states[NUMSTATES] = {
 {SPR_FX08,32773,4,NULL,S_PHOENIXFXI1_7,0,0},   // S_PHOENIXFXI1_6
 {SPR_FX08,32774,4,NULL,S_PHOENIXFXI1_8,0,0},   // S_PHOENIXFXI1_7
 {SPR_FX08,32775,4,NULL,S_NULL,0,0},    // S_PHOENIXFXI1_8
+#if (APPVER_HERETICREV < AV_HR_TIC12)
+{SPR_FX08,32776,8,NULL,S_PHOENIXUNKNOWN2,0,0}, // S_PHOENIXUNKNOWN1
+{SPR_FX08,32777,8,A_UnnamedPhoenixFunc,S_PHOENIXUNKNOWN2,0,0}, // S_PHOENIXUNKNOWN2
+{SPR_FX08,32778,8,NULL,S_NULL,0,0},    // S_PHOENIXUNKNOWN3
+#endif
 {SPR_FX04,1,4,NULL,S_PHOENIXPUFF2,0,0},        // S_PHOENIXPUFF1
 {SPR_FX04,2,4,NULL,S_PHOENIXPUFF3,0,0},        // S_PHOENIXPUFF2
 {SPR_FX04,3,4,NULL,S_PHOENIXPUFF4,0,0},        // S_PHOENIXPUFF3
@@ -758,9 +768,13 @@ state_t    states[NUMSTATES] = {
 {SPR_FDTH,32782,5,A_NoBlocking,S_PLAY_FDTH16,0,0},     // S_PLAY_FDTH15
 {SPR_FDTH,32783,4,NULL,S_PLAY_FDTH17,0,0},     // S_PLAY_FDTH16
 {SPR_FDTH,32784,5,NULL,S_PLAY_FDTH18,0,0},     // S_PLAY_FDTH17
+#if (APPVER_HERETICREV < AV_HR_TIC12)
+{SPR_FDTH,32785,4,NULL,0,0,0}, // S_PLAY_FDTH18
+#else
 {SPR_FDTH,32785,4,NULL,S_PLAY_FDTH19,0,0},     // S_PLAY_FDTH18
 {SPR_ACLO,4,35,A_CheckBurnGone,S_PLAY_FDTH19,0,0},     // S_PLAY_FDTH19
 {SPR_ACLO,4,8,NULL,S_NULL,0,0},        // S_PLAY_FDTH20
+#endif
 {SPR_BSKL,0,5,A_CheckSkullFloor,S_BLOODYSKULL2,0,0},   // S_BLOODYSKULL1
 {SPR_BSKL,1,5,A_CheckSkullFloor,S_BLOODYSKULL3,0,0},   // S_BLOODYSKULL2
 {SPR_BSKL,2,5,A_CheckSkullFloor,S_BLOODYSKULL4,0,0},   // S_BLOODYSKULL3
@@ -3703,6 +3717,35 @@ MF_NOBLOCKMAP|MF_MISSILE|MF_DROPOFF|MF_NOGRAVITY,                // flags
 MF2_THRUGHOST|MF2_NOTELEPORT           // flags2
  },
 
+#if (APPVER_HERETICREV < AV_HR_TIC12)
+{              // MT_PHOENIXUNKNOWN
+-1,            // doomednum
+S_PHOENIXUNKNOWN1,             // spawnstate
+1000,          // spawnhealth
+S_NULL,                // seestate
+sfx_None,              // seesound
+8,             // reactiontime
+sfx_None,              // attacksound
+S_NULL,                // painstate
+0,             // painchance
+sfx_None,              // painsound
+S_NULL,                // meleestate
+S_NULL,                // missilestate
+S_NULL,                // crashstate
+S_PHOENIXUNKNOWN3,             // deathstate
+S_NULL,                // xdeathstate
+sfx_None,              // deathsound
+0,             // speed
+2*FRACUNIT,            // radius
+4*FRACUNIT,            // height
+100,           // mass
+0,             // damage
+sfx_None,              // activesound
+MF_NOBLOCKMAP|MF_MISSILE|MF_DROPOFF|MF_NOGRAVITY,              // flags
+MF2_NOTELEPORT         // flags2
+ },
+#endif // APPVER_HERETICREV < AV_HR_TIC12
+
 {              // MT_PHOENIXPUFF
 -1,            // doomednum
 S_PHOENIXPUFF1,                // spawnstate

20 hours ago, PVS said:

NY00123
You did what I dreamed of for a long time, Heretic 1.0! Some time ago I already did everything I could for 1.0, everything that I could see visually, knowing the engine mechanics and it features, but this is not 100% enough. Now I have the opportunity try do it correctly and accurately, thank you very much, AGAIN! heh
 

You're welcome!

20 hours ago, PVS said:

At the moment I do not see your sources and which Heretic exe versions did you use, because to tell the truth - I can't never open your site from my old PC, I always ask a friend to download and send them to me. So, in a couple of days I will look at your sources and I will already be better oriented.
 

That's interesting. So you can't open Bitbucket from this PC? I'm wondering if you can run another browser, and/or use a git client to download the sources instead.

20 hours ago, PVS said:

About Shareware Heretic's demos - that they seem to be played the same way on versions 1.0 and 1.2 is normal, they even playback on 1.3, but in fact - there are some differences, although they do not lead to desync.

20 hours ago, PVS said:

On maps without FireMace, also remains problem - different speed of changing player look up/down in 1.0 vs 1.3. I recorded enough test demos where on E1M1, E1M7 I actively used look up/down, shot monsters from different angles - this is enough for a demo recorded on 1.0 to go into desync on 1.3, and vice versa.

One of the shareware demos indeed has an instance of looking up, so it's obviously impacted. I did spot these couple of differences between G_GAME.C and an older version of it, G_OLD.C. It was probably before figuring out that I could use G_OLD.C as a base for v1.0. I also used D_NETBAK.C instead of D_NET.C.

G_OLD.C (v1.0):

        if(lookheld < SLOWTURNTICS)
        {       
                lspeed = 3;
        }                       
        else
        {       
                lspeed = 5;
        }

G_GAME.C (v1.2/1.3):

        if(lookheld < SLOWTURNTICS)
        {       
                lspeed = 1;
        }
        else    
        {
                lspeed = 2;
        }

21 hours ago, PVS said:

Redneckerz
On the forum I attached jHeretic, jHexen is a separate project from him, at the moment I am not ready to show it. If you are interested in working with old Hexen iwads, then this part is already in my Chocolate version, you have this. Chocolate 2.3.0 is even better because can work on Win7 or even 10, while this old jHexen is limited only to XP. I remember that you collect old ports, if with this jHexen I'm ever be ready to show something - I'll do it.

Aha, i see :) Perfect, no worries :) I should get around giving your work more coverage anyway. Thanks!

NY00123
My PC is much older than you might think, but this is my problem, not worth attention, I got the sources and looked at them a bit.

About FireMace changes - yes, P_CloseWeapons and P_RepositionMace this is the main place, now I see - I almost guessed the old code, only where Raven need one line - I need three, heh. Look up/down - you showed the first part, there is also the second one, where multiplier was used, i.e. the difference in speed is not in 3 times, as can be seen from this part, it is less.

Already noticed one difference in the mechanics that I could not detect earlier - from 1.2 blocked possibility for air monsters to fly one above the other, when this will happens in game it will certainly lead to desync, because monsters will move differently, but it's really difficult to notice this visually, from gameplay. In general, I have a lot of interesting work ahead.

Found one more interesting moment - v1.2 knows Shadow of the Serpent Riders iwad! I have thought that NY00123 mistakens, but not, tested itself - 1.2 really can work with 5 episodes iwad, knows E6M1-E6M3, knows map names in 4,5 episodes. Earlier I thought that with big iwad can work only 1.3 engine. Version 1.2 - June 1995, 1.3 - March 1996, how this happened, anyone know? We can expect that Raven something planned, but seems to me - that 4,5 episodes be ready in June 1995, but released in March 1996.

Also, the earliest version of Heretic remains:
052F82FECE58FA38DB40713CBBCC675D (3-level beta release, 1994/12/20).

Must be close to Shareware 1.0, but can contain old code, maybe. Shareware 1.2 = Rigistered 1.2, as far as I know.
 

On 11/7/2020 at 2:17 AM, PVS said:

Found one more interesting moment - v1.2 knows Shadow of the Serpent Riders iwad! I have thought that NY00123 mistakens, but not, tested itself - 1.2 really can work with 5 episodes iwad, knows E6M1-E6M3, knows map names in 4,5 episodes. Earlier I thought that with big iwad can work only 1.3 engine. Version 1.2 - June 1995, 1.3 - March 1996, how this happened, anyone know? We can expect that Raven something planned, but seems to me - that 4,5 episodes be ready in June 1995, but released in March 1996.
 

Yeah, I noticed this as well while working on the code. I already found the the original EXEs to share a common file size, which was a very great hint, albeit I didn't think about episodes 4-5 as much; Then again, I'm not sufficiently familiar with Heretic to fully remember which EXEs were or weren't distributed with Shadow of the Serpent Riders.

Since the added episodes didn't introduce new weapons or monsters, maybe almost all coding was done before a great deal of the mapping for episodes 4-5 was being conducted.

To compare, following Doom Wiki pages, The Ultimate Doom was released on April 30, 1995, albeit its (most recent?) EXE was actually date-stamped 1995-05-25. I'm not sure what happened here. Either way - assuming this wasn't known in Raven beforehand - chances are that the release of The Ultimate Doom convinced them to similarly add more to Heretic, thus leading to the additional code in v1.2's EXE.

Other than a really small amount of differences related to the addition of episode 4-5, v1.3 added to P_MAP.C a few pieces of code related to missiles.

On 11/7/2020 at 2:17 AM, PVS said:

Also, the earliest version of Heretic remains:
052F82FECE58FA38DB40713CBBCC675D (3-level beta release, 1994/12/20).

Must be close to Shareware 1.0, but can contain old code, maybe. Shareware 1.2 = Rigistered 1.2, as far as I know.

ok, so while I'm careful of making any promise as usual, I'm wondering which Heretic and Hexen executables are known?

Ignoring Hexen95, these are the versions that I'm currently aware of:

Heretic:

- 3-level Shareware beta (1994-12-20)

- Shareware v1.0

- Registered v1.0

- Shareware/Registered v1.2 (same exe)

- Shadow of the Serpent Riders v1.3

Hexen:

- Retail store beta (1995-09-26)

- 4-level demo beta (1995-10-02)

- v1.0 (1995-10-13)

- v1.0 with added i_CDMusic check in P_SetupLevel (1995-10-15, but with VERSIONTEXT still defined to "FINAL 1.0 (10 13 95)")

- Demo v1.0 (1995-10-18, but with VERSIONTEXT defined to "DEMO 10 16 95")

- v1.1 (1996-03-12)

- v1.1 with A_SoAExplode fix (1996-03-22)

Your versions list for Heretic/Hexen is correct, at least - these are all versions that I known and have. I gave examples of missing versions just because you asked for it earlier, not for invite you to work on them. You yourself know better - whether you are interested in it or not, especially since a few people are interested in these games, there is a small feedback. You have already made all the main and interesting versions and even less significant ones, I did not even hope that this would ever happen. To tell the truth, earlier I tried reverse myself and more than once, but it is closer to assembler and difficult for me.

Tested a bit your DOS version Heretic 1.0 on my old real hardware, everything works well, I don't see any problems. About SFX and midi music playback - the situation is very similar to your recreated HeXen exe: the SFX volume is about 1/3 lower and rarely, but there are some oddities, the SFX sounds are repeated 2 times, the midi music volume is about 2/3 lower. Maybe you tested your versions in action, on dosbox? I wonder what result you have, when compared to the original exe. I understand that this happens with sound due to the lack of a licensed DMX library.

Also, an interesting moment, I see that P_CloseWeapons() in Heretic 1.0 contains an error, memory is most likely damaged there when engine tries to load E4M1, but function is designed for 3 episodes. Due to this error, on E4M1 on the remaining free FireMace slots - engine spawns 'Shadowsphere/invisibility' artifact instead of monsters, it's just a coincidence that the engine doesn't crash, I think it depends on the EXE layout itself. I take old P_CloseWeapons() and compile test Chocolate release build, in Heretic 1.0 mode (what I additionally have) - it crash silently when tries to load E4M1, debug build not crash, but spawn 'little health', not Shadowsphere. StripTic.exe works like original - not crash and spawn Shadowsphere on E4M1, I think it means that you are close or have reached your goal, only DMX doesn't let you reach the original EXE layout.

Heretic (just like old Doom versions) contains another broken function - P_FindNextHighestFloor(), reproduce the memory damage that may occur there - it seems to me impossible in source ports. Some time ago I tested this a lot, recorded many test demos, there is very interesting behavior on Heretic 1.3, always different depending from OS environment. This is the second way check recreated StripTic versions from the practical side, but I'm pretty sure - they will match the original EXE layout and behavior, heh

Some information about differences between versions, if anyone has not seen and interested:
Heretic/Hexen series: https://tcrf.net/Category:Heretic/Hexen_series

Heretic 3-level beta: https://tcrf.net/Proto:Heretic

Heretic v1.0 - v1.3: https://tcrf.net/Heretic

HeXen Retail Store Beta: https://tcrf.net/Proto:Hexen_(DOS)/Near-Final_Beta
 

I'll first begin with a small bit which I forgot to mention earlier. When you made the October 30 reply following my post about additional Hexen versions, it was more-or-less when Hexen turned 25 (counting from the day of initial release).

On 11/14/2020 at 3:15 AM, PVS said:

Tested a bit your DOS version Heretic 1.0 on my old real hardware, everything works well, I don't see any problems. About SFX and midi music playback - the situation is very similar to your recreated HeXen exe: the SFX volume is about 1/3 lower and rarely, but there are some oddities, the SFX sounds are repeated 2 times, the midi music volume is about 2/3 lower. Maybe you tested your versions in action, on dosbox? I wonder what result you have, when compared to the original exe. I understand that this happens with sound due to the lack of a licensed DMX library.

I checked at least one of the builds in DOSBox. It looks like another instance of the side-effects of using the Apogee Sound System instead of DMX. I recall briefly checking if I can adjust one of the volumes, but IIRC it reached the maximum. Unsure about the details, because the sound and music volumes can be controlled independently of each other, but this is what I recall.

On 11/14/2020 at 3:15 AM, PVS said:

Also, an interesting moment, I see that P_CloseWeapons() in Heretic 1.0 contains an error, memory is most likely damaged there when engine tries to load E4M1, but function is designed for 3 episodes. Due to this error, on E4M1 on the remaining free FireMace slots - engine spawns 'Shadowsphere/invisibility' artifact instead of monsters, it's just a coincidence that the engine doesn't crash, I think it depends on the EXE layout itself. I take old P_CloseWeapons() and compile test Chocolate release build, in Heretic 1.0 mode (what I additionally have) - it crash silently when tries to load E4M1, debug build not crash, but spawn 'little health', not Shadowsphere. StripTic.exe works like original - not crash and spawn Shadowsphere on E4M1, I think it means that you are close or have reached your goal, only DMX doesn't let you reach the original EXE layout.

It might just be a lucky coincidence that STRIPTIC.EXE v1.0 didn't crash in your case. Generally, the global functions and variables present in the Heretic code base itself should be ordered in mostly the same manner with or without DMX, but there can be a greater impact, depending on various factors.

I write "mostly", since if you replace even the original DMX.H header with an alternative, this can impact the order of global variables in OBJ files, due to the way the compiler works.

On a side-note, I'm not even sure where to host this, so I'll just attach the file here.

Basically, at some point, I decided to try and replicate the older behaviors of Hexen's A_SoAExplode function (i.e., reproducing the -nomonsters bug), but with modified ZScript code for GZDoom.

I otherwise have no practical experience with ZScript at all; This is technically my first released ZScript (more like a modification), so the way it's packaged can be wrong in any way, but I'm still attaching it.

hex11a.pk3.zip

Yes, October 30th was the official 25th HeXen birthday, but you know, for me it's October 2 and December 20 for Heretic, when the demo versions were published and the first Heretic/HeXen guys appeared, heh. I don't know exactly the story with HeXen Retail Store Beta, I found it much later and I have it just because of my interest.

I have corrected and supplemented Heretic 1.0 mode in my hobby project, in accordance with your sources. Immediately was able to playback all my problem 1.0 demos, everything works well at the moment. This is no longer emulation, now it can be called 'compatibility', which is good, also added compatibility with 1.0 save game files. I am writing this on purpose so that you know that your work is useful to someone.

I wonder what are you planning next? As far as I understand, through HeXen/Heretic you want to get closer to the old Doom exe versions?
 

On 12/10/2020 at 1:53 AM, PVS said:

I have corrected and supplemented Heretic 1.0 mode in my hobby project, in accordance with your sources. Immediately was able to playback all my problem 1.0 demos, everything works well at the moment. This is no longer emulation, now it can be called 'compatibility', which is good, also added compatibility with 1.0 save game files. I am writing this on purpose so that you know that your work is useful to someone.

It's great to see that the recreated Heretic 1.0 sources have already become useful for someone.

I wonder what are you planning next? As far as I understand, through HeXen/Heretic you want to get closer to the old Doom exe versions?

The way it's usually done, I prefer to not write much before I finish working on something, or at least get sufficiently close to such a state.

As previously mentioned, doing the work covering Heretic and Hexen, but for Doom, is expected to be significantly more difficult, due to the lack of original DOS sources.

There's also the question of DMX; So far I could use (for the purpose of creating EXEs) very specific versions of DMX header and library files, which turned out to be the same for all currently covered versions of Heretic and Hexen.

At some point, I got word from Hendricks266 that Jaguar Doom might be a good reference. It is reportedly based on Doom v1.2, which Heretic is apparently also based on: https://doomwiki.org/wiki/Versions_of_Doom_and_Doom_II

What Nuke.YKT remembered at the time is Linux Doom's headers being quite different. This can greatly have an impact on restoration efforts; Especially if you also want to get global variables (at least the ones in the BSS and not assigned specific values) to be ordered as expected. I didn't even get that sufficiently close with the older Hexen versions, albeit with the help of a script, I could at least find out that the recreated EXEs are still more-or-less the same as the originals, ignoring the order of variables.

Back to Linux Doom's differing headers, consider DOOMDEF.H. It was originally larger, something which be observed by inspecting the Heretic and Jaguar Doom sources:

https://github.com/OpenSourcedGames/Heretic/blob/1f4d3de8d639d62d52e7383f01acc1e81fc1b7f9/Heretic Source/DOOMDEF.H

https://github.com/Arc0re/jaguardoom/blob/392d665438909aab8b8e28852a86f68c1797d619/doomdef.h

For Linux Doom, a great deal of DOOMDEF.H's contents was moved out of it: https://github.com/id-Software/DOOM/blob/4eb368a960647c8cc82d721d0183629ae10759d1/linuxdoom-1.10/doomdef.h

As far as I understand, the situation with old Doom code is more complicated than with Heretic/Hexen, because for me it's on the contrary - you know Doom better than me, heh. Doom has more fans, players and developers and old versions code still is not interesting to anyone, this is strange for me.

About your Heretic work. From the beginning I noticed in your sources that in 1.3 there are some additional checks for missiles, but only now I figured out about one moment (or maybe the only one) - why this was done, because this CheckMissileImpact() calls leads deeper and deeper in code. In 1.3 changed the behavior for the gun-switches: in 1.0/1.2 such switches could only be activated with 1,2,4 weapons (like in Doom?), but in 1.3 all Heretic's weapons can switch such gun-switches, so they needed these additional missile checks for 3,5,6,7 weapons. I don't know if you are interested in this information or not, but for me it means - that 1.2 is mechanically different from 1.3 and now I also have 1.2 compat mode, heh

But I was interested - why was it needed? Checked iwad and found that Gun-switches (action 24,46,47) used only in E4M5, E4M8, E4M9, E5M6, E5M7 maps, these are additional 4,5 episodes and it immediately became clear why it appeared in version 1.3. Also found a bad moment - now these switches can be triggered even through closed doors/walls if the distance to them is small, most likely it depends from missiles size of the 3,5,6,7 weapons.

Hey there,

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.

Following preceding interest, I'm attaching an archive with a build. As with the other builds, it's using APODMX, so expect it to sound different from the original. As usual, the actual Hexen code should still match, more-or-less. Given the use of GPLed code, I'll reference the relevant revisions again:

https://bitbucket.org/gamesrc-ver-recreation/audiolib/src/ad045a8d066d4f806b73b008afa134aabd3ac973/
https://bitbucket.org/gamesrc-ver-recreation/apodmx/src/848d85cd2015b7df0b3dbd26e3be3da429282786/
https://bitbucket.org/gamesrc-ver-recreation/hexen/src/a53dad15370b86de58cabed95b80589a46b7c50b/

STRIPHEX_20210509.7Z

So, it's possible that anybody who tries to cover all versions from a single EXE might find it difficult to do so at this point.

That is, unless you go for what I did in Reflection Wolfenstein 3D, as it more-or-less covers separate builds of different game versions in a single exe.

As of this post, the following additions are now in:

- 3-level shareware beta of Heretic (Dec 20 1994).

- Retail store beta of Hexen (Sep 26 1995).

These will probably be the last additions related to Heretic and Hexen. As usual, there's no promise regarding any future endeavor.

To summarize, we ended with 5 distinct DOS builds of Heretic, and 7 of Hexen.

As I suspected, it still took significantly more time to work on the beta release of the 4-level Hexen demo (given preceding work on v1.0 and the demo re-release), compared to the work on the aforementioned two betas of Heretic and Hexen.

In certain technical manners, the two Hexen betas might be close, even if obviously not identical. The aforementioned removed fly code is the same, just for one example.

I did have issues with the generated layouts of the following functions in the Hexen betas again: A_Quake, P_XYMovement and P_ZMovement. As mentioned earlier, the latter's C code was actually not changed by me at all.

In the case of Heretic, I suddenly spotted a different layout for M_FindResponseFile in a recent build of 1.2. I did it see beforehand, also in Hexen, but I thought that it was not reproduced after I finished working on each of the differing Heretic versions, excluding the beta. At the least, the code size, including padding for alignment, remained the same, so the other functions did match in layouts and locations.

To finish, I've attached an archive consisting of new builds of all covered versions, again using the Apogee Sound System wrapper instead of DMX.

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

https://bitbucket.org/gamesrc-ver-recreation/heretic/src/9e456d7e201aee5f067314c2c44fa6ca57ced83f/

https://bitbucket.org/gamesrc-ver-recreation/hexen/src/1847583de60fdfe66476c30746740f0a6aa11dca/

STRIPTICHEX_20210521.7Z

Tested your latest HeXen Demo-1, Retail Beta and Heretic beta exe's vs original versions: savegame's format compatible, some of my test demos playback fine, some details about beta versions, which I know only from practice and see them visually - are reproduced on your binaries. In my opinion, everything worked well! as usual, heh

Not sure if I understood correctly about A_Quake, P_XYMovement and P_ZMovement functions - you doubt, what got their code correctly? Also, I never knew about this fly (although it doesn't look like a fly, heh) in HeXen beta, it's interesting and even funny, but this fly is really hard to notice, from all 5 hubs in beta iwad - she sits only in one place, at the end of map 13. I remember, that on this map in my current beta compatibility mode - I block one unknown thing type 112, but it turns out to be - a fly!

You returned all Heretic/HeXen code versions, I didn't even hope for this, as usual - thank you very much, from me! I have a lot of interesting work ahead.

P.S. Not so long ago, probably just for nostalgia - I launched my old Kali client on old PC, and there, on the #descent channel I saw a person with NY00123 nickname, if it was you - maybe we'll meet again there, heh

I'll first begin with a small bit that I forgot to mention earlier: The versions which I previously named HEXDM10A and HEXDM10B in the hexen repository were renamed HEXDEMOA and HEXDEMOB, respectively. The retail store beta is identified as HEXRBETA, and the 3-level shareware demo of Heretic is TICSBETA. The rest remain unchanged.

19 hours ago, PVS said:

Tested your latest HeXen Demo-1, Retail Beta and Heretic beta exe's vs original versions: savegame's format compatible, some of my test demos playback fine, some details about beta versions, which I know only from practice and see them visually - are reproduced on your binaries. In my opinion, everything worked well! as usual, heh

Great to see that all of these worked as expected! Thanks for testing. Now, if anything differs in behaviors, on the other hand...

Well, as there are differences in the recreated EXE (like global variables having a different order), this is expected, especially in cases where the exact EXE layout matters, like buffer overflows.

Not sure if I understood correctly about A_Quake, P_XYMovement and P_ZMovement functions - you doubt, what got their code correctly? Also, I never knew about this fly (although it doesn't look like a fly, heh) in HeXen beta, it's interesting and even funny, but this fly is really hard to notice, from all 5 hubs in beta iwad - she sits only in one place, at the end of map 13. I remember, that on this map in my current beta compatibility mode - I block one unknown thing type 112, but it turns out to be - a fly!

What I mean with these 3 functions is that you'll find differences if you make your own exe (even with DMX), and then compare the generated code to the original, side-by-side; Maybe these differences don't have an impact on the functions' behaviors, but this is still what I saw.

Regarding the fly, while it might be missing from the early demo's maps, you can still find code and data for it, including sprite graphics. However, as they're quite small (around 2x2 pixels), it can be easy to mistake them for placeholders. In particular, I assumed that there are larger sprites in the retail store beta, but it doesn't seem to be the case.

Of course, this assumes that the sprites were actually intended for use, and weren't placeholders. One thing I can say for sure, is that the small size of them can make it difficult to view them in certain programs, since they can make the sprite images look blurry.

You returned all Heretic/HeXen code versions, I didn't even hope for this, as usual - thank you very much, from me! I have a lot of interesting work ahead.

You're welcome! I can probably wish you good luck with your endeavor, heh.

P.S. Not so long ago, probably just for nostalgia - I launched my old Kali client on old PC, and there, on the #descent channel I saw a person with NY00123 nickname, if it was you - maybe we'll meet again there, heh

That's interesting. I don't recall myself using Kali.net in the last 10 years, and especially not staying in a descent channel. It was probably about 20 years ago when I tried to use it for Duke Nukem 3D, in a kind of a demo/trial mode. All that I remember is one attempt to join a session, for which a game launch probably failed, heh.

Hmm, maybe I was wrong with nickname in Kali, I'll check later. Since 2013 possible use Kali freely, server is still running, if you have old PC and OS - go ahead! heh

NY00123
Stupid question: in Heretic/Hexen demo recording is limited in 128K, in G_RecordDemo hardcoded demobuffer as 0x20000 size. I'm wondering - it is possible to find this hex value in exe and increase it? I'm looking for an easy way to increase the recording time for DOS exe, unsuccessful at the moment, heh

About Hexen -nomonsters mode, what we talked in demo topic. Under "IWAD maps not have normal -nomonsters" I meant - that this is not a problem of Hexen engine, as in Doom/Heretic, this is a map design problem, i.e. only the map authors. In Hexen possible provide -nomonsters support very simply - through ACS scripts, even not need modify map in the editor, but the author must take care about this, what didn't happen for IWAD maps.

If you are interested - look at this small example: one room, one monster and a closed exit. Monster (Ettin) contain a special action - lower the floor (open the exit), which is executed when he dies. In normal game you kill this monster, he executed its special action and you can exit from map. I'm care about -nomonsters on skill 1-3, but ignore it on purpose for skill 4-5, to simulate the situation, as it sometimes happens on IWAD maps. With -nomonsters on skill 1-3 - you can exit from this map, on skill 4-5 - your fate is stuck here forever, heh
 

HexNoMo.zip

On 11/27/2021 at 2:22 AM, PVS said:

NY00123
Stupid question: in Heretic/Hexen demo recording is limited in 128K, in G_RecordDemo hardcoded demobuffer as 0x20000 size. I'm wondering - it is possible to find this hex value in exe and increase it? I'm looking for an easy way to increase the recording time for DOS exe, unsuccessful at the moment, heh
 

HexNoMo.zip

This depends on the version of the exe in question. For Heretic v1.3 you should look for the following sequence of bytes, beginning at address 0x4c227 of the original exe file:

B8 00 00 02 00 E8 83 E4 01 00

Here, it's the number "00 00 02 00" which should be patched. I haven't tested it, but by inspecting a disassembly of the EXE, it seems to make sense.

There's only just one mention of the string "B8 00 00 02 00" in the exe. While again untested, since the calling convention should be the same, I expect "B8 00 00 02 00" to still have relevance in the other exes; It's an instruction to write the number 0x20000 to the register eax.

On 11/27/2021 at 2:22 AM, PVS said:

About Hexen -nomonsters mode, what we talked in demo topic. Under "IWAD maps not have normal -nomonsters" I meant - that this is not a problem of Hexen engine, as in Doom/Heretic, this is a map design problem, i.e. only the map authors. In Hexen possible provide -nomonsters support very simply - through ACS scripts, even not need modify map in the editor, but the author must take care about this, what didn't happen for IWAD maps.

If you are interested - look at this small example: one room, one monster and a closed exit. Monster (Ettin) contain a special action - lower the floor (open the exit), which is executed when he dies. In normal game you kill this monster, he executed its special action and you can exit from map. I'm care about -nomonsters on skill 1-3, but ignore it on purpose for skill 4-5, to simulate the situation, as it sometimes happens on IWAD maps. With -nomonsters on skill 1-3 - you can exit from this map, on skill 4-5 - your fate is stuck here forever, heh
 

HexNoMo.zip

To see if I understand this correctly, do you mean that you can make it impossible to complete a map with -nomonsters just by changing an ACS script, or alternatively, that this already applies to original IWAD maps due to the IWAD's ACS code?

I knew that you would solve this question, thanks for watching and helped! Sometimes I record test demos on the original exe's and always suffer, because often, this 10 minutes limit is not enough to reproduce all details and behaviors which I need. At the moment I need this for Hexen Retail Beta, where I found this demobuffer on offset 587BA, 02 replaced by 0F, which will be about 960K or ~1h20m (if I'm not mistaken), which is more than enough. Recorded 2 demos in 30 and 40 minutes long, everything works fine, heh.

About Hexen -nomonsters: I was hoping that you would understand my example, but maybe - this is a little deep in Hexen mapping. I tried to say, what to make the normal -nomonsters mode in Hexen - it was necessary to spend additional time on this task when developing the maps themselves, which was not done in IWAD maps. I also did not see this in pwads, many of which are also not possible to finish in -nomonsters mode. But this is easy enough, which I tried to show with this small example.

Small sneak peek

Another one

8 hours ago, nukeykt said:

Another one

Looking good! :)

Having some updates, both major and minor.

- Thanks to Nuke.YKT's efforts, Doom and Strife are now both covered. He used the Heretic sources and other sources in order to transform Linux Doom into faithful Final Doom DOS sources. I added older Doom versions to the tree, and occasionally also assisted with Strife a bit, here and there. He created a separate thread covering Doom and Strife. See the bottom of this post for a link.

- Nuke.YKT further updated the apodmx repository, i.e., his DMX wrapper that uses the Apogee Sound System. This technically impacts not just Doom or Strife, but also Heretic and Hexen.

- Ken Silverman figured out how was Ken-Build's GAME.EXE (probably) built from the sources as uploaded in November 2002. So, while the code was there beforehand, I added it as an option to the BAT files and make file.

- For a few exes that can be built from the duke3d tree, 3 bytes would differ before adding these linker directives: "segment type code lo", "segment type data lo". As it recently turned out, an alternative fix was the simple removal of the directive "system dos4g".

Additionally, Nuke.YKT is now a part of gamesrc-ver-recreation.

There might still be restrictions on what's uploaded to gamesrc-ver-recreation. For instance, a reversed engineered game is generally not covered. Exceptions are still a possibility. For instance, after Blake Stone: Planet Strike was open-sourced by Apogee, it was stated that the Aliens of Gold sources were assumed to be lost, thus explaining their lack. Therefore, I didn't mind building upon Blzut3's earlier reverse-engineering efforts, and later uploading reconstructed sources for the game.

On 1/29/2022 at 1:55 PM, NY00123 said:

Having some updates, both major and minor.

 

- Thanks to Nuke.YKT's efforts, Doom and Strife are now both covered. He used the Heretic sources and other sources in order to transform Linux Doom into faithful Final Doom DOS sources. I added older Doom versions to the tree, and occasionally also assisted with Strife a bit, here and there. He created a separate thread covering Doom and Strife. See the bottom of this post for a link.

I'd have to comment there. Recreating Doom through the source blows my mind.

On 1/29/2022 at 1:55 PM, NY00123 said:

- Nuke.YKT further updated the apodmx repository, i.e., his DMX wrapper that uses the Apogee Sound System. This technically impacts not just Doom or Strife, but also Heretic and Hexen.

I had no idea that there was a wrapper module for the DMX, utilizing ASS. That's magnificent

On 1/29/2022 at 1:55 PM, NY00123 said:

- Ken Silverman figured out how to recreate Ken-Build's GAME.EXE as uploaded in November 2002. So, I added it as an option.

I'd love to hear some elaboration on that. What is this used for?

I am also surprised Awesoken didn't mention this himself. That is quite a feat in either case.

On 2/1/2022 at 2:20 PM, Redneckerz said:

I had no idea that there was a wrapper module for the DMX, utilizing ASS. That's magnificent

Yeah, it has been out for quite a while. I originally added it to gamesrc-ver-recreation as an option for Hexen; This is why you can find in this thread earlier posts referring to differences in sound/music output.

Nuke.YKT used it for PCDoom beforehand; He actually tested it with Heretic first. What I eventually did was reconfiguring it as a partially standalone static library, and also applying a few minor fixes. The linker still needs the Apogee Sound System, i.e., AUDIO_WF.LIB.

On 2/1/2022 at 2:20 PM, Redneckerz said:

I'd love to hear some elaboration on that. What is this used for?

 

I am also surprised Awesoken didn't mention this himself. That is quite a feat in either case.

 

I've edited my post to clarify the point on Ken-Build. Basically, while the Build Engine and the Ken-Build test game were originally open-sourced by Ken in June 2000, if you download the archive today, you should find really minor updates to GAME.C and BUILD.C. The updates also explain the timestamp of November 2002 for GAME.EXE.

In spite of the timestamps making it clear the exe was indeed matching the sources, I didn't exactly figure out how to appropriately build the exe. This is what Ken did, following private communication involving both of us.

Unless you count his website, I'm not currently aware of him being active in anything like a community for gaming; Before they were shut down, he used to post in JonoF's forums. These were eventually closed due to getting a great deal of automated spam, along with having relatively small user activity.

On 2/2/2022 at 6:16 PM, NY00123 said:

I've edited my post to clarify the point on Ken-Build. Basically, while the Build Engine and the Ken-Build test game were originally open-sourced by Ken in June 2000, if you download the archive today, you should find really minor updates to GAME.C and BUILD.C. The updates also explain the timestamp of November 2002 for GAME.EXE.

 

In spite of the timestamps making it clear the exe was indeed matching the sources, I didn't exactly figure out how to appropriately build the exe. This is what Ken did, following private communication involving both of us.

So similarly to the recreated Doom/Heretic/Hexen sources, this would be an educational tool first and formost?

As a sidenote, its great that Ken chipped in for this - As notorious of a programmer as he was, the guy is a great tutor (and has done so on many occassions as his website shows).

On 2/2/2022 at 6:16 PM, NY00123 said:

Unless you count his website, I'm not currently aware of him being active in anything like a community for gaming; Before they were shut down, he used to post in JonoF's forums. These were eventually closed due to getting a great deal of automated spam, along with having relatively small user activity.

Perhaps Duke4 itself could be an alternative. Though Ken is probably too busy with his Voxon work and his own private muckings to consider such, ofcourse.

I wonder what he thinks about Ion Fury, or The AMC Team or the Raze port.

Am I doing something wrong or is APODMX still a bit disappointing?  I got the Heretic source as released by Raven to compile using it (with only minor tweaks to get the compilation process to go through) but the music output isn't great.  I get that replicating the exact timbres might be hard but it seems to drop notes in some tracks and doesn't appear to work with any sound card setting besides "AdLib".