The future of GZdoom [GEC] to DZdoom by [GEC]

[Erick194]

Greetings to all, long ago I have an ambitious goal, but I do not want to leave out all those who cannot run the latest versions of Gzdoom.  I will start to modify any of these 2 ports which are maintained by @drfrag, these are Zdoom32 which is the closest thing to the version I used in for my previous project Gzdoom [GEC], which was set to run the PSXDOOM maps and DOOM64 in UDMF but with an environment similar to the original game, although not perfect, and LZdoom that has zscript and other improvements more similar to the current versions.  I need to know what should be the most ideal version for DZdoom, please leave a comment because the engine I select should be chosen.

[taufan99]

I think LZDoom might fit if you're looking to achieve more complex accuracy.

[VGA]

LZDoom is newer and better!

[seed]

Ye, I think LZDoom is the right port to choose between the two, as drfrag backported a lot of features to keep it in line with mainline, while remaining capable of running on potatoes.

 

However, he already stated that he's retiring it with another ZDoom-based project.

[ReaperAA]

I think LZdoom should be used because it has ZScript and other modern GZDoom modding features.

 

2 hours ago, seed said:

However, he already stated that he's retiring it with another ZDoom-based project.

 

"Another" fork? There are like 4 or 5 forks of ZDoom made by Dr. Frag already.

[drfrag]

Why do you type DZdoom instead of DZDoom?

The poll result was to be expected as ZDoom32 is far less popular. As i told you it depends on what you want to achieve, is it meant to run mods? Do you want to keep shaders working on GL2 hardware? With ZDoom32 you could save yourself a lot of work probably but then you could also port your shaders to LZDoom's legacy render path and keep both shader systems maybe.

 

The idea was to do some kind of ZDoom reboot based on dpJudas' polybackend but in the end i'll keep the LZDoom name and the GL renderer, but it's based on a modern GZDoom and it's up to date. Soon i won't be able to maintain the GL2 renderer, well i'm about to discontinue the g3.3mgw branch i mean since the code has diverged so much that i can't port all the new stuff: for instance sheet fonts don't work but surprisingly widescreen title graphics were portable and seems they work.

This is meant to keep supporting 32 bit systems besides being and alternative fork with some different features such as something really heretical i added recently. It keeps the classic ZDoom UI too.

2 hours ago, ReaperAA said:

"Another" fork? There are like 4 or 5 forks of ZDoom made by Dr. Frag already.

That not counting Chocolate ZDoom 2.1.8, but i think i'll keep the ZDoom Classic name. Now i'm playing NOVA III using it, seems it's the only way to avoid playing with BD for me, the temptation of loading it is too strong.

[seed]

3 hours ago, ReaperAA said:

"Another" fork? There are like 4 or 5 forks of ZDoom made by Dr. Frag already.

 

What can I say, he's a busy man I guess :p .

 

55 minutes ago, drfrag said:

Soon i won't be able to maintain the GL2 renderer

 

So the new fork won't be GL2 compatible anymore? Then in what ways is it going to differ from mainline then? Just less feature rich?

 

I would prefer DZDoom to be rebased in a new version tbh, I don't see the point of sticking to GL2 since the user base of people running such ancient hardware that isn't even GL3 compatible is just too small - and not worth sacrificing modern hardware for the ancient, but hey, it's Erick's project not mine, just my 0.02$.

[Redneckerz]

8 hours ago, Erick194 said:

Greetings to all, long ago I have an ambitious goal, but I do not want to leave out all those who cannot run the latest versions of Gzdoom.  I will start to modify any of these 2 ports which are maintained by @drfrag, these are Zdoom32 which is the closest thing to the version I used in for my previous project Gzdoom [GEC], which was set to run the PSXDOOM maps and DOOM64 in UDMF but with an environment similar to the original game, although not perfect, and LZdoom that has zscript and other improvements more similar to the current versions.  I need to know what should be the most ideal version for DZdoom, please leave a comment because the engine I select should be chosen.

