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