Yet another retro source port?

[Blzut3]

The only other developer in the Doom community who works on his port to let it run levels not really made for it is Ketmar of K8vavoom.

While I agree with this statement, this seems like a good jumping off point to ask: What about DelphiDoom? I just noticed the other day that it has a dialect of DECORATE. And knowing that now it's even funnier when people resist implementing DECORATE since that's distinct ports that implement it plus Eternity's state syntax (plus ECWolf if you want to count that). At what point will people realize it became a de facto standard?

Don't really know what to think of it myself since I only remember it exist when the topic gets bumped at Doomworld, but I would say it's mostly held back by being called DelphiDoom. Kind of undersells what it is.

[Gez]

Slightly related, but I know Hedon, the standalone game, has a custom engine port aswell based on GZDoom - But its only a few slight changes, and if i remember correctly Rachael worked on them aswell.

I don't believe the engine is actually custom. I played the mod (before it was put on Steam) with the regular build of GZDoom. But if Hedon has a tweaked executable, then Zan needs to release the source code, it's a GPL requirement.

[Graf Zahl]

The only other developer in the Doom community who works on his port to let it run levels not really made for it is Ketmar of K8vavoom.

While I agree with this statement, this seems like a good jumping off point to ask: What about DelphiDoom? I just noticed the other day that it has a dialect of DECORATE. And knowing that now it's even funnier when people resist implementing DECORATE since that's distinct ports that implement it plus Eternity's state syntax (plus ECWolf if you want to count that). At what point will people realize it became a de facto standard?

My guess? Never. The Eternity faction is too deeply entrenched into their own little world and this bogus mindset of 'standing apart'. Every time such things get mentioned the usual suspects gang up and scream "NO!"

Don't really know what to think of it myself since I only remember it exist when the topic gets bumped at Doomworld, but I would say it's mostly held back by being called DelphiDoom. Kind of undersells what it is.

TBH, DelphiDoom's biggest problem is Delphi. That port, despite all its features will always suffer from having been rewritten in a different language.

[Rachael]

Slightly related, but I know Hedon, the standalone game, has a custom engine port aswell based on GZDoom - But its only a few slight changes, and if i remember correctly Rachael worked on them aswell.

I don't believe the engine is actually custom. I played the mod (before it was put on Steam) with the regular build of GZDoom. But if Hedon has a tweaked executable, then Zan needs to release the source code, it's a GPL requirement.

I am well aware of the requirements of GPL3 concerning this particular issue, and I went out of my way to make Zan quite aware of them too, and there was no disagreement about it. You would only have to take a poke at my Github account to find it.

https://github.com/madame-rachelle/hgzdoom

I am not aware of any requirement for whether the source code must actually be advertised in the project, though, but I am sure that if it does it'll be pretty easy to talk it over with Zan and get that taken care of. Even though it is now its own fork with its own unique purpose and its own identity, it does not do things altogether differently from GZDoom outside of one internal variable that it allows the mod's scripting system to access. Besides renaming the engine, customization of its variables, and tweaks, it has no real features that should make it attractive as a stand-alone port.

[Graf Zahl]

AFAIK the GPL v3 requires that anyone offering the binary for download also must provide a ready-to-use link for the source. Linking to a Github repo would be sufficient.

[Redneckerz]

I don't believe the engine is actually custom. I played the mod (before it was put on Steam) with the regular build of GZDoom. But if Hedon has a tweaked executable, then Zan needs to release the source code, it's a GPL requirement.

It used to be based on just GZDoom, but as Rachael highlights, it moved on to a fork - hGZDoom.

According to the patchnotes: https://steamdb.info/patchnotes/4052011/ it is based off of GZDoom 4.1.3.

And here the differences are detailed: https://www.patreon.com/posts/enter-hgzdoom-28567469

1. It customizes the settings menus, removing things like network options or player options that make no sense for Hedon and are more confusing than anything.

2. It allows for a message autoscaling script to run that detects the player's screen resolution and auto adjusts the messages to a proper scale. This is very important, as reading texts is essential for Hedon, and having to ask people to go search for options to configure themselves was never a great thing. Now all of this is finally sorted out, no more need to scale text by yourselves!