DZDoom = GZDoom 1.91.

ZDoom32 = GZDoom 1.91. So obviously, they are similar, but ZD32 is more of an incremental update to DZDoom as it stands.

LZDoom =  Similar to latest GZDoom, but towards better legacy support. So with ZScript and what not.

 

Conclusion:

• For an incremental update that won't deviate/change much further going forward, pick ZDoom32.
• For a bigger upgrade that may see support being stopped as per @seed's post, pick latest LZDoom, if 3.85 is the last build to be released with OpenGL 2.0 support. Recommended.

Alternatives:

• Move to a more modern GZDoom build but still retain some legacy support. GZDoom 3.4/3.4.1 is the last to support OpenGL 2.0 (That is also in GZDoom 1.9.1). This would bring a huge update in general, but you will have locked in support (as this is also a legacy build). Do note that LZDoom also has OpenGL 2.0 support, this is just mentioned because its an official GZDoom build.
• Move to Zandronum to include multiplayer. It does mean you have to downgrade slightly in feature support though, as Zandro is GZDoom 1.8.6 based.

 

3 hours ago, ReaperAA said:

I think LZdoom should be used because it has ZScript and other modern GZDoom modding features.

"Another" fork? There are like 4 or 5 forks of ZDoom made by Dr. Frag already.

Indeed. It has taken some time to describe the various performance tiers drfrag targets.

 

29 minutes ago, drfrag said:

The idea was to do some kind of ZDoom reboot based on dpJudas' polybackend but in the end i'll keep the LZDoom name and the GL renderer, but it's based on a modern GZDoom and it's up to date.

Similarly to your new ZDoom CL port, this aids to the confusion, and if you want to keep it that way, you really have to specifiy which version will be the latest vintage version and the new modern version.

 

So this is why i strongly recommend, especially in LZDoom's case, to pick a new name for the new fork. There are quite a few LZDoom users out there, myself included, that rely on an updated codebase and a legacy GL renderer. I know, woe is me for having anemic hardware.

 

I can also imagine this will affect the ZDoom homepage aswell - LZDoom is listed primarly for the lower-end fallback. Moving to modern GZDoom and dropping the GL2 renderer effectively means a fork of current GZDoom, codewise.

29 minutes ago, drfrag said:

Soon i won't be able to maintain the GL2 renderer, well i'm about to discontinue the g3.3mgw branch i mean since the code has diverged so much that i can't port all the new stuff: for instance sheet fonts don't work but surprisingly widescreen title graphics were portable and seems they work.

So which LZDoom version will be the last? The current 3.85 version or 3.86?

29 minutes ago, drfrag said:

That not counting Chocolate ZDoom 2.1.8, but i think i'll keep the ZDoom Classic name. Now i'm playing NOVA III using it, seems it's the only way to avoid playing with BD for me, the temptation of loading it is too strong.

Please don't. Your ports are used by others - targetting a general audience. Such an audience is not going to know why LZDoom Next-Gen or ZDoom CL New Version suddenly do not run anymore/introduce previously unknown issues, because they retain the same name.

 

This is why i  recommend a new name. For the sake of clarity, for both users and helpers.

[drfrag]

It's meant to keep support for 32 bit systems in the future. It will be feature complete minus Vulkan and software oriented. Well that's the idea.

In some countries some people still can't afford GL3 hardware plus he has his own set of shaders for that hardware, he could recreate them tough.

[Redneckerz]

2 minutes ago, drfrag said:

It's meant to keep support for 32 bit systems in the future. It will be feature complete minus Vulkan and software oriented. Well that's the idea.

In some countries some people still can't afford GL3 hardware plus he has his own set of shaders for that hardware, he could recreate them tough.

So, GZDoom, for 32 bits, minus Vulkan, software oriented (Using Soft poly backend).

 

That does not really sound like GZDoom nor LZDoom :P

 

Maybe call it SZDoom because of it's software rendered nature?

[drfrag]

