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

NY00123

Members
  • Content count

    72
  • Joined

  • Last visited

2 Followers

About NY00123

  • Rank
    Mini-Member

Recent Profile Visitors

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

  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. 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).
  7. 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).
  8. 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.
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. 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.
  14. 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:
  15. 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.
×