3. It holds Hedon's default configurations rather than vanilla Doom's. Again very useful, especially that now you can reset to defaults directly from the settings if you mess something up, and I no longer have to rely on packing an external .ini file with the game.

Besides renaming the engine, customization of its variables, and tweaks, it has no real features that should make it attractive as a stand-alone port.

Well, here you point out exactly why i dislike the mantra ''If it does not work, Fork!'' philosophy detailed earlier. Because this port does exactly that. If stuff like this has no actual attractive features, why not post a patch or a suggestions list then? I can understand that there is a risk that Graf deems it unneeded, but if you provide all code and implementation on a platter as an optional thing, why not?

For modders who want to create a standalone title, you could aswell set up a flag to incorporate these changes. That way you can stay within GZDoom yet ship with QoL improvements. Ofcourse, besides this code you would actually have to code in said flag aswell, and i am pretty sure Graf won't do that, so Zan should provide that. But that said, i can't see why a suggestion or patch with such code presented on a platter would be insufficient.

AFAIK the GPL v3 requires that anyone offering the binary for download also must provide a ready-to-use link for the source. Linking to a Github repo would be sufficient.

A reference on the Steam page and other distribution places would be perfect, obviously.

[Graf Zahl]

The biggest issue prompting this fork has been addressed by now, i.e. changing the CVAR defaults. I'm not sure there's anything really relevant in here.

[dpJudas]

Well, here you point out exactly why i dislike the mantra ''If it does not work, Fork!'' philosophy detailed earlier. Because this port does exactly that. If stuff like this has no actual attractive features, why not post a patch or a suggestions list then? I can understand that there is a risk that Graf deems it unneeded, but if you provide all code and implementation on a platter as an optional thing, why not?

For modders who want to create a standalone title, you could aswell set up a flag to incorporate these changes. That way you can stay within GZDoom yet ship with QoL improvements. Ofcourse, besides this code you would actually have to code in said flag aswell, and i am pretty sure Graf won't do that, so Zan should provide that. But that said, i can't see why a suggestion or patch with such code presented on a platter would be insufficient.

If only it was that simple. To get things into mainstream GZD you need to go through a (relatively) long process that may not even get your changes in. If I was to release something based on GZDoom some of the first things I'd do would totally not be approved directly as-is and would require a lot of work to even get Graf to consider including it. For better or worse, GZD was made to target Doom games from the 90's and not standalone spinoffs.

[Rachael]

Well, here you point out exactly why i dislike the mantra ''If it does not work, Fork!'' philosophy detailed earlier. Because this port does exactly that. If stuff like this has no actual attractive features, why not post a patch or a suggestions list then? I can understand that there is a risk that Graf deems it unneeded, but if you provide all code and implementation on a platter as an optional thing, why not?

For modders who want to create a standalone title, you could aswell set up a flag to incorporate these changes. That way you can stay within GZDoom yet ship with QoL improvements. Ofcourse, besides this code you would actually have to code in said flag aswell, and i am pretty sure Graf won't do that, so Zan should provide that. But that said, i can't see why a suggestion or patch with such code presented on a platter would be insufficient.

I'm sorry - but I disagree vehemently here.

The changes I made to hGZDoom are things I do not want in the main GZDoom repo. For one, it does use a specific asset of Hedon, which has no place in the main GZDoom repository. Currently, GZDoom does not allow you to customize its icon, and particularly in order to do so on its executable you must use an icon replacer, or replace the icon in the source and recompile.

Second of all, there is this god-awful gruesome hack I did that would NEVER be allowed in the main GZDoom repo. I would never allow something like this if it came in a pull request. And I guarantee you neither will mental or Graf. It is a change that is made specifically for this project only. If GZDoom had to backport this, it would have to be done another way and it would be a lot more work.

The biggest issue prompting this fork has been addressed by now, i.e. changing the CVAR defaults. I'm not sure there's anything really relevant in here.

This is exactly right. Besides Hedon-specific things, there really isn't anything relevant or special there, which is the point I was trying to make with my previous post. The source is released more for compliance with the GPL than for any educational purpose. You really gain nothing out of having it, unless you want to change something that is specific to Hedon.

[Redneckerz]

