[For Forks/Other Devs] Doom 64 Support
Moderator: GZDoom Developers
-
- Posts: 7402
- Joined: Fri Oct 22, 2004 9:22 am
- Graphics Processor: nVidia with Vulkan support
- Location: MAP33
[For Forks/Other Devs] Doom 64 Support
Doom 64 is now available in legal, DRM-free form and a mostly-accurate reverse-engineering is present as the old Doom 64 EX source code. There's a great project for crowbarring the IWAD into compliance with GZDoom in the form of Doom CE, but anything that reduces user friction and "completes the set" of supported PC Doom games would be brilliant.
Sadly, it doesn't look like this will happen via the official GZDoom development team - Graf and Rachael have thoroughly [No]'d the subject citing legal issues surrounding reverse-engineering of closed-source games... that strangely haven't affected the continued support for Strife or Raze's versions of Blood and Powerslave, which are all in pretty much the exact same boat of being based off reverse-engineerings following the seemingly-permanent loss of source code to the ages. (Those fears in addition also seem relatively unfounded in regards to stuff Zenimax owns, as they tend to either stay their hand on or actively support community matters - we're not talking GTA and its protective-to-the-point-of-vindictive rights holders here - but I digress...)
Rather, this thread is more of a request to third-parties who've meddled with the engine in one way or another to provide their own implementation, either as a pull request or (more likely) a specialized fork. Such support would provide new playgrounds for gameplay modders to explore and reinterpret (I'm sure Zik's already preparing to bring Hideous Destructor to those darkened corridors...) while also providing an additional highlight for Doom 64's nascent custom mapping community and the magnificent things falling out of it.
I'm also aware that it's not just the flick of a switch though, and convincing GZDoom to interpret Doom 64's map format and macro script systems may well be more trouble than its worth, even with many equivalent features (gradient lighting, ACS etc.) already in the engine. I'd love to hear from engine experts whether such a thing is even feasible within the engine's architecture - things that seem simpler than this are often just not plausible for a host of reasons, so it'd be understandable.
(I don't know where Feature Requests for forks/third parties go, please move to General or where-ever if it should be somewhere other than Feature Requests. Sorry for the hassle!)
Sadly, it doesn't look like this will happen via the official GZDoom development team - Graf and Rachael have thoroughly [No]'d the subject citing legal issues surrounding reverse-engineering of closed-source games... that strangely haven't affected the continued support for Strife or Raze's versions of Blood and Powerslave, which are all in pretty much the exact same boat of being based off reverse-engineerings following the seemingly-permanent loss of source code to the ages. (Those fears in addition also seem relatively unfounded in regards to stuff Zenimax owns, as they tend to either stay their hand on or actively support community matters - we're not talking GTA and its protective-to-the-point-of-vindictive rights holders here - but I digress...)
Rather, this thread is more of a request to third-parties who've meddled with the engine in one way or another to provide their own implementation, either as a pull request or (more likely) a specialized fork. Such support would provide new playgrounds for gameplay modders to explore and reinterpret (I'm sure Zik's already preparing to bring Hideous Destructor to those darkened corridors...) while also providing an additional highlight for Doom 64's nascent custom mapping community and the magnificent things falling out of it.
I'm also aware that it's not just the flick of a switch though, and convincing GZDoom to interpret Doom 64's map format and macro script systems may well be more trouble than its worth, even with many equivalent features (gradient lighting, ACS etc.) already in the engine. I'd love to hear from engine experts whether such a thing is even feasible within the engine's architecture - things that seem simpler than this are often just not plausible for a host of reasons, so it'd be understandable.
(I don't know where Feature Requests for forks/third parties go, please move to General or where-ever if it should be somewhere other than Feature Requests. Sorry for the hassle!)
-
- Lead GZDoom+Raze Developer
- Posts: 49146
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: [For Forks/Other Devs] Doom 64 Support
Let's clear up a few things here:Kinsie wrote:Sadly, it doesn't look like this will happen via the official GZDoom development team - Graf and Rachael have thoroughly [No]'d the subject citing legal issues surrounding reverse-engineering of closed-source games... that strangely haven't affected the continued support for Strife or Raze's versions of Blood and Powerslave, which are all in pretty much the exact same boat of being based off reverse-engineerings following the seemingly-permanent loss of source code to the ages.
1. Strife is no longer a problem because its reconstructed source has been released under the GPL.
2. The Build games are also not an immediate issue because Build engines cannot be used for profit due to the Build license.
Putting Doom64 into GZDoom is different, because there is no legally released Doom64 code under a permissive license. The new version of the game came without source release so for all intents and purposes all original licenses still apply, even to Kaiser's code, making it incompatible with GZDoom's GPL v3. The real issue is that if this code ends up in a commercially used product it can become a huge legal problem for anyone involved into making games with GZDoom, and that's not to be taken lightly.
-
- Posts: 7402
- Joined: Fri Oct 22, 2004 9:22 am
- Graphics Processor: nVidia with Vulkan support
- Location: MAP33
Re: [For Forks/Other Devs] Doom 64 Support
Does GZDoom use that code specifically, though? Or is it an earlier reverse-engineering? I seem to remember the earliest stages of ZDoom's Strife support emerging long before Chocolate Strife (which is the official codebase used and developed by Strife's current rights holders) was a glimmer in the eye. I'm not sure how much that would effect things legally, but it'd be a concern if Night Dive weren't being chill about such matters.Graf Zahl wrote:Strife is no longer a problem because its reconstructed source has been released under the GPL.
But either way, you're not interested in the idea and don't want to do it. That's a far more understandable reason, in my eyes, because this is a hobby project above all else and there's only so much time to devote to such things. Maybe someone else wants to give it a crack as a fork, though? Hence this thread.
-
- Lead GZDoom+Raze Developer
- Posts: 49146
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: [For Forks/Other Devs] Doom 64 Support
Don't split hairs. Of course it's an earlier reverse engineering - or to be precise - in part it may even be from the same reverse engineering (i.e. SVStrife.) But that doesn't change the fact that Strife's source is available under a permissive license while Doom 64's is clearly not!
-
- Posts: 13741
- Joined: Tue Jan 13, 2004 1:31 pm
- Preferred Pronouns: She/Her
Re: [For Forks/Other Devs] Doom 64 Support
Here's something also to consider: Doom 64 EX is a reverse engineering project, it is not the OFFICIAL NIGHTDIVE source, and that goes even if it is by the same author. That's what makes it legally dubious - despite its connection to the rights holder, it's not sanctioned by said rights holder. For all intents and purposes it's a past side project.
If Nightdive is willing to bless and put their name the earlier Doom 64 EX project (it is after all made by one of their employees), this would change things a lot. And if Nightdive has the full rights to do this and can give the legal clear, that will probably clear a lot of hurdles. (Does Nightdive have the full rights to do this?)
Of course it would be even better if the real Doom 64 source code (the current version) were released since that would avoid the need of even more reverse engineering for the current file/layout structures, if they have indeed changed at all. (I haven't looked, so I don't know) - at least documenting these for source ports (*by* Nightdive themselves, or at least willing to publish and sanction it somehow if someone else does it), if Nightdive is unwilling to release the official PC Doom64 source - would be necessary. Basically the deal is: This can't be reverse-engineered, even the file structures themselves, in order to officially be a part of GZDoom.
P.S.: And just so we're clear: the "what-about-ism" bullshit that happened in the Github thread will not be tolerated here - if that shit continues it will be met with tempbans at the very least. Make your arguments logical and constructive - the moment they turn into attacks, I will not be showing any mercy - you should know better by now.
If Nightdive is willing to bless and put their name the earlier Doom 64 EX project (it is after all made by one of their employees), this would change things a lot. And if Nightdive has the full rights to do this and can give the legal clear, that will probably clear a lot of hurdles. (Does Nightdive have the full rights to do this?)
Of course it would be even better if the real Doom 64 source code (the current version) were released since that would avoid the need of even more reverse engineering for the current file/layout structures, if they have indeed changed at all. (I haven't looked, so I don't know) - at least documenting these for source ports (*by* Nightdive themselves, or at least willing to publish and sanction it somehow if someone else does it), if Nightdive is unwilling to release the official PC Doom64 source - would be necessary. Basically the deal is: This can't be reverse-engineered, even the file structures themselves, in order to officially be a part of GZDoom.
P.S.: And just so we're clear: the "what-about-ism" bullshit that happened in the Github thread will not be tolerated here - if that shit continues it will be met with tempbans at the very least. Make your arguments logical and constructive - the moment they turn into attacks, I will not be showing any mercy - you should know better by now.
-
-
- Posts: 17924
- Joined: Fri Jul 06, 2007 3:22 pm
Re: [For Forks/Other Devs] Doom 64 Support
The Strife-VE release makes the Strife support code retroactively a non-issue. As for Raze, it hasn't been used for any commercial game, and its license prohibits such a thing.Kinsie wrote:Sadly, it doesn't look like this will happen via the official GZDoom development team - Graf and Rachael have thoroughly [No]'d the subject citing legal issues surrounding reverse-engineering of closed-source games... that strangely haven't affected the continued support for Strife or Raze's versions of Blood and Powerslave, which are all in pretty much the exact same boat of being based off reverse-engineerings following the seemingly-permanent loss of source code to the ages. (Those fears in addition also seem relatively unfounded in regards to stuff Zenimax owns, as they tend to either stay their hand on or actively support community matters - we're not talking GTA and its protective-to-the-point-of-vindictive rights holders here - but I digress...)
Several years ago there was an attempt (by Blzut3 and myself) at making a fork of ZDoom to load the IWAD generated by Doom64 EX's wadgen. The map format wasn't too much of a hassle (though a lot of rendering stuff was left unimplemented), and the macro system wasn't a big issue either (I had hacked in a quick draft VM that handled enough of the stuff to make Staging Area's macro work). Back then there was the hindrance of not being able to look at the Doom64 EX source code (it was GPL and it was still in the ZDoom days of the GPL-incompatible license mess) so we were working from the "Doom 64 Tech Bible" PDF that Kaiser had published.Kinsie wrote:I'm also aware that it's not just the flick of a switch though, and convincing GZDoom to interpret Doom 64's map format and macro script systems may well be more trouble than its worth, even with many equivalent features (gradient lighting, ACS etc.) already in the engine. I'd love to hear from engine experts whether such a thing is even feasible within the engine's architecture - things that seem simpler than this are often just not plausible for a host of reasons, so it'd be understandable.
The problems were in handling correctly the cosmetic stuff. Doom 64's switches, for example, are composited on the fly. And that's something that EX got wrong, so we can't really use it as a reference. There are texture mirroring flags on sidedefs, so that's one more thing to handle in the renderer. And most importantly, I had, and still have, no idea how to handle the skies. There's the firesky issue and then the rest of the skies are built with a complex skybox system. No idea how compatible it is with looking up and down.
-
- Posts: 7402
- Joined: Fri Oct 22, 2004 9:22 am
- Graphics Processor: nVidia with Vulkan support
- Location: MAP33
Re: [For Forks/Other Devs] Doom 64 Support
I'd imagine Id Software would have at least some say since they managed the re-release. Again, though, their corporate masters seem willing to let a lot of stuff slide with people hacking on and reversing their games, to the point of patching the Steam release of Daggerfall to better align with the expectations of a popular Unity-based reversal/rewrite project. It might be possible to get at least an informal thumbs-up from Id, if you're willing to attract potentially-unwelcome attention...Rachael wrote:If Nightdive is willing to bless and put their name the earlier Doom 64 EX project (it is after all made by one of their employees), this would change things a lot. And if Nightdive has the full rights to do this and can give the legal clear, that will probably clear a lot of hurdles. (Does Nightdive have the full rights to do this?)
One possibility for ensuring legal comfort for standalone gamedevs could be to use a preprocessor or other switch to disable/remove Doom 64 support from a build.
I don't think a release for the modern version is currently possible since it would include console-SDK-centric code and also the latest version of the KEX stuff, which is currently Night Dive's Secret Sauce (for now at least) and also, IIRC, extremely console-SDK-laden.Rachael wrote:Of course it would be even better if the real Doom 64 source code (the current version) were released since that would avoid the need of even more reverse engineering for the current file/layout structures, if they have indeed changed at all. (I haven't looked, so I don't know)
I believe the IWAD is mostly the same formats-wise between EX and the official release, with most of the improvements being on the code side with an aim towards compatibility with the original demo recordings, which isn't hugely relevant to GZDoom for a number of reasons (least of all being that they're built around N64 controller inputs!). I think the biggest one - and I'm sure I'll be getting a few Discord PMs correcting me if I'm wrong - is that sound effects are now handled the same way they are in every other Doom game instead of as MIDI files playing a single note from the game's custom soundfont.
-
- Lead GZDoom+Raze Developer
- Posts: 49146
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: [For Forks/Other Devs] Doom 64 Support
See, there's lots of technical issues to solve, aside from the legal ones. And many of them cannot be solved with Doom64Ex's source, because it differs too much from the new version, never mind that we probably never get this legally cleared anyway.
Adding support for extracted old ROM IWADs is something I have zero interest in, because all that'd lead to is people pirating the game instead of buying it - what is interesting is supporting the new releases. But to do that properly we'd need source that isn't available - and probably won't ever be, which makes the projct DOA for now.
Adding support for extracted old ROM IWADs is something I have zero interest in, because all that'd lead to is people pirating the game instead of buying it - what is interesting is supporting the new releases. But to do that properly we'd need source that isn't available - and probably won't ever be, which makes the projct DOA for now.
-
- Posts: 13741
- Joined: Tue Jan 13, 2004 1:31 pm
- Preferred Pronouns: She/Her
Re: [For Forks/Other Devs] Doom 64 Support
This isn't a terrible idea - but I am sure there are better solutions. I think one might be - to separate the whole entire thing as its own little subproject (like how game_support.pk3 is built) - and have the option to replace the files in question with stubs in order to avoid linker errors. Even with this suggestion though, I don't think the idea is completely out of the woods quite yet.Kinsie wrote:One possibility for ensuring legal comfort for standalone gamedevs could be to use a preprocessor or other switch to disable/remove Doom 64 support from a build.
Gez listed a number of issues which I find concerning. Nothing that's a deal killer of course - they can all be worked around and fixed.I think the biggest one
Also - thanks for correcting me about who owns the rights to the game. I forgot that it was id/Bethesda and that Nightdive really just did the work.
--
These still ignore the biggest issue by far: Someone still needs time, desire, interest, and knowledge (or at least determination) to do this. Inviting fork developers to do this really isn't a bad idea with the legal grayness of the whole thing - the only problem is there aren't a lot of prominent fork developers who work with the GZDoom engine. I think it's basically myself, drfrag (if he still does it), Nash, SanyaWaffles (maybe? I dunno how much she changes in her's but her projects get listed as WIGZDoom at any rate), Cooke with QZDoom (but that's really just a testbed for GZDoom anyway) plus whatever random projects do that's basically little more than a rebrand of GZDoom to whatever game they are bundled with. If someone had the time and desire to work with a GZDoom fork that does this, they'd likely be at least as prominent as the people I've listed here, but I'd love to be proven wrong.
And Graf isn't wrong - there's a lot of grayness over it, even if Bethesda does not "usually" go after people who reverse engineer their games. For anyone who's doing their damnedest to avoid a lawsuit, the assurances that Bethesda "does not care" is nowhere near as comforting as Bethesda directly saying it themselves. There's a lot of indie studios (outside of GZDoom too) who would go under at even a sneeze of a possible lawsuit coming - so avoiding legal quagmires is important.
-
- Posts: 7402
- Joined: Fri Oct 22, 2004 9:22 am
- Graphics Processor: nVidia with Vulkan support
- Location: MAP33
Re: [For Forks/Other Devs] Doom 64 Support
Stranger things have happened. Stranger things are happening. (Seriously, that whole lightmapping thing is nuts.) And stranger things will probably continue to happen in the future.Rachael wrote:These still ignore the biggest issue by far: Someone still needs time, desire, interest, and knowledge (or at least determination) to do this. Inviting fork developers to do this really isn't a bad idea with the legal grayness of the whole thing - the only problem is there aren't a lot of prominent fork developers who work with the GZDoom engine. I think it's basically myself, drfrag (if he still does it), Nash, SanyaWaffles (maybe? I dunno how much she changes in her's but her projects get listed as WIGZDoom at any rate), QZDoom (but that's really just a testbed for GZDoom anyway) plus whatever random projects do that's basically little more than a rebrand of GZDoom to whatever game they are bundled with. If someone had the time and desire to work with a GZDoom fork that does this, they'd likely be at least as prominent as the people I've listed here, but I'd love to be proven wrong.
-
- Posts: 13741
- Joined: Tue Jan 13, 2004 1:31 pm
- Preferred Pronouns: She/Her
Re: [For Forks/Other Devs] Doom 64 Support
I hope you're right.Kinsie wrote:Stranger things have happened. Stranger things are happening. (Seriously, that whole lightmapping thing is nuts.) And stranger things will probably continue to happen in the future.
-
- Spotlight Team
- Posts: 1085
- Joined: Mon Nov 25, 2019 8:54 am
- Graphics Processor: Intel (Modern GZDoom)
Re: [For Forks/Other Devs] Doom 64 Support
Well, there is DZDoom, which is (old) GZ getting the D64 rendering features going. And then the projects already mentioned.
-
-
- Posts: 3167
- Joined: Wed Nov 24, 2004 12:59 pm
- Graphics Processor: ATI/AMD with Vulkan/Metal Support
Re: [For Forks/Other Devs] Doom 64 Support
Actually I wasn't even aware Kaiser wrote that document, but I was in communication with Kaiser on IRC while doing that. At the point we were at the only things in Doom 64 Ex I cared about were the map data structure layouts and state tables/magic numbers. Stuff that has only one right answer. I was primarily interested in trying to force the software renderer to render the maps and it's not like Doom 64 Ex's code was going to offer any help there.Gez wrote:Back then there was the hindrance of not being able to look at the Doom64 EX source code (it was GPL and it was still in the ZDoom days of the GPL-incompatible license mess) so we were working from the "Doom 64 Tech Bible" PDF that Kaiser had published.