[For Forks/Other Devs] Doom 64 Support

Post a reply

Smilies
:D :) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :wink: :geek: :ugeek: :!: :?: :idea: :arrow: :| :mrgreen: :3: :wub: >:( :blergh:
View more smilies
BBCode is ON
[img] is OFF
[url] is ON
Smilies are ON
Topic review
   

Expand view Topic review: [For Forks/Other Devs] Doom 64 Support

Re: [For Forks/Other Devs] Doom 64 Support

by Blzut3 » Mon Jun 27, 2022 1:06 am

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

Re: [For Forks/Other Devs] Doom 64 Support

by Redneckerz » Fri Jun 24, 2022 2:11 pm

Well, there is DZDoom, which is (old) GZ getting the D64 rendering features going. And then the projects already mentioned.

Re: [For Forks/Other Devs] Doom 64 Support

by Rachael » Fri Jun 24, 2022 3:33 am

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.
I hope you're right. :)

Re: [For Forks/Other Devs] Doom 64 Support

by Kinsie » Fri Jun 24, 2022 3:32 am

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

Re: [For Forks/Other Devs] Doom 64 Support

by Rachael » Fri Jun 24, 2022 3:03 am

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.
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.
I think the biggest one
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.

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.

Re: [For Forks/Other Devs] Doom 64 Support

by Graf Zahl » Fri Jun 24, 2022 1:46 am

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.

Re: [For Forks/Other Devs] Doom 64 Support

by Kinsie » Fri Jun 24, 2022 1:32 am

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

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

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

Re: [For Forks/Other Devs] Doom 64 Support

by Gez » Fri Jun 24, 2022 1:22 am

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

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.

Re: [For Forks/Other Devs] Doom 64 Support

by Rachael » Fri Jun 24, 2022 12:51 am

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.

Re: [For Forks/Other Devs] Doom 64 Support

by Graf Zahl » Fri Jun 24, 2022 12:48 am

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!

Re: [For Forks/Other Devs] Doom 64 Support

by Kinsie » Fri Jun 24, 2022 12:43 am

Graf Zahl wrote:Strife is no longer a problem because its reconstructed source has been released under the GPL.
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.

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.

Re: [For Forks/Other Devs] Doom 64 Support

by Graf Zahl » Fri Jun 24, 2022 12:33 am

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.
Let's clear up a few things here:

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.

[For Forks/Other Devs] Doom 64 Support

by Kinsie » Fri Jun 24, 2022 12:09 am

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!)

Top