Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
NY00123

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

Recommended Posts

2 hours ago, ETTiNGRiNDER said:

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".

 

Last I checked, the music (via Adlib or Sound Blaster) does sound at least somewhat different, including also the volumes. Looking at the apodmx code, it seems to support Adlib, SB, MPU 401 and GUS?

 

For sound effects, apodmx appears to support SB and GUS, and at least for Doom, also the PC Speaker. The latter won't work with Apogee Sound System v1.1 or later, which explains why I chose 1.09 at the time.

 

More information can be found in recent posts of Nuke.YKT from the thread about Doom and Strife to which I linked. One major difference

is that DMX internally uses MUS, while the Apogee Sound System rather uses MIDI. Format conversions are supported up to differing extents.

 

3 hours ago, Redneckerz said:

 

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).

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.

 

For now gamesrc-ver-recreation/build is indeed similar to the other trees, in terms of documenting behaviors matching other versions (or at least attempts to do so) and possibly making these useful for source ports.

 

There's surely a lot which is covered by Ken's website.

 

If I'm not wrong, then at some point, Ken lost interest in checking (new) games, due to other engine developers still being in the industry and working on evolving tech.

 

I'm not sure he's following differing projects involving the Build Engine. I've found a quote of him here: https://steamcommunity.com/app/562860/discussions/0/1694914735993224533/

 

Re-quoting just in case:

 

Quote

"-I had to Google "Ion Maiden" to realize that this was a game being made by Voidpoint. Last year, I negotiated a contract with Voidpoint about using the Build Engine. As for the game itself, I know nothing about it, other than the fact that they are probably using a highly modified version of the Build Engine."
-Ken Silverman, 2018

Share this post


Link to post
On 2/6/2022 at 8:20 PM, Redneckerz said:

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

 

Got an update from TerminX, who heard the following from Ken. From what I was told, he liked Ion Fury, and even found a place where a familiar error from Duke Nukem 3D: Atomic Edition was reproduced:

 Too many sprites spawned.

 

Share this post


Link to post
On 2/6/2022 at 11:35 PM, NY00123 said:

For now gamesrc-ver-recreation/build is indeed similar to the other trees, in terms of documenting behaviors matching other versions (or at least attempts to do so) and possibly making these useful for source ports.

Would this help projects that now are standalone using EDuke32?

On 2/6/2022 at 11:35 PM, NY00123 said:

Re-quoting just in case:

Ken's tech goes places, with Ion Fury's Fury Engine :)

 

4 hours ago, NY00123 said:

 

Got an update from TerminX, who heard the following from Ken. From what I was told, he liked Ion Fury, and even found a place where a familiar error from Duke Nukem 3D: Atomic Edition was reproduced:


 Too many sprites spawned.

 

Looks like Ion Fury pays respect to the Duke in more than one way :) Good to know he likes the tech - A Build Engine game is instantly recognizable, in the same vein one could spot a Doom engine game from a mile away.

Share this post


Link to post
16 hours ago, Redneckerz said:

Would this help projects that now are standalone using EDuke32?

 

I wonder what do you refer to when writing standalone - I guess that not projects like Ion Fury or The AMC Squad, but rather separate game modules like Rednukem or NBlood?

 

I do know that reconstructed Build Engine code (even if not in gamesrc-ver-recreation at the time) assisted for compatibility when behaviors could be game-impacting, say clipping. EDuke32's revision of the Build Engine has separate versions of functions, like clipmove_compat, and a variable named enginecompatibilitymode is used for selecting the exact functions in use. There are also other behaviors which are changed, based on this variable.

 

Different values of enginecompatibilitymode are used not just for Rednukem, NBlood or PCExhumed, but also for VoidSW.

 

Albeit maybe not what you originally asked for, in terms of Duke3D game code, I know that certain bits in gamesrc-ver-recreation/duke3d helped fixing errors in EDuke32 game code specific to NAM and WW2GI.

 

16 hours ago, Redneckerz said:

Looks like Ion Fury pays respect to the Duke in more than one way :) Good to know he likes the tech - A Build Engine game is instantly recognizable, in the same vein one could spot a Doom engine game from a mile away.

 

This might depend on how far did games become from each other. Differing Build Engine games are based on distinct game codes, making them feel at least partially different (say in terms of physics); Earlier examples, like Lameduke, might give a different feeling due to the apparent lower frame rate; But there are indeed more than enough common traits which can be found.