The biggest issue prompting this fork has been addressed by now, i.e. changing the CVAR defaults. I'm not sure there's anything really relevant in here.

What would stop you or Zan from backporting those QoL's back to GZDoom? Because looking at the features it does differently, i am seeing very little that couldn't be taken into account by GZDoom (And for a wider purpose).

It might be personal preference obviously, so in no way am i attacking Zan's decision. I just wonder why the need for an extra fork arose (Which is to be expected considering my stance on it haha).

EDIT: And this has been iterated on by Rachael.

If only it was that simple. To get things into mainstream GZD you need to go through a (relatively) long process that may not even get your changes in. If I was to release something based on GZDoom some of the first things I'd do would totally not be approved directly as-is and would require a lot of work to even get Graf to consider including it. For better or worse, GZD was made to target Doom games from the 90's and not standalone spinoffs.

Hence why i said When presented on a platter. I can't possibly reasonably expect that a mere feature suggestion with some sample code would be sufficient for either Graf or Mental to be like: ''You know what, that's a mighty fine idea. In.''. Often this only occurs when either something truly handy is presented or a good solution to an annoying bug is found, in my experience.

I'm sorry - but I disagree vehemently here.

Im glad you do, in fact. All in all i present an argument and i try to represent that argument as sensible as possible - Ofcourse its not absolute, even though my phrasing may make it sound like it is. (This is not done on purpose. Its just how i write.)

The changes I made to hGZDoom are things I do not want in the main GZDoom repo. For one, it does use a specific asset of Hedon, which has no place in the main GZDoom repository. Currently, GZDoom does not allow you to customize its icon, and particularly in order to do so on its executable you must use an icon replacer, or replace the icon in the source and recompile.

Ill basically just build on what ive said to Judas here - I am not saying that a mere suggestion should be in, but what if the implementation is delivered as-is, ready for inclusion. What would the stance then be?

This also means replacing specific assets with a general one - That's the idea in this case of a patch anyway, to make things general for which you now had to fork specifics for. Because what you are describing in my ears should not defacto be such a hassle that you need to cast a fork out of it.

This is a hypothetical, literal definition, mind you. When taken into account how the actual situation is, obviously it makes much more sense to fork and i hope you don't think i am denying this. Just taken by a literal sense, in that imaginative perfect world, i would argue that such changes would not absolutely need a fork.

If GZDoom had to backport this, it would have to be done another way and it would be a lot more work.

And that wouldn't be on Graf/Mental obviously, but on Zan, because its outside the scope of Graf and Mental to work that out.

The biggest issue prompting this fork has been addressed by now, i.e. changing the CVAR defaults. I'm not sure there's anything really relevant in here.

Suppose someone else wants to make a standalone game and want these QoL things. Obviously they have to change these to the game they are making, but would such a thing be useful for them? I can't imagine folks making game specific forks just to apply the same thing there. So in that sense, its relevant stuff?

[Rachael]

I don't think you understand what a fork really is if you see the need to eliminate it that passionately.

A fork allows you to make modifications that are not possible under the engine's broader umbrella. As dpJudas already said, some of these changes stay under review for such a long period of time that you're lucky if they're even included at all. I know that's asking a lot of the rest of the GZDoom team to change but they actually can't be faulted for it because GZDoom is, after all, a hobby project and nobody is getting paid for it.

And just remember without forks you would not have browsers like Firefox, Seamonkey, Palemoon, Chrome, Chromium, Brave, Electron, Dullahan, and many others which are, in fact, forks of some previous browser. Without forks you would not even have GZDoom, ZDoom, Eternity Engine, or others - all forked from Doom's source code. Forks are not a threat to you - they simply occur when someone wants to quickly build on top of a source code release and add features or fix bugs. And continuing the browsers example - the process that created Electron and Dullahan created functional web browsers with a completely different purpose - in Electron's case it allows a browser to be used as an application (ie Discord and many game launchers you see in use today) and for Dullahan it actually allows you to have web browsers within a game.

[Graf Zahl]

There is nothing here. The entire changes consist of different defaults for CVARs, removal of some menus that have no meaning for Hedon and the executable icon. There's simply nothing to backport here. Otherwise I'd already have done it.

