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


  • Content count

  • Joined

  • Last visited

1 Follower

About NY00123

  • Rank
    Warming Up

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. For the ones who don't know, here's a Duke4.net thread about In Pursuit of Greed, created by Lunick around the time the sources were uploaded: https://forums.duke4.net/topic/7845-in-pursuit-of-greed/ There are a few posts of MrFlibble and Blzut3 referencing the title "Assassinators", which you may find interesting. A notable example is the following response of Robert Morgan to Blzut3 about the title: Also, some things which I didn't get to write in my preceding post, of course: While I don't recall myself playing any of the Catacombs back in the day, I did have a chance to try a demo of In Pursuit of Greed, found in a shareware games CD. It's essentially version 2.0 from September 1995, as available from here: https://www.classicdosgames.com/game/In_Pursuit_of_Greed.html I don't think that I was trying the single player campaign for very long, but I accidentally turned out to have at least 1-2 deathmatches in a LAN with 1-2 more players. I otherwise don't recall trying this game again, at least not before it became open-sourced. During 2015, I had at least one deathmatch over the internet, and later, I did complete the single player campaign. The latter was done across at least a couple of separate time periods, but I eventually finished all episodes.
  2. Great to see someone porting another less commonly played game! To clear things up, I'm comparing here to these other games made for Softdisk, i.e., the 3D Catacomb titles; These games were ported by Arno and me; There's also NotStiller who experimented with a separate Catacomb 3-D port, for another example. When it comes to the 2D games, I know that the second of them was ported by Blzut3, with some help from Havoc. I'm actually wondering which game was a bit more well-known: In Pursuit of Greed or any of the Catacombs; My hunch is currently that it's either one of the Catacombs, or there's virtually no difference. I can't say that, as a low priority idea, I didn't think about trying to make a port of this in the past; In fact, it's actually someone else who asked me about this; Wondering if this individual knows who I'm referring to :). It's good to see that someone else is porting the game instead, then. Using Pascal is an interesting choice; It's quite impressive to see you cobbling up your own converter for the C files, albeit I can understand the reasoning for doing this. I think that the compiled code as present in the EXE should still be native code for most, right? Pascal was actually the first general-purpose programming language that I properly learnt (albeit not self-learnt), at least partially.
  3. @Arno I was surprised (at least a bit) when I discovered the existence of the Catacomb Wiki, obviously due to my assumption that there's a significantly lower interest in the Catacombs than in, say, Commander Keen. I guess that eventually, one individual is sufficient for launching a new Wiki. I know that there was at least one attempt to mod any of the 3D Catacombs, but I don't know if anything using Catacombs code was released. I saw that you re-used Reflection Keen for the sound code. I didn't think about the notion of inspecting the C translation of assembly code, although in a retrospect, this actually makes sense. Nice to see my work for the Catacombs being useful in this manner, given what I presumed to be low interest in the series again. Another example of work which I'm aware of is an Amiga port of Reflection Keen, done by someone identified as "BSzili": https://github.com/BSzili/refkeen/tree/amiga One thing about CatacombGL which I did notice a while ago is that, while it was clear to me that you used the original sources as a reference, CatacombGL is mostly looking like new code, implementing various features somewhat differently. It's possible that I may get differing impressions based on the filenames. Consider ECWolf for one example. While it's obvious that it has differences from the DOS versions, say, due to support of DECORATE for modding and the differing video output code, it still has enough code which clearly comes from Wolfenstein 3D. I thought that Catacomb 3-D was maybe a bit more well-known than Abyss, due to being the first, and also since I think that it was (probably mistakenly) included in at least one BBS and two CDs of game collections; At least one of these CDs is identified as a collection of shareware games. A couple of more points about CatacombGL development: - I've wondered how feasible it can be to re-implement Carmack's software renderer. Since Catacomb 3-D's renderer can be seen as an early prototype of Wolfenstein 3D's renderer, though, maybe it's better to use the one from Wolf3D as a base (unless you do want Cat3D's one). - I see that you actually considered making CatacombGL compatible with saved games from the original DOS versions. I assume that this covers just saved game loading, due to CatacombGL working in other ways internally? You maybe further saw that there might be a problem with even defining such compatibility for Armageddon/Apocalypse. For the ones who don't know, this is related to my previously mentioned example of "statetype" structs being moved to far memory for these games. Basically, pointers to such states are written to saved games. In Cat3D and Abyss, and also in KDreams, Keen 4-6 and Wolf3D, these are 16-bit near pointers, consisting of 16-bit offsets. These offsets depend just on the layout of a specific EXE for DOS. With the structs moved to far memory, though, each such pointer is a 32-bit value consisting of a 16-bit segment and a 16-bit offset. In theory, the segment should also depend just on the EXE. In practice, though, the exact location of the first loaded segment depends on the environment (e.g., available memory), and this also impacts the locations of all following segments. Catacomb Armageddon and Apocalyse (the original DOS versions) still write and read saved games as usual, but there's no guarantee with regards to the stability of the segment values. In particular, if you start the game from DOSBox, save a game, then restart it with LOADFIX and then load the game, there are great chances that you'll get the game to a seemingly undefined corrupted state. The situation is different in the case of Bio Menace, for which the "statetype" structs were also moved to far memory. This was actually the reason for changing the game to bring you back to the beginning of the corresponding level after loading a saved game. In the Bio Hazard prototype, which still has the states in near memory, you can load a saved game and find yourself in the middle of a level, albeit it's not without issues.
  4. Going to reply on Tab+O as used in Wolf3D, but this might be the chance to finally write a bit about Catacomb 3-D ports in general. So, with regards to CatacombGL itself, very good job! Nice to see that less commonly played games like these get the attention, and not just from me. Personally, I wasn't very familiar with the Catacombs when I started. I probably saw just a few bits of Catacomb 3-D beforehand. I got exposed to Dangerous Dave very long ago, though, so it was obviously not done via the Gamer's Edge Sampler Disk, at least not in a way which lets you select Catacomb. I also got familiarity with the Keens, again quite a while ago. After the Catacombs were open-sourced, I had small work on files from the id Engine, in case it may become useful for some Keen game. Eventually, they only got used for an actual released project of mine after Keen Dreams was open sourced. I started with the CGA graphics for Keen Dreams, with support for EGA versions being added afterwards. My port was initially titled "Chocolate Keen Dreams". Later on, I (eventually) ported all 3D Catacombs, beginning from Catacomb Abyss. I also gave up "Chocolate" for "Reflection" after adding Catacomb Abyss support. Thus, we now have "Reflection Keen". Someone identified as NotStiller was also experimenting with a Catacomb 3-D port. The initial commit was done about 2 weeks before Keen Dreams was open-sourced: https://github.com/NotStiller/Catacomb3D/ Either way, good job again. While it's obvious that users of ports prefer them to run natively, version 0.4.3 is already working well for me under Ubuntu, using Wine. I've checked this. The overhead map is accessible in Wolf3D shareware v1.0 with Tab+O, although the data is missing 16x16 tiles required for proper map display. Enabling cheats in v1.0 is just a little bit different than in v1.1+, but it's otherwise the same. The code was disabled using "#if 0" blocks, but is still present in the sources as originally released, within WL_DEBUG.C. The earlier alpha build from March 1992 also supports this, and has the 16x16 tiles in the VGAGRAPH data. F10 is used in this prototype instead of Tab; Just like Keen Dreams and Keen 4-6, and also like Catacomb 3-D and Catacomb Abyss. A few side-notes: 1. Catacomb Armageddon & Apocalypse changed to using Backspace for the debug keys instead of F10. The same thing was done for Blake Stone. I have a feeling that this is not a coincidence. 2. On the other hand, Catacomb Armageddon & Apocalypse both had the "statetype" structs moved to far memory, something which was also done during the development of Bio Menace. Unlike the debug keys example, this does look like a coincidence to me.
  5. @PVS Good to read about this information. Being quite unfamiliar with general id Tech 1 modding, albeit still having a copy of SLADE, I found myself searching for suits of armor in maps, while using DoomWiki pages as references; Emphasis on suits of armor from which monsters can spawn. Of course, this was done (at least initially) without being 100% sure that "Suit of armor" was indeed what I was looking for, again due to lack of familiarity (well, mostly with Heretic and Hexen; I'm way more familiar with Doom terminology e.g., the names of monsters). I still want to investigate differences between revisions of Hexen identified as 1.0. As for CHeretic/CHexen, I've had a look at a few strings in CHEXEN.EXE with a hex editor, and compared it to HEXEN.EXE (v1.1 without the A_SoAExplode fix). My conclusion is that CHexen is using DMX. The same applies to CHeretic as well.
  6. Thanks again for the interest in this work! Going to answer about some points raised here after my preceding post: - First, a few examples of hardcoded texts specific to Hexen 1.0: https://bitbucket.org/gamesrc-ver-recreation/hexen/src/112c5f366158f930f9755895298195bd57370879/IN_LUDE.C#lines-156 https://bitbucket.org/gamesrc-ver-recreation/hexen/src/505686ef1310fc3d22410e5674c868a75272fb52/F_FINALE.C#lines-62 - I wasn't sure about saved games compatibility, again due to not being familiar with the codebase. I do know that in the earlier titles of Keen Dreams, Catacomb 3-D and Wolfenstein 3D, the saved game as present in the file also includes 16-bit near pointers, which clearly depend on the EXE layout. At least in Hexen, I believe that at the most, the difference between two pointers to different locations in the same array is written, and this is indeed not dependent on the EXE layout, at least not in the same manner. - Regarding the sound library and licensing, I haven't yet checked CHexen or another port to be sure. I was just aware of Nuke.YKT's DMX wrapper using the Apogee Sound System, so I realized that it'd possibly work with the original Hexen sources after not more than a few changes. I've just looked for CHeretic and CHexen now, though, and what I can find are archives with EXE and TXT files, but not the sources? - A short explanation about the name STRIPHEX.EXE: If you check the makefile as present in the open-source release of Hexen, you can see that the Watcom Linker (wlink) is first used to create hex.exe, then the file is copied to striphex.exe, and finally, debugging information is removed from the latter using the Watcom Strip utility (wstrip). - What I've been doing is indeed useful for Chocolate Hexen . As usual, it's a matter of someone spending the time in preparing a patch or more, especially if refactoring has to be done due to the desire to support multiple versions from a single EXE. Now, following a suggestion of Nuke.YKT, I did submit a (quite) small patch for Chocolate Hexen, reverting a bug fix in A_SoAExplode, so the function will behave like HEXEN.EXE as coming from Steam: https://github.com/chocolate-doom/chocolate-doom/commit/7ac729c46dd3a221f1f9665d194ed929149aa013 However, I later learnt that there are two EXEs identified as Hexen 1.1 (if not more). The EXE not coming from Steam can be found here: https://github.com/Doom-Utils/iwad-patches/tree/71eeba800e8bd021e4b756c96b93ca2064842d21/vanilla-engine/ As it turns out, this other EXE is actually matching the Hexen sources as originally released. In particular, these are the few differences that I could find between the two 1.1 EXEs: - The A_SoAExplode bugfix being present in the EXE from the above repo (not fixed in the EXE from Steam). - VERSION_ID is set to CBI in the earlier 1.1 EXE from Steam, and to BCP in the later one. - The expanded __DATE__ string differing as expected. Of course, supporting this in Chocolate Hexen will probably require the introduction of support for differing variations of the Hexen 1.1 EXE, like the four variations of the Doom 1.9 EXE that I'm aware of: The original EXE, Ultimate Doom, Final Doom and Final Doom - id Anthology.
  7. Hey @PVS, thanks for your interest! All right, I have attached an EXE. It still requires an external DOS/4GW loader or compatible (e.g., DOS/32A). The audio output, especially the MUS tracks, is expected to sound different, due to usage of the apodmx wrapper. I've used the following repositories with the referenced commits, and further with the Apogee Sound System matching version 1.09: https://bitbucket.org/gamesrc-ver-recreation/audiolib/src/ad045a8d066d4f806b73b008afa134aabd3ac973/ https://bitbucket.org/gamesrc-ver-recreation/apodmx/src/9658b6c89ff27a223e456d12cf17828a4d40f0b1/ https://bitbucket.org/gamesrc-ver-recreation/hexen/src/505686ef1310fc3d22410e5674c868a75272fb52/ Personally, I only properly completed the relevant Heretic and Hexen titles once (in terms of play-throughs). However, I still have differing periods of interest in recreating sources for older versions of (generally) open-sourced games from the 90s, like these. While I still can't make any promise on Doom or even Heretic, my plan has been to start from Hexen, then continue to Heretic, and finally, if it's feasible, try to tackle Doom. One way in which I think this work differs from ports supporting the behaviors of multiple versions (including DOS ports), as described by you, is the following. Basically, what I'm trying to do is prepare an infrastructure, which can later be used by ports like Chocolate Doom. STRIPHEX_10_20200508.7Z
  8. Did anybody figure out in the past the exact original firemace spawning behavior (say by reverse engineering)? If yes, then I suppose that one can grab some Heretic sources that you can build and are known to behave like 1.3 (say Chocolate Heretic), apply this modification, make an exe and then play back the demos; Mainly since I consider the Heretic sources to match 1.3 in behaviors at this point. Thanks for the suggestion. Yes, I'm aware of the copy of the DMX files that he got. I actually used the DMX 33gs headers and the DMX 34a library, since Nuke.YKT initially tried to do this with Heretic and seemed to get quite close code. It turned out that the open-source release of Heretic is matching 1.3 (as available from Steam), although it's possible that the compiler may generate the code of one function or two a little bit differently. Why not just use the DMX 34a headers, btw? Well, they appear to differ just in one header file, and only by the addition of 1-2 additional extern symbols (and also a couple of more macros). The addition of any function/variable declaration or definition, even if it's just a declaration of a function/variable which doesn't even exist, is enough for changing the order of global variables as present in the EXE, at least with Watcom. For reference, the presence of these DMX files was mentioned in this issue, initially discussing MIDI sound effects: https://github.com/chocolate-doom/chocolate-doom/issues/639#issuecomment-156249500 Doomworld thread on the topic: Getting Doom and other games open-sourced was a thing of Carmack, while working for id Software, so it obviously had nothing to do with code not belonging to id. There seemed to be disagreements from id Software's side on decisions done while DMX was developed, which obviously wouldn't assist here. Either way, Paul may have his personal reasons, indeed. As I'm not even sure that Digital Expressions, Inc. (the company which was used for licensing DMX) still exists, it might just be simpler to do nothing. Another possible reason is that, according to the following Wiki page, Paul holds various patents related to audio in games: https://doomwiki.org/wiki/Paul_Radek
  9. Hi all, Let me introduce you to the following collection of repositories: https://bitbucket.org/gamesrc-ver-recreation/ Basically, most of this work involves reverse-engineering of code related to games. However, rather than REing a whole game, what I usually do is RE a different version of an already open-sourced game. The success rates vary greatly, due to the technicalities involved. I got this idea after the open-source release of not just one, but multiple DOS versions of Softdisk's Keen Dreams title. In particular, I had a look at the revision matching shareware v1.13. Using what I assumed to be the exact process for making the EXE, I got precisely the original EXE from the 90s, byte-by-byte. This process includes usage of the right compiler version, as well as packing the EXE with LZEXE 0.91. Back to the above-mentioned collection of repositories, a more successful example that you may find is the code for Wolfenstein 3D and Spear of Destiny. With minor exceptions for certain Spear of Destiny EXEs, this should cover EXEs that may be perfectly recreated, byte-by-byte. Examples are the Apogee versions (shareware/registered versions 1.0, 1.1, 1.2 and 1.4(g) without disabling the cheats), as well as the Activision versions. With the assistance of earlier REing work done by Blzut3, I also added the DOS version of Super 3-D Noah's Ark, which can be perfectly recreated, minus the debugging information. I further have a separate tree for Blake Stone, similarly building upon Blzut3's work for REing Aliens of Gold (the open-source release covers just Planet Strike). Now, my most recent addition is Hexen 1.0, with version 1.1 also being covered. You can find these under the "hexen" submodule. In the case of Hexen, especially version 1.0, the EXE isn't exactly matching in layout, although there are great chances that it's otherwise identical in behaviors. Saved games compatibility might be an exception; I'm not sufficiently familiar with Hexen's saved game format to know for sure. More notes to add: - Like the original open-source release of Heretic and Hexen, this is not including the proprietary DMX sound library. I've added a GPL-compatible replacement, albeit it won't sound exactly the same, especially the music (excluding CD Audio). Some of you may recall Nuke.YKT's PCDoom port. As a part of his work on it, he created a DOS-compatible DMX wrapper which is backed by the Apogee Sound System. So, I've made a few changes to the wrapper and then uploaded it. You'll need to have the submodule subdirs of "audiolib", "apodmx" and "hexen" residing in the same directory. - As usual with public repositories, there might be changes later, like using output directory names differing from "10" or "11". Just for one example of an explanation, I've recently learnt that there might actually be two original Hexen DOS EXEs identified as 1.1, with one of them possibly including the following A_SoAExplode bugfix for DK, which I've disabled for now: https://bitbucket.org/gamesrc-ver-recreation/hexen/src/505686ef1310fc3d22410e5674c868a75272fb52/A_ACTION.C#lines-1161 - What about other id Tech 1 games, like Doom or Heretic? Well, Doom is expected to be quite more difficult, since we don't have access to original DOS sources. Heretic should hopefully be closer to Hexen, in case I get to it; Although, while working on Hexen 1.0, I occasionally used Heretic code as a reference (even bringing a few functions from Heretic as-is). I might not have this privilege for older versions of Heretic. What I can say, though, is that an earlier inspection of Nuke.YKT and me shows that the Heretic sources appear to match version 1.3.
  10. Hi all, I originally created a forums account during September 2014, probably in case I want to ask or comment about a specific topic I had in mind. Of course, things then changed and I made no post at all, except for the one lonely post last February. So, I've thought about making a short introduction. I'm concurrently repeating this in the ZDoom forums. Basically, I'm mostly known around (retro) gaming cycles as NY00123. It'll probably be the simplest to search around the Internet if you want to learn a bit more about me, but a couple of related hobbies of mine are programming and RE. While I've been spending way more time in other games, I do have experience with Doom and related franchises, and I completed the following titles: - The Ultimate Doom, Doom II, the Master Levels for Doom II and Final Doom. - The Sony PlayStation port of The Ultimate Doom and Doom II. - Heretic: Shadow of the Serpent Riders, Hexen: Beyond Heretic, Hexen: Deathkings of the Dark Citadel, Hexen II and Heretic II. - Doom 3 and Doom 3: Resurrection of Evil. As is the case of other forums, there are chances that I won't post a lot. Well, I think that this is it.
  11. Can probably just wish good luck with the act of experimenting with the codebases of the games and related libraries. I maybe weren't contributing to Build Engine ports as much as others (like TerminX or Hendricks266) had been, and also didn't get to release that much user-made contents. But, I've seen enough of the code, especially Duke3D and the differing libraries, that I can say that it is often very far from easy to get something decent and new done, especially if you want it to be done well. The differing game codes being quite distinct (even if eventually derived from the same Ken-Build test game) obviously add to the above.