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

NY00123

Members
  • Content count

    72
  • Joined

  • Last visited

Everything posted by NY00123

  1. Yes, this is indeed the clause that makes the original 4-clause BSD license incompatible with the GNU GPL. A big question is which combinations are still allowed by the GPL, if any. For example, there are instances in which a GPLed program is allowed to be linked with a proprietary system library. For more details, the contents of the relevant GPL document should be inspected. https://www.gnu.org/licenses/gpl-faq.en.html#SystemLibraryException This clearly sounds like a useful approach for the user. Once the relevant parser from another source port is added, some amount of work might be required for replacing hardcoded contents like strings. Hopefully, there won't be as much work for the arrays defined in INFO.C, because there aren't that many of them. Maybe function pointers will need more work for going through them.
  2. NY00123

    Doom and Strife source code restoration

    Hmm, is it possible that I should maybe clarify what I wrote earlier? Basically, I was wondering if you could build DeHacked from unmodified sources, and then use it with any of the original Doom exes from the 90s (rather than gamesrc-ver-recreation or any other exe). This way, if there's still a problem (say in the UI), then it's probably in the compilation process; Unless there's an actual problem with the original DeHacked sources that I'm not aware of, but after many years, I'm currently having doubts.
  3. While the license is a bit different, it indeed has its own variation of the advertising clause. Here's a copy of the 4-clause BSD license for reference: https://spdx.org/licenses/BSD-4-Clause.html Since the built exe can work without binding or even using DOS/32, I'm not sure that binding DOS/32 will be considered the creation of "derivative work" as defined in the GPL. There are also the original non-GPL terms by which the Doom, Heretic and Hexen sources were originally distributed, albeit Heretic and Hexen's terms were an EULA not intended for the distribution of source code. Either way, as usual, it should better be assumed that IANAL.
  4. Renaming DOS32A.EXE to DOS4GW.EXE looks like a common approach for running older exes (which lack sources), so this might work here; Albeit I thought that the usage of the name of DOS4GW.EXE for what is actually DOS/32 can be confusing. I'm not entirely sure if this is allowed by DOS/32's license in this case, but another option might be to bind DOS/32 into the game exes. Given that it's intended for use with older EXEs from the 90s in general, it might be. https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/system/dos32a/dos32a.txt
  5. NY00123

    Doom and Strife source code restoration

    Maybe I should start by asking if a build of the unmodified DeHacked sources works as expected, without the aforementioned problems shown in the interface. If the problems are reproduced even without modifying the sources then they're probably not related to the changes. In retrospect, this might be a good example of possibly less intentional or planned manners in which gamesrc-ver-recreation code is used, which can be a good thing. In the current state, it sounds like it'll still require a custom DeHacked build for each new exe, unless something like an appropriate extension of the .DEH format (or any of my preceding suggestions) will be the way to go.
  6. 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.
  7. 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).
  8. NY00123

    Doom and Strife source code restoration

    I think that this is where what I wrote here earlier still holds: Thanks to Nuke.YKT's efforts, almost all Doom exes currently covered may theoretically be recreated with more-or-less the same layout, including how are global variables ordered. That's, of course, under the assumption that matching DMX versions (which might've been modified on their own) are used. From my understanding, a matching DOS/4GW stub will also be required for compatibility with .deh files. Currently, this will still not apply to the Doom II 1.666 prototype; Even for the rest, any little difference in the process can lead to a bit different exe, and this is sufficient for making existing .deh files incompatible; This, at least from the way I see it, might be enough for giving up on the idea, and doing something different might work better (e.g., adding a proper .deh file loader to a source port, if there isn't any).
  9. 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.
  10. NY00123

    Doom and Strife source code restoration

    Good to see you going through these, thanks. Yeah, I'm not sufficiently familiar with dehacked modding, but I still suspected that this would be the case; There are offsets which are hardcoded in dehacked and depend on the version of the Doom exe. As a consequence, as I wrote beforehand, there's no practical reason to support applying .deh files directly on top of newly built DOS exes with (a modified) dehacked. Better implement a proper Vanilla Doom compatible .deh file loader in a source port (even if the port is actually still running under DOS). Alternatively, change the sources directly.
  11. 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. 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.
  12. 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.
  13. NY00123

    Doom and Strife source code restoration

    It might indeed be a good idea to make a partial topic change, and see if anybody inspected the sources for the purpose of comparing different versions. Looking for mentions of APPVER should lead to most changes, if not all. Unless I did a mistake, I was surprised to find out the version as shown in the textual loading screen was the only difference in code between versions 1.7 and 1.7a of Doom II. The DMX code was exactly the same in v1.7, v1.7a and French v1.8; Basically dmx34a with fmfix. English v1.8 and later (including Chex Quest) used dmx37. EDIT (Feb 10 2022): Nuke.YKT realized I was a bit wrong with the dmx version for 1.7(a) and French v1.8; It's still based on dmx34a with fmfix, but also had other minor changes to the fm code. I renamed the expected directory name in doom/makefile and pushed this change. At the least, what I wrote in the other post could explain the differing reactions of people, at least partially; Albeit it probably mostly comes down to the differing levels of interests that the games have, as hinted by you. Another thing which might have an impact is the presence of a source port. If reverse-engineered code or a modification of leaked sources still targets a platform like DOS, the interest might be significantly smaller than a port to modern platforms.
  14. NY00123

    Doom and Strife source code restoration

    Another tidbit to add: Here is how can one look at it. Leaked source code should generally not be accessible to the public. On the other hand, reconstructed code, even if not clean room, can be made using at least one exe which was properly released. That is, it can be a derivative of files which were made available in expected manners. Of course, it's possible the work was done using debugging information mistakenly left in one of the exes, but it's still different (or at least, technically more difficult and time consuming) from outright copying leaked sources. In practice, we can see that even with leaked code, things apply on a case-by-case basis. From what I've seen, Witchaven as available from Steam and GOG.com is claimed to be bundled with enhancements from EGwhaven. Additionally, WitchavenGDX and TekwarGDX exist.
  15. NY00123

    Doom and Strife source code restoration

    One thing which should be done is preparing the relevant environment variables for using Watcom, like %WATCOM% or %LIB%. I probably assumed that writing the details was out of scope of the documentation for gamesrc-ver-recreation submodules, as it's more related to getting Watcom ready for use. On a second thought, I won't be surprised if out of the ones experimenting with the code, a relatively large percentage will try Watcom for the very first time (at least in a while). Secondly, looks like I missed this: I can see the desire in using a GPL-compatible toolchain for building a GPL-compatible codebase. The scope of gamesrc-ver-recreation implies that the original tools have to be used (for the purpose of near-perfect binary exe recreations), so there isn't a great deal of choice; Actually, there's often no choice at all. The sources are still there, so anybody who's interested can try to adapt them for a different toolchain. There's also Open Watcom. It's currently still not available under GPL-compatible terms, albeit I've recently found the following discussion with a proposal to change the license: https://github.com/open-watcom/open-watcom-v2/discussions/271 Blzut3's answer should probably cover most of it. That's also one of the reasons why, ignoring a few exceptions, I generally restricted gamesrc-ver-recreation to not more than recreations of other versions of code bases which were already open-sourced. I'll quote a part of one of my posts in the more general DW thread about gamesrc-ver-recreation:
  16. NY00123

    Doom and Strife source code restoration

    Yeah, this seems to be the case. As I wrote earlier, if everything is matching the original exe in layout and size, including also DOS/4GW and DMX, then no change is expected to be needed; Otherwise, The exe size and offsets will have to be adjusted, at the least. I do wonder how stable will this be. If I didn't mention it, I learnt that Watcom C (at least a version used for Heretic) may generate a bit different code even just by defining an unused environment variable; Yes, its output seems to partially depend on the environment, even if rarely. My conclusion is that if anybody wants to use gamesrc-ver-recreation as a base for a DOS port of Doom, it might be better to include a proper .deh file loader, just like the various ports to modern platforms.
  17. NY00123

    Doom and Strife source code restoration

    I'm not sufficiently familiar with idgames' history, and I currently still have a total of 0 direct uploads to idgames, so I'm not that familiar with specific rules. Is the restriction of distributing original Doom exes still in effect? Outside of Final Doom, the last DOS version of doom2.exe is also available with shareware v1.9. The exes might not be allowed due to already being a part of other archives (and since required storage may get somewhat larger as multiple copies of the same exe get uploaded). Also, generally speaking, I think that people will still prefer to let a mod be available with more than a standalone exe, be it a .deh file or source code. If it's about the Wiki, Nuke.YKT recently add a stub via this URL: https://doomwiki.org/wiki/Gamesrc-ver-recreation I might create an account and add on my own, as there's information that might otherwise not really be known. Right now, I'm not aware of a port of apodmx to platforms differing from DOS. What was ported to other platforms was the Apogee Sound System, as a part of at least a few Build Engine source ports, but probably also ROTT. JFAudioLib might be simpler to start with, while the code from EDuke32/NBlood supports OPL emulation and other additions. But it'll probably still not be something you can plug-in and get to immediately work with not more than a few minor changes. PC Speaker output will probably also not be functional for Doom, if the interest exists; That is, unless this was implemented for a ROTT source port.
  18. 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. 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:
  19. NY00123

    Doom and Strife source code restoration

    I assume that distributing a modified exe was mostly a concern for id before the game was open-sourced, and later, because of DMX, if there was any. But with having not just Linux Doom, but also the reconstructed sources (and if it matters, a DMX replacement), I don't think there should be a problem anymore. I didn't even think about applying .deh files with DeHackEd itself to any exe made via gamesrc-ver-recreation. From what I was reading, DeHackEd detects the game version by the exe size, so it's already expected to fail due to the lack of DMX or the relevant DOS/4GW stub. Even if these weren't a concern, there's more that could break. As long as everything the .deh file tells DeHackEd to change is exactly at the expected location in the exe, I think that patching will generally work, but this isn't necessarily the case. For instance, as written beforehand, global variables which aren't explicitly initialized in the C code might be ordered differently. Generally speaking, I thought about gamesrc-ver-recreation more in terms of education, as well as the ability to use the code in ports to modern platforms, mostly ones inspired by Chocolate Doom. I can't speak for other examples for DOS. DoomNew is indeed a DOS port which can use DMX, but it also has its own deviations, like support for the SimulEyes VR goggles. So, it makes sense for it to use a bit different take on the Doom name (or possibly NEWDOOM.EXE, the original name of the exe as outputted by the Watcom Linker in id Software). What's in gamesrc-ver-recreation, on the other hand, generally aims to be not more than plain source code recreations. This is why I mentioned "Vanilla Doom", because that's really what you technically get (or at least, close enough). If you're still looking for a name, I guess that something like "a part of gamesrc-ver-recreation" should work.
  20. NY00123

    Doom and Strife source code restoration

    As I wrote in the related thread beforehand, reversing Doom was something I thought about, but the lack of original Doom sources for DOS was the main blocker. Sure, I could start, and if done correctly, get to some point; The biggest problem, as usual, would probably be that differences from the original codebase for DOS would lead to a different order of global variables as a part of the BSS (i.e., variables which aren't explicitly initialized). At least there isn't much of a need for me to do it at this point. ok, I technically still can, but as expected, I currently don't have an incentive. At least from my point of view, what these code bases aim to do is grant access to reconstructed code for differing versions of games and libraries. This can be very useful for source ports inspired by Chocolate Doom, emulating the features of specific game versions in other ports, or even just studying the technical differences. Regarding the names, so far, I haven't given any unique name. For source ports, it makes sense to use separate names of ports in order to differentiate them by features. Here, however, you have gamesrc-ver-recreation, and within it, there are differing trees which are used for recreating executables with behaviors that mostly match originals. Sometimes, these are 100% the original exes if appropriately built (say for multiple Wolf3D versions). So for something like Doom, the closest matching name I may currently think of is really "Vanilla Doom". If, on the other hand, you referred to the use of APODMX, that's a good question. I'm really, really careful of making any promise, but a specific situation might change at some point (emphasis on the last few posts): https://github.com/chocolate-doom/chocolate-doom/issues/639 Regardless, for now, APODMX is an option, so maybe PCDoom/PCHeretic/PCHexen/PCStrife can work; Albeit PCHeretic is longer than 8 characters. So, maybe PCDoom/PCTic/PCHex/PCStrife? Not that I give this a high priority (at least for Heretic or Hexen), heh. Even then, it's only the sound library which is replaced; The Doom/Heretic/Hexen/Strife code remains 100% identical, outside of possible differences stemming from differing compiler or linker outputs. Indeed. It's not just for Doom. For other games and libraries which I worked on, like Wolfenstein 3D, I also had to repeatedly compare executables, at least while they weren't sufficiently matching; Comparing disassembler outputs is a good way of doing this. It tends to be easier when there isn't missing code that I need to recreate (e.g., a whole function), but there are situations in which this is required.
  21. Yeah, it has been out for quite a while. I originally added it to gamesrc-ver-recreation as an option for Hexen; This is why you can find in this thread earlier posts referring to differences in sound/music output. Nuke.YKT used it for PCDoom beforehand; He actually tested it with Heretic first. What I eventually did was reconfiguring it as a partially standalone static library, and also applying a few minor fixes. The linker still needs the Apogee Sound System, i.e., AUDIO_WF.LIB. I've edited my post to clarify the point on Ken-Build. Basically, while the Build Engine and the Ken-Build test game were originally open-sourced by Ken in June 2000, if you download the archive today, you should find really minor updates to GAME.C and BUILD.C. The updates also explain the timestamp of November 2002 for GAME.EXE. In spite of the timestamps making it clear the exe was indeed matching the sources, I didn't exactly figure out how to appropriately build the exe. This is what Ken did, following private communication involving both of us. Unless you count his website, I'm not currently aware of him being active in anything like a community for gaming; Before they were shut down, he used to post in JonoF's forums. These were eventually closed due to getting a great deal of automated spam, along with having relatively small user activity.
  22. Having some updates, both major and minor. - Thanks to Nuke.YKT's efforts, Doom and Strife are now both covered. He used the Heretic sources and other sources in order to transform Linux Doom into faithful Final Doom DOS sources. I added older Doom versions to the tree, and occasionally also assisted with Strife a bit, here and there. He created a separate thread covering Doom and Strife. See the bottom of this post for a link. - Nuke.YKT further updated the apodmx repository, i.e., his DMX wrapper that uses the Apogee Sound System. This technically impacts not just Doom or Strife, but also Heretic and Hexen. - Ken Silverman figured out how was Ken-Build's GAME.EXE (probably) built from the sources as uploaded in November 2002. So, while the code was there beforehand, I added it as an option to the BAT files and make file. - For a few exes that can be built from the duke3d tree, 3 bytes would differ before adding these linker directives: "segment type code lo", "segment type data lo". As it recently turned out, an alternative fix was the simple removal of the directive "system dos4g". Additionally, Nuke.YKT is now a part of gamesrc-ver-recreation. There might still be restrictions on what's uploaded to gamesrc-ver-recreation. For instance, a reversed engineered game is generally not covered. Exceptions are still a possibility. For instance, after Blake Stone: Planet Strike was open-sourced by Apogee, it was stated that the Aliens of Gold sources were assumed to be lost, thus explaining their lack. Therefore, I didn't mind building upon Blzut3's earlier reverse-engineering efforts, and later uploading reconstructed sources for the game.
  23. [UPDATE: Dec 31 2021] The project is titled ReflectionHLE as of writing this. Ignoring the URL, the rest of this post currently remains unedited by me. Hi all, Let me introduce you to the following source ports inspired by Chocolate Doom, now also covering Wolfenstein 3D: https://github.com/ReflectionHLE/ReflectionHLE/releases This is a 6 years anniversary release. On September 26 2014, I released a new port of Keen Dreams, initially titled "Chocolate Keen Dreams". Although Keen Dreams was released earlier in the same month, I actually started some work on it even earlier, after the Catacombs were open-sourced (in June 2014). Reason is that I already knew that a lot of the code was common. Following Keen Dreams, I added Catacomb Abyss, then Catacomb 3-D, and finally the rest of the Catacomb Adventure Series. Recently, I've been working on the source ports again. With the assistance of the gamesrc-ver-recreation/wolf3d tree, the last release introduces support for Wolfenstein 3D, Spear of Destiny (excluding the mission packs) and Super 3-D Noah's Ark (DOS version). For Wolfenstein 3D, this currently covers Apogee shareware versions 1.0, 1.1, 1.2 and 1.4 (the one with cheats), as well as 6-episodes Activision v1.4. For Spear of Destiny, this covers FormGen demo v1.0 and Activision v1.4. For Super 3-D Noah's Ark, this covers the one Wisdom Tree DOS version that I'm aware of. There are still some problems. In particular: - You can't save games or load saved games in Wolf3D and the games based on it. - These games have no support for the "modern" game controller scheme. I think that the other games should still have it, though. - For technical reasons, you can't load the Spear of Destiny mission packs. - More generally, you can't load TCs made to work with original EXEs from the 90s (as released by id and/or related publishers). I still haven't decided how to approach this. - In order to detect game data, you also need the original DOS exe (albeit the 2015 edition of Keen Dreams is an exception). - For Super 3-D Noah's Ark, this exe currently has to be named noah3dos.exe, as this is the way it arrives from Steam right now. Currently, there's no good way to support auto-detection of data with alternative file names. - The rate of palette updates in Wolfenstein 3D is at least somewhat imprecise. - VSync is disabled by default for now. There are other potential problems with timing in Wolfenstein 3D, which might partially be related to instances in which the game tries to render more often than the host display's refresh rate. - Stereo panning remains unimplemented. - For the Wolfenstein 3D based games, if you try to use a wall right after pushing it, the behaviors are essentially undefined.
  24. NY00123

    ReflectionHLE (Reflection Keen)

    A bit late reply, but I'm going to add one now: Thanks for the support! It's true that supporting more games requires more work, which can feel repetitive at times. Surely, it obviously helps that the ports use a common codebase. I also made changes at times to make ReflectionHLE code more suitable for supporting multiple games. One example is the recent replacement of the command-line options -skipintro and -showslides with the ability to select a "sub-gamever" via -gamever. A list of the possible variations can be be shown with -listgamevers. Also, as I wrote in the past, I generally prefer to not promise anything new before I'm quite sure that it'll be done. This also applies to support for other games, of course. On a comment which is more relevant to the post I'm replying to, each newly supported game is expected to require more work and time for future maintenance.
  25. NY00123

    ReflectionHLE (Reflection Keen)

    Version 0.40.0 has been released. Since Keen Dreams isn't the only supported game, the project is being renamed as of this version. It's now titled "ReflectionHLE". A side-effect of this is that you'll have to manually migrate saved games and settings. Hopefully, it shouldn't be more than copying a directory or two. See the top of the change log for details. This version has the experimental addition of keyboard and mouse button overrides. They might not always work as expected. For instance, overridden keys may become unusable for cheat codes. There's also an APK for Android again. Audio resampling isn't included in it, and there might be other problems related to audio. Generally speaking, the Android builds should be considered less supported. Dec 31, 2021 (v0.40.0): The project is renamed "ReflectionHLE" as of this version. As a side-effect, users of earlier Reflection Keen versions will have to manually migrate older settings and saved games. See paths given below. Windows: %APPDATA%\reflection-keen => %APPDATA%\reflectionhle macOS: ~/Library/Application Support/reflection-keen => ~/Library/Application Support/reflectionhle Linux - two paths (assuming $XDG_CONFIG_HOME and $XDG_DATA_HOME aren't set): ~/.config/reflection-keen => ~/.config/reflectionhle ~/.local/share/reflection-keen => ~/.local/share/reflectionhle * The project was renamed from "Reflection Keen" to "ReflectionHLE". * A single executable can now be used for running the supported games. It is identified as "ReflectionHLE". * Due to using one exe, the application icon had its game identifiers removed. * Additionally, the cfg file was split, with game-specific settings residing in their own separate cfg files. Some cfg key and value names were further renamed. Code was added for automatic migration of these from v0.33.1, but this does not cover the directories which store the cfg files and saved games. * The command-line options -skipintro and -showslides were removed. Instead, you can show the intro or slides with sub-gamever selection via -gamever. * Added the command-line option -listgamevers. It can be used for listing supported game versions, instead of -?, which doesn't do so anymore. * There's now experimental support for keyboard and mouse button overrides, applying to in-game actions during gameplay. * Note that these take a higher priority than in-game settings for the same keys. They also have a higher priority than hardcoded behaviors of them. For instance, it might be impossible to use a cheat code. You can still use a cheat code via the on-screen debug keys, though. * The on-screen keyboard with debug keys can now be displayed even if there's no use of touch input or any game controller. * Revert the impact of changes from v0.33.0 to the way controller buttons get mapped under the modern controller scheme. Instead of mapping to the default settings of a game, mapping is now done to the matching actions. For instance, in Keen Dreams, you can map a button to Jump instead of Ctrl (the default key for jumping in the original releases). This is still done in a different manner from versions preceding 0.33.0, as it's now less tied to the original games' keyboard settings. * As a side-effect, there are changes to the impacts of the analog motion toggles, even while using a D-pad. Additionally, the novert toggle should also impact vertical motion from a game controller or touch input. * Catacomb Abyss: Ensure it's possible to scroll through HELP.TXT using a game controller or touch input, even if movement keys were changed in config.abs. * General restructuring of the launcher's menus, following the support for multiple games from a single exe and the addition of key/button overrides. * Android builds are now possible again, albeit without audio resampling. Generally speaking, these builds should be considered less supported. * For technical reasons, sound output is done somewhat differently on Android. There may still be problems with audio, including delays. * Improvements to timing of sound playback during the intermission screen in Wolfenstein 3D, Spear of Destiny and Super 3-D Noah's Ark. This might be more noticeable while VSync is toggled on. * Launcher control bindings for Wolfenstein 3D and Super 3-D Noah's Ark: The weapons/feeders are now referred to by their numbers, instead of game-specific descriptions. * Emulation of mouse motion via game controllers was made less frame rate dependent. * Fix a typo impacting startup of Catacomb Apocalypse's hint book. The offset of a textual screen as present in the original exe was wrong. The bug was introduced during a refactor after the release of v0.30.1. This screen is actually used just in the electronic catalog of the supported shareware version of Catacomb Abyss, upon trying to print the catalog. * Catacombs, Wolf3D: Fix building in case "char" is an unsigned type. * Additional miscellaneous refactors, edits and fixes.
×