[MrFlibble]

BTW, speaking of NBlood and Blood source code reconstruction, I'm a bit puzzled that NBlood apparently still does not have support for the shareware version. Even taking into account the version differences between the final shareware (v1.11) and retail (v1.21?) releases, how complicated would it be to implement that?

[Phredreeke]

My guess is the demo version is considered redundant. I don't think the Powerslave demos or the half level RR demo are supported either in respective port.

[NY00123]

Question is how much effort will be required. If the versions are very similar, maybe; There might also be significant differences. Nuke.YKT was obviously striving for a high level of accuracy, at least as a base for something that can be modified later.

EDuke32 itself has some support for shareware v1.3d, but it has never aimed to be even close to a demo-compatible port.

btw, on a sub-topic which covers a game in gamesrc-ver-recreation, albeit separate from these repositories, I've recently learnt of this:

https://www.doomworl...eering-project/
https://github.com/I...ringer/Doom05RE

[MrFlibble]

 Phredreeke, on 31 December 2023 - 11:28 AM, said:

I don't think the Powerslave demos <...> are supported either

The final four-level demo is fully supported, which was added at my request, as a matter of fact:

 sirlemonhead, on 30 November 2019 - 01:52 PM, said:

We'll certainly look into supporting the demo, especially as it sounds a lot simpler based on what you've said.

As for the Redneck Rampage demo, well, it's so short it was probably not worth the effort, so I never even asked, although, unless there's some drastic difference between the map formats used in the demo and the retail releases, there should be little trouble in actually implementing that, just like with Powerslave.

Also the shareware version of Blood is not really a "demo", it's a fully featured Apogee model shareware game/episode with a complete storyline, boss battle, secret level (IIRC) and multiplayer options. It's kind of a complete stand-alone game, with the only problem (from the source port perspective) being that it's somewhat behind the final retail patch, codebase-wise -- although I do not know what exactly is different.

[Phredreeke]

My recollection is that the shareware version was actually used in early stages of reverse engineering, due to having debug symbols left in.

I also think there's a funny message upon entering the tunnel at the end of the second level that was left out of the final version.

The RR demo interestingly has some different tiles in the art file, including a different render of the coot

[NY00123]

Hi,

Frenkel, on 06 June 2023 - 03:16 AM, said:

What about this September 1993 version of WOLF3D.EXE?

I suppose an updated answer to this question should be found here.

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.

[NY00123]

Looks like a good time for a new post.

1. First of all, after about 11 years and 5 months of hosting on Bitbucket, a decision was made to move gamesrc-ver-recreation's sources to GitHub. That follows Bitbucket-side policy changes. One is about forking a repository outside of its workspace, even if less relevant for gamesrc-ver-recreation so far. That policy change might be related to having companies' use of Bitbucket workspaces in mind. Another policy change is the cleanup of free workspaces which are unused after some time period.

Here's the new URL: https://github.com/g...-ver-recreation

In fact, this endeavor briefly started as a GitHub-hosted repository named "game-srccode-ver-recreation", as shown by a git remote URL of an old local repository. It had its life in 8 commits during November 2014's first week.

2. Secondly, both Nuke.YKT and I had a few updates for the Build Engine repository, albeit actual code changes committed by me are mostly based on code received from Ken privately and released with permission in 2024*.

About a year ago, Nuke.YKT made changes allowing the recreation of Build Engine object files matching multiple versions of Blood and its Build editor, MapEdit. Covered matching versions, not including the 3dfx patch, are 0.91-1.21.

As for me, I used engine-side C code released in 2024 in order to make some changes, say cleanups. At times, it was just about making code look closer to the original. That said, C code from buil062896.zip helped me remove a couple of hacks from MMULTI.C, while code from BUILDBAK.ZIP helped fixing incorrect local variable naming in CACHE1D.C's functions "compress" and "uncompress".

Most important, BUILDBAK.ZIP and buil1995.zip helped me fix inaccuracies in binary code recreation within 4 functions of ENGINE.C. In particular, an ENGINE.OBJ file fully matching the Build Editor (BUILD.EXE) for Duke3D v1.3d in binary code may be recreated now (along with the rest of the Build Engine objects). Ignoring a few caveats like possible environment-dependent data inserted between C string literals by the Watcom 10.0 series of compilers, all code of this revision of BUILD.EXE may be accurately recreated now.

3. Last but not least, Nuke.YKT also got something up within the Apogee Sound System (audiolib) repository. In addition to the Build Engine, during the same month of April 2025, he applied changes allowing the recreation of code matching version 1.12 as used in Blood. People might remember that audiolib's open-source release is also identified as 1.12, but it turned out to have at least a few differences. As a consequence, I decided to add the option to build code matching two AUDIO_WF.LIB files from the open-source release of 2002, as well as that release's C code.

To finish, last March, Nuke.YKT improved upon my earlier work from 2017 Q4. I was working on recreating v1.04 as used in multiple DOS versions of ROTT identified as v1.3, but had major difficulties with the function MV_ServiceVoc. Thanks to the assistance of line number information found in the original AUDIO_WF.LIB file's MULTIVOC.OBJ, Nuke.YKT managed to change the function body, so it may be accurately recreated now. On a minor note, back in February 2019, I added the option to more-or-less recreate v1.09 as used in Shadow Warrior (1997) 1.0-1.2. That said, the contents of the generated FX_SetupCard differed by one register read. That is fixed by Nuke.YKT as well now - probably thanks to two switch statement's cases having separate identical code bodies, instead of one shared body of code.

* See video and URLs referenced in video description:

[HellFire]

Any plans on restoring the original/non atomic Duke3D .exes (1.3d) ?