NY00123

So, the following recent discovery of mine is less about the aforementioned clone for DOS itself, but is still Pengo-related, so I guess I can still use this thread for now (rather than creating a new one). People around here might be familiar with the 1993 Apogee-published game titled "Halloween Harry", or alternatively, "Alien Carnage". In fact, it was not the first game in the franchise. One of the people behind this 1993 game, John Passfield, was previously working on a 1985 game similarly titled "Halloween Harry" for the Australian Microbee computer system. The game was released via Honeysoft Publishing Company at the time. I wrote about it beforehand: https://forums.duke4.net/topic/12315-alien-carnage-halloween-harry-corner/page__p__379778#entry379778 Now, after a recent search leading to a page about the person's works, I accidentally found out that Passfield previously published another Microbee game in this manner. It is the 1984 game "Chilly Willy". Indeed, it is a clone of Pengo. There's another clone of the same name for the Commodore 64, btw. Actually, chances are I already saw a mention of the Microbee-compatible clone, at least in the file "harry25th.txt" as available from an August 1993 beta of the Apogee-published Halloween Harry game (if not also the freeware release's readme.txt). In the aforementioned thread about Halloween Harry, I brought up the Microbee Software Preservation Project, i.e., MSPP. As in the case of Halloween Harry, I could find a disk image including Chilly Willy and get it to work, using the uBee512 emulator: Vimeo-hosted gameplay video: https://vimeo.com/75279888 YouTube-hosted gameplay video: https://www.youtube.com/watch?v=FidEYtravyk

https://gitlab.com/NY00123/pango-re Pango is a clone of the arcade game Pengo (note the differing 2nd letter). As in the original game, you play the role of a penguin, named Pango in this clone. Your goal is clearing the field of bees. You can do so by squashing them with blocks. Additionally, you may capture bees after shocking them by kicking nearby walls. For more details, including bonus points, check "How to Play ?" in the game's menu. The original arcade game was released in 1982, from what I can see. The covered DOS version was (probably) released in 1983. The linked repository includes reconstructed assembly sources. It is my assumption that the sources were originally written in assembly, given the lack of an equivalent of C library initialization routines or standard calling conventions. Also, outside of using a call stack for function calls and pushed register values, stack memory does not appear to be used for local variables at all. With the right tools, I could recreate the original executable, byte-by-byte. Namely, these would be The Microsoft MACRO Assembler (MASM) Version 1.10 (5.10 is another option) and the IBM Personal Computer Link Version 1.10. As usual, your mileage may vary. While optional, the Microsoft Program Maintenance Utility (NMAKE) Version 1.00.05 should be useful.

So the info isn't correct, at least not for v1.01. What about another version? I know that The Catacomb Abyss had at least 3 versions out (shareware versions 1.12 and 1.13, plus registered v1.24); The Catacomb Armageddon had a version titled "Curse of the Catacombs", while The Catacomb Apocalypse had one named "Terror of the Catacombs".

I'm wondering, does that also include the Catacomb Apocalypse? Reason is that, assuming the information currently given in the following page is correct, it has an IMF file matching the length of Too Hot to Handle's IMF, only that it's filled with empty instructions: https://vgmpf.com/Wiki/index.php/Too_Hot_to_Handle

This post can be seen as a response to the following thread, but I wasn't sure if bumping it after about 8.5 years ago was a good idea: Basically, while the Doom games as originally released might not make use of the DMX library's General Sound Set (GSS) support, another game does. Namely, Raptor: Call of the Shadows. It was about 8 days ago when I uploaded a demonstration (warning - expect noises at times), selecting Adlib and using Nuked OPL3:

Adding my words as well. 1. Work on Raptor v1.2 was started by @nukeykt after receiving original files from Scott Host of Mountain King Studios. I joined later with the efforts, albeit I consider most work to still be done by @nukeykt. v1.1 was indeed covered by @nukeykt during the span of a single day, more-or-less. For v1.0, I helped a bit, mostly with Sound Blaster related code in DMX, but it was otherwise @nukeykt's work again. What we ended with were 3 separate private git branches representing versions 1.0, 1.1 and 1.2. They weren't ready for becoming public, due to the presence of proprietary DMX code and other possible aspects of code review. I eventually took the open-source release of v1.2 from skynettx' repository and added versions 1.0 and 1.1 to the same codebase, while preparing additional files (like Raptor's makefile and helper scripts) for support of all covered versions. I also added README.md, partially based in form on notes previously written for other games. 2. One more thing is the time span, given that it all started back in November 2021. While originally preparing the open-source release of Raptor v1.2, we were waiting to see if we'd maybe be able to use DMX. There were also internal pending code review notes. At some point, Scott Host seemed to want something a bit different; While he'd be working on a remaster of Raptor without a legacy mode, @nukeykt would work on a more direct port of the original game, with the idea that - possibly as an alternative to the DOS sources - the port itself would be the one to go open-source. Eventually, as written by @nukeykt, he had finally gotten back to Raptor v1.0 source reconstruction and finished it in September 2023. Host showed support for the original plan again, and not much later, skynettx published the sources. 3. I'll finish with the topic of forum threads. People have maybe noticed that the Duke4.net and/or Doomworld threads on the topic were new ones. In fact, @nukeykt already started a separate related Doomworld thread earlier, covering reconstructed Doom and Strife sources. Beforehand, there was generally just a single thread of mine about gamesrc-ver-recreation in each forum which had any; For a portion of these threads, each of them would be mostly specific to one game or engine, but that wasn't the case for all of them. I had actually considered deprecating my Doomworld thread covering Heretic+Hexen and migrating to @nukeykt's thread about Doom+Strife as a new general one. However, it was eventually decided with @nukeykt to start a new one for Raptor (at least on Duke4.net and Doomworld for now). A few reasons to bring up: - If a post about a newly covered game (e.g., Raptor) were to be made in a more general existing thread, then people who see the title wouldn't immediately be aware of Raptor being the topic; They wouldn't know without inspecting the thread. - As an added post to a previously created thread, chances are it would look like a small update, rather than something entirely new. - Finally, I think that usually, one person's reverse-engineering projects covering different code-bases (e.g., games) are considered to be separate endeavors. Sure, we've had varying repositories under gamesrc-ver-recreation, and there's more than enough to share (like the Apogee Sound System). But I still think the notion of such projects being separate makes sense.

Confirming. One thing to remind here is that the aforementioned garbage data might depend on the environment. Originally, I got an executable differing by 42 bytes from the released EXE instead of 29, but I could shrink this figure to 29 after changing environment variables to be closer to Nuke.YKT's. These were a part of a setup for running Watcom's program, say a modification to the PATH environment variable and the addition of a WATCOM variable. I'll remind here that (non-demo) versions "1.0r1" and "1.0r2" of Hexen differ in one manner, as described in the thread I created here about gamesrc-ver-recreation: The call to S_StartSongName from P_SetupLevel was made conditional in "1.0r2", depending on the value of i_CDMusic. I haven't fully inspected the files related to Doom, and don't know for sure if there's anything new that matters, compared to the previously uploaded disc image. At least a subset is indeed common, like one SIT file that I'm not even sure what was its original filename: "2:17:19.sit", "2/17/95.sit" or "2_17_95.sit".

I can't be 100% sure, of course. I didn't make full comparison of non-Hexen contents, albeit it's maybe similar to what the other CD had. While I'm not 100% sure about the Hexen sources, my guess from the timestamps is that it either matches 1.0(r2) or is very close to that versions. Either way, bidding sold this time.

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.

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