But Reality Check: That's SOP if you want to do a commercial release. It's unprofessional to ship a generic engine without your own icon and other outward facing parts that give the game its identity.
Ion Fury did the same with EDuke32 - they disabled some code the game did not need and replaced the icon and other identifying marks. The game itself can still be played with the base engine, the custom one got nothing the base one does not have, quite the opposite in fact.

[Rachael]

There's simply nothing to backport here. Otherwise I'd already have done it.

You probably would not even need to go that far. Everything that I've ever done for actual features in commercial engines, I've put in a pull request for GZDoom. Whether or not it got accepted is another story, but the point remains, I preemptively backport it already, anyhow.

[Redneckerz]

I don't think you understand what a fork really is if you see the need to eliminate it that passionately.

Do note that i speak from a general hypothetical sense, not a specific sense here. Ofcourse i would know what a fork is on the basic level, and i understand the necessity of hGZDoom - Because it allows for things that you wouldn't be able to get rid of in the general codebase, hence why you fork.

That's not what i am at, mind you.

A fork allows you to make modifications that are not possible under the engine's broader umbrella. As dpJudas already said, some of these changes stay under review for such a long period of time that you're lucky if they're even included at all. I know that's asking a lot of the rest of the GZDoom team to change but they actually can't be faulted for it because GZDoom is, after all, a hobby project and nobody is getting paid for it.

Absolutely. Hence why i was saying otherwise - Just merely dropping a suggestion and a small example to add QoL would inevitably be rejected, because it means more work for the GZDoom team. My hypothetical scenario was more, if it were to be presented on a platter, fully functional, would it still see such rejection?

Ultimately it does not really matter nor do i condemn hGZDoom in a realistic sense. It serves a purpose, and that's whats most important. The whole rant from me about unnecessary forking is purely just that, theory and argument. After all, that's the question raised by the topic title.

And just remember without forks you would not have browsers like Firefox, Seamonkey, Palemoon, Chrome, Chromium, Brave, Electron, Dullahan, and many others which are, in fact, forks of some previous browser. Without forks you would not even have GZDoom, ZDoom, Eternity Engine, or others - all forked from Doom's source code. Forks are not a threat to you - they simply occur when someone wants to quickly build on top of a source code release and add features or fix bugs. And continuing the browsers example - the process that created Electron and Dullahan created functional web browsers with a completely different purpose - in Electron's case it allows a browser to be used as an application (ie Discord and many game launchers you see in use today) and for Dullahan it actually allows you to have web browsers within a game.

I wouldn't disagree. But i would argue that each of the forks you mentioned add significantly compared to its source release and in various ways. That makes a fork more valueable. I understand this stuff is rather vague and i am having difficulties explaining this properly, but lets just be loud and clear - I am not opposed to Forks in general, heck, i love a good fork every day of the week. (Are we still talking about software forks or the stuff you use at diner? )

There is nothing here. The entire changes consist of different defaults for CVARs, removal of some menus that have no meaning for Hedon and the executable icon. There's simply nothing to backport here. Otherwise I'd already have done it.

But Reality Check: That's SOP if you want to do a commercial release. It's unprofessional to ship a generic engine without your own icon and other outward facing parts that give the game its identity.
Ion Fury did the same with EDuke32 - they disabled some code the game did not need and replaced the icon and other identifying marks. The game itself can still be played with the base engine, the custom one got nothing the base one does not have, quite the opposite in fact.

I get that - No worries there!

[dpJudas]

My hypothetical scenario was more, if it were to be presented on a platter, fully functional, would it still see such rejection?

Yes. That is often what happens. My initial true color renderer PR for ZDoom was rejected (can't remember anymore why, but it was). My homing missile fix for Descent Rebirth was rejected (due to the maintainers there not being good at math and me not willing to fight for the bug fix by demonstrating why they were wrong).

There are a lot of small things that can cause a pull request to get rejected, including not knowing the contributor very well and not being sure if they will maintain what you accept. Once something is accepted into GZD it becomes the project's problem if it got problems. As a rule of thumb, the larger a change is and the less known the contributor is, the more likely the PR will be rejected unless it is 110% made exactly like the project maintainers imagine it should be. Developers are people too and sometimes it isn't worth the effort to get things merged upstream if your personal benefit isn't great enough.