Share this post


Link to post
7 hours ago, NY00123 said:

 

I wonder what do you refer to when writing standalone - I guess that not projects like Ion Fury or The AMC Squad, but rather separate game modules like Rednukem or NBlood?

I actually mena projects like AMC Squad.

7 hours ago, NY00123 said:

This might depend on how far did games become from each other. Differing Build Engine games are based on distinct game codes, making them feel at least partially different (say in terms of physics); Earlier examples, like Lameduke, might give a different feeling due to the apparent lower frame rate; But there are indeed more than enough common traits which can be found.

Then i guess this should break gamever-recreation and standalone EDuke32 mods, as they may differ. Thanks for addressing!

Share this post


Link to post
1 hour ago, Redneckerz said:

I actually mena projects like AMC Squad.

Then i guess this should break gamever-recreation and standalone EDuke32 mods, as they may differ. Thanks for addressing!

Since it's about projects like The AMC Squad, their development may continue regardless of what gamesrc-ver-recreation offers; After all, they may still use the stock EDuke32 behaviors. without changing the version compatibility variable. On the other hand, doing the latter might assist if some form of stability and/or expected behaviors as desired, in case these may change during development of EDuke32 itself.

 

Referring to the breakages mentioned by you, question is - what may get broken? I originally referred to how, e.g., Duke3D, Blood and SW use very different game codes, and thus may feel different; The same may apply when comparing these to binaries that use earlier engine revisions, like LameDuke; Even if only due to game-side differences between LameDuke and the released Duke3D game, rather than engine-side changes.

Share this post


Link to post
13 hours ago, NY00123 said:

Since it's about projects like The AMC Squad, their development may continue regardless of what gamesrc-ver-recreation offers; After all, they may still use the stock EDuke32 behaviors. without changing the version compatibility variable. On the other hand, doing the latter might assist if some form of stability and/or expected behaviors as desired, in case these may change during development of EDuke32 itself.

 

Referring to the breakages mentioned by you, question is - what may get broken? I originally referred to how, e.g., Duke3D, Blood and SW use very different game codes, and thus may feel different; The same may apply when comparing these to binaries that use earlier engine revisions, like LameDuke; Even if only due to game-side differences between LameDuke and the released Duke3D game, rather than engine-side changes.

The first thing that comes to mind that might get broken is CON script behavior. Have you tested your recreated builds against CON-heavy based mods to see if these execute properly?

Share this post


Link to post
7 hours ago, Redneckerz said:

The first thing that comes to mind that might get broken is CON script behavior. Have you tested your recreated builds against CON-heavy based mods to see if these execute properly?

If you're talking about DOS executables made via gamesrc-ver-recreation, then the most that I did was building exes and comparing them (e.g., their contents) to the originals; Albeit I do recall getting a functional play-through of Duke3D v1.5's original 3 demos.

 

When it comes to EDuke32's Build Engine, relevant changes that impacted behaviors came from Nuke.YKT for most. I checked with him for more details. Before the unrelated clipping overhaul of EDuke32 (impacting the EDuke32 game code, including Ion Fury), Nuke.YKT's changes were smaller, but he still had to apply modifications for Rednukem and NBlood demo compatibility. More code was added by him after the overhaul, so demo compatibility may remain. This was also done for PCExhumed.

 

As I wrote earlier, the engine compatibility variable was appropriately set for VoidSW, in addition to the game trees specific to the NBlood repository. The variable is also explicitly set in NetDuke32 (at the time, EDuke32-OldMP).

Share this post


Link to post
On 11/4/2020 at 4:53 PM, NY00123 said:

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.

 

  Reveal hidden contents


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:

 

  Reveal hidden contents


@@ -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

 

 

 

Late night thought as I'm re-reading this thread and thinking about the whole deal with Heretic's removed "phoenix puffs"... could it have been that some early development version of Heretic had the phoenix rod working more like Doom's BFG, with the "phoenix puffs" being analogous to the green flashes that appear on top of enemies hit by BFG tracers?

Share this post


Link to post

Hi,

 

I'm having additions to the wolf3d repository after more than 6.5 years, covering two added revisions of code. But there are also a few more general points to add:

- The various repositories aren't submodules of the "gamesrc-ver-recreation" repository itself anymore. Nuke.YKT and I haven't really been using this feature, so I've decided to do this change. The repositories still exist, I just don't use the submodule feature.
- While currently done in the wolf3d tree only, doing so in other repositories isn't necessarily out of the question. So, a significant subset of the file notes-restoration.md was replaced with a new README.md file, aiming to replace it. It should be much smaller, albeit it's still not necessarily a small file. I left various notes under notes-restoration.md but I currently have no guarantee of them being up-to-date. Interestingly, the older incarnation titled "game-srccode-ver-recreation" had a quite small README.md file added to it, so this can be seen in part as going back to the roots.

 

As for wolf3d, before getting to the aforementioned two code revisions, I also made these changes:
- Output build directories were collapsed. That should be more consistent with other repositories, the Blake Stone repository being just one example. For instance, WL1AP10.PRJ's output dir was changed from "OBJ\WL1AP10" to "WL1AP10".
- One directory was mistakenly named "STATIC\WOLF3D\WL920512". Instead of "WL920512", "WL920312" is used now.

 

Let's get to the added revisions themselves.
- The first one is what I suspect to be a quite unknown April 16 1992 prototype executable, somewhere in-between WL920312 and shareware v1.0. There wasn't a lot of new code added but I did have to go through existing macros, so it took some time. There were a few exceptions here and there, like placeholder code under the function "Victory", but what was there beforehand could be reused otherwise.
- Secondly, under a new directory, I added a separate modification of the open-source release of Wolf3D into code more-or-less matching a very early ROTT prototype. Known as ROTT0993, it's still essentially a modified Wolf3D. There wasn't a lot of code added and I didn't introduce new game data to the repository. This revision draws textured floors and ceilings and also has additional hotkey checks for debugging. As for the output EXE, expect differences in debugging symbols. I was reducing them, but even after making timestamps match, I still had 29 differing bytes.

 

To finish, here's one more thing. Getting back to the wolf3d repository after about 6.5 years, short of the few occasional edits done in-between, is not something I recall doing beforehand under gamesrc-ver-recreation right now. One point was known to me earlier, but having another look after a while further clarified it. Basically, the use of pre-processor macros did make it possible to cover many versions under a single codebase - currently 19 in total. On the other hand, over time, it may become difficult to maintain this code and track it with the added pre-processor macro checks. Then again, they did make it quite convenient to see differences between versions under a single window, without using a diff program. But that can be a challenge when it comes to supporting multiple versions in source ports. In ReflectionHLE's case, I mostly bypassed it by repeatedly rebuilding ported Wolf3D sources with a bit different configurations and then linking the builds into a single binary. Definitions of pre-processor macros inherited from gamesrc-ver-recreation were changed across these sets of objects. I still made adjustments, if due to the replacement of the macro UPLOAD with a variable of the same name, or any other technical reason.

 

On 10/17/2023 at 12:29 PM, ETTiNGRiNDER said:

 

Late night thought as I'm re-reading this thread and thinking about the whole deal with Heretic's removed "phoenix puffs"... could it have been that some early development version of Heretic had the phoenix rod working more like Doom's BFG, with the "phoenix puffs" being analogous to the green flashes that appear on top of enemies hit by BFG tracers?

 

I still don't have a known answer, but I guess that maybe? To compare, Doom's BFG9000 was shooting multiple plasma balls during development of the game.

Share this post


Link to post
20 hours ago, NY00123 said:

- Secondly, under a new directory, I added a separate modification of the open-source release of Wolf3D into code more-or-less matching a very early ROTT prototype. Known as ROTT0993, it's still essentially a modified Wolf3D. There wasn't a lot of code added and I didn't introduce new game data to the repository. This revision draws textured floors and ceilings and also has additional hotkey checks for debugging.

 

Awesome. Is the code for the textured floors and ceilings the same as in Blake Stone and/or Super 3D Noah's Ark?

Share this post


Link to post
On 2/27/2024 at 10:27 PM, Frenkel said:

 

Awesome. Is the code for the textured floors and ceilings the same as in Blake Stone and/or Super 3D Noah's Ark?

 

Thanks!

 

Like the other games, the prototype in question indeed uses a variation of the code found under WOLFHACK.C. One difference is that it makes no use of WHACK_A.ASM, and all relevant code resides under WOLFHACK.C. Related data in memory may also be changed via WL_PLAY.C:CheckKeys by pressing on any of the keys C, F, 0 and 7-9.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×