The idea at first was to give it the NZDoom name and be software only. But Blzut3 suggested keeping the already well known name, i merged the LZDoom code anyway and we have a logo besides changing names will add more confusion.

The new classic version is just ZDoom 2.1.7 with a few fixes and an early D3D backend to allow it to run on modern systems, and a couple of QOL additions. I just can't give it the ZDoom name but it's meant to preserve that old version there's not really much to it. Old GZDoom versions still run fine on modern systems (but not in software) so no enhancements this time. I said i was not happy with the previous classic version, i added too much junk.

[seed]

Hm, it sounds pretty stripped down then, if it isn't that feature rich and also being Software oriented.

[drfrag]

Why? The GL renderer it's still fully featured.

ZDoom32 is based on a later 1.9.x renderer so it's not the same, and a late ZDoom codebase.

LZDoom is based on GZ 3.3.x but i ported a ton of later stuff. Using an older GZDoom doesn't make sense even if it's official, when things got hacky was when the localization feature was added in GZ 4.0.0. But those hacks are not too bad and later i fixed old bugs too.

 

[Redneckerz]

12 minutes ago, drfrag said:

The idea at first was to give it the NZDoom name and be software only.

You joked a few times with that name. I would have prefered if this was the definitive name.

12 minutes ago, drfrag said:

But Blzut3 suggested keeping the already well known name, i merged the LZDoom code anyway

So LZDoom's intent and purpose is heavily changed to a different purpose (Namely, 32 bit/software backend versus lower end GL support) but the name remains.

 

Either i am missing something here but that just adds to the confusion. People using LZDoom and upgrading to this new build will wonder:

• why GL 2.0 is gone
• why performance is suddenly so bad
• why the game does not look polished

I am not saying this to bully you in any way, i am simply at a loss why Blzut3 of all people would suggest retaining the name given the focus of the port is vastly different now.

 

A LZDoom logo is nice though ;)

 

12 minutes ago, drfrag said:

besides changing names will add more confusion.

 

How is changing the name of the port because its vastly different from current LZDoom more confusing than retaining the LZDoom name, despite it being vastly different from current LZDoom?

 

12 minutes ago, drfrag said:

The new classic version is just ZDoom 2.1.7 with a few fixes and an early D3D backend to allow it to run on modern systems, and a couple of QOL additions. I just can't give it the ZDoom name but it's meant to preserve that old version there's not really much to it.

So that's similar to older ZDoom CL. Got it.

 

9 minutes ago, seed said:

Hm, it sounds pretty stripped down then, if it isn't that feature rich and also being Software oriented.

The softpoly backend does run on a GL surface (If i remember correctly).

 

3 minutes ago, drfrag said:

Why? The GL renderer it's still fully featured.

ZDoom32 is based on a later 1.9.x renderer so it's not the same, and a late ZDoom codebase.

LZDoom is based on GZ 3.3.x but i ported a ton of later stuff. Using an older GZDoom doesn't make sense even if it's official, when things got hacky was when the localization feature was added in GZ 4.0.0. But those hacks are not too bad and later i fixed old bugs too.

Explain this to a general audience. Don't you think this is already confusing as is?

 

On top of that, you want to make a new port that still retains the LZDoom name, despite being vastly different from the LZDoom description you just provided.

[seed]

Okay, I think I get it now.

 

But that being said, yes, I think changing the name would be the most reasonable choice at this point, especially now when the goal and scope of the project has changed. Once the new version comes out with all the changes it will open a can of worms, a la:

 

28 minutes ago, Redneckerz said:

• why GL 2.0 is gone
• why performance is suddenly so bad
• why the game does not look polished

 

[drfrag]

 Heh, i thought the same at first but then i looked more into it and changed my mind.

 My main goal was never to keep the GL2 renderer, i said it many times. I already released many forks with different names so another one would add even more confusion.

 It's still a legacy and alternative fork. Software was already the default. I want to "allow people to play it with Direct3D 9 the way they used to back in the ZDoom days" like dpJudas said. Performance is not actually THAT bad but you need to make some adjustments plus i support additional lower resolutions.