I can mention first that version 1.1 of the remix has been released recently (January 15, more-or-less). Albeit I had another reason for posting now. As a little disclaimer, for the ones not aware: - I found myself in contact with Scott Host a few years earlier. It was originally Raptor-related, with @nukeykt having greater involvement thanks to earlier reverse-engineering efforts, but that might be a different topic. - As a consequence, I've been granted a copy of the game. The video linked here should demonstrate this copy. - I've actually also gotten beta access a short while before the release, albeit not doing much pre-release testing. And so, here's the video. Following a textual segment about DemonStar and the re-release, level 1 is demonstrated in legacy and enhanced modes, side-by-side. I actually used the less common vertical orientation / TATE mode, currently with the aspect ratio of 5:6. In total, 12:6 for the video itself.

Regarding the described Hexen source tree - thanks to @nukeykt for checking: The timestamps show this revision was last edited on Oct 15 1995. This date is also in the timestamp of CD version 1.0's executable, currently identified as "1.0r2" here: https://doomwiki.org/w/index.php?title=HEXEN.EXE&section=2#Older_versions_2 A separate source reconstruction of this version should exist in gamesrc-ver-recreation as of now. The main technical advantage of having access to the original sources would probably be ensuring BSS variables got ordered exactly as in the original 1995 executable; Albeit, it's probably possible to do the same with the reconstructed sources by manipulating extern symbol definitions, if one knows how to. Other than that, it's mainly about knowing more of the original code, if in variable names or source code comments. https://www.doomworld.com/forum/topic/114031-restoration-of-differing-doom-engine-exe-revisions-also-done-for-other-games/

It does, at least in what's known as the Original Missions (from 1997-1998). The situation differs for the Secret Missions (2002-2003), and is a bit complicated for the first part of them. The Original Missions (OM) indeed have MIDI tracks of Prince. The Secret Missions 2 (SM2) have digitized recordings of Scott Host. With the Secret Missions 1 (SM1), this depends on the version. The less commonly known version 5.0 from 2007, possibly made for Reflexive Entertainment, also has a digitized soundtrack of Scott Host in SM1. It'll further be used as a base in a new version of SM1, similar to the recent release of OM. In versions earlier than 5.0, SM1's intro track is still essentially the same digitized one, but all the rest are Marcus Knudsen's MIDI tracks. Even during SM1's intro, an empty MIDI track is played, in parallel to the digitized one that can be heard; Probably since playing an intro MIDI is also what happens in OM. Migrating to Host's digitized tracks in SM1 as of v5.0 obviously made it closer to SM2 in style, while I also heard about copyright-related concerns with the MIDI tracks for SM1.

https://en.wikipedia.org/wiki/DemonStar This is a top-down vertical scrolling shooter, from the same company that brought Galactix and Raptor: Call of the Shadows. Consisting of 18 levels, this game, retroactively also known as "DemonStar - Original Missions", had an initial demo release by the end of 1997, before having a proper release in 1998. 8 more levels, known as "Secret Missions 1", were further released in 2002, followed by 8 levels of "Secret Missions 2" in 2003. Recently, a new release of the Original Missions was released via Steam, including a remixed mode not present beforehand. https://store.steampowered.com/app/2577180/DemonStar__Original_Missions/ It's still being updated. Certain features, like keyboard remapping, are planned to be re-implemented, due to the removal of Windows-specific code. Scott Host (the owner, and also the coder of the new version) hopes that sales of this version will assist with funding further development of Raptor Remixed.

Looks like another project that I've missed and should be aware of! I've also let @nukeykt know. Even if I did spot this project beforehand, I was surely not aware of the recent (re)introduction of DOS support until the previous day or night. 6 months preceding Doom shareware v0.99/1.0 were surely a significant development. When it comes to the reverse-engineering department and getting things accurate, I can totally understand the technical difficulties that ones may have to go through. I misremembered or wrongly assumed the early versions to not use DMX at all, given the lack of sound output; Well, that was apparently the case for versions of Doom preceding 0.5, while v0.5 had quite early DMX code. Having non-optimized binaries surely assists, and so does debugging information.