[Redneckerz]

47 minutes ago, seed said:

Okay, I think I get it now.

 

But that being said, yes, I think changing the name would be the most reasonable choice at this point, especially now when the goal and scope of the project has changed. Once the new version comes out with all the changes it will open a can of worms, a la:

I went ahead and asked Blzut3 directly if he actually suggested a name change. The response was that indeed this was the case, but Blzut3 mean't this as a way of making a LZDoom family, in a similar sense that the various ZDoom maintenance branches fall under the same base (ZDoom). Here is his response, slightly edited for reading and neutrality:
 

Quote

''...There are a ton of reasons why I think it's in both his and the consumers benefit to do so.

The main thing to consider is that all of drfrag's ZDoom ports are essentially maintenance branches of whatever version they're based on

although drfrag's plans change frequently. I highly doubt he'll ever get to the point of truly forking from (G)ZDoom and developing into its own thing.
 

As a result currently he has three or more projects that can be described in effectively the same way, just with a different target user but this difference doesn't need to be carried by a whole new unrelated name, it could just be a different branch of the same "long term maintenance" project.
 

The other thing to consider is infrastructure, LZDoom is on the zdoom home page and I don't think the people involved want to change everything over, create a new logo, etc just because drfrag changed which version his thing is based off of. There's also the drdteam builds, but even you as a wiki maintainer have additional cost to setup multiple new pages for each name.
 

In short I think all things considered it's easier to teach people that LZDoom doesn't have one singular latest and greatest release, and that it's a family of very related projects. You then have one place to go to figure out which version is right for you, vs trying to figure out what the difference between ZDoom32, ZDoomLE, and LZDoom is. Note that at this time I don't think drfrag has made any attempt to bring ZDoom32 or ZDoomLE into the LZDoom branding, but I have encouraged him to do that.
 

As for the GL renderer thing, Graf is very blunt about what he thinks about legacy hardware. I've encouraged drfrag to leave the GL/Vulkan stuff in place but just change the default to software renderer, especially given that softpoly is slow compared software renderer-over-Vulkan backend under Linux and having the Vulkan backend necessitates having all the Vulkan code.
 

He's going to do what he's going to do and for now it looks like that's disabling the GL/Vulkan code outright on Windows. I personally wish that he would stick to literally being (G)ZDoom LTSB, since that would imo be the most useful for everyone, but ultimately what he's doing is the second best thing and if he has more fun doing it his way then so be it.

Personally, i have suggested to him that ZDoomLE should be renamed LZDoom 1.x, ZDoom32 be LZDoom 2.x, LZDoom be LZDoom 3.x, and the upcoming thing LZDoom 4.x. An analogy you could probably use is the way that Linux kernel LTS releases work. They don't go under a different name, they're just Linux 4.14.x, Linux 4.19.x, Linux 5.4.x, etc but each includes backports from the newer versions as deemed appropriate for the respective code bases.''

 

33 minutes ago, drfrag said:

 Heh, i thought the same at first but then i looked more into it and changed my mind.

 My main goal was never to keep the GL2 renderer, i said it many times. I already released many forks with different names so another one would add even more confusion.

Retaining the exact same name for LZDoom would just be detrimental to said confusion. Now that i've heard Blzut's POV, i agree that if you want to retain the name, atleast create a variety of it, similar to ZDoom32/ZDoom LE and so on. Make a LZDoom family.

 

[ReaperAA]

I agree with Red that the exact same name might not be the best idea. This would cause confusion. I recommend making a LZdoom family. Maybe call the new port something like "LZDoom S" or "LZDoom X" or something else (you get the idea).

[Erick194]

One of the things that I will include in DZDoom is the current gradient light from gzdoom but without shaders, and I will also incorporate it in the Poly Render (experimental) I already did that before and it looks good and a flag to make it like the original Doom 64 since the current system is a little different from the original.

 

But that would be then in a fork of LZDoom