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

Do you think Zandronum should merge with [G/L]ZDoom at some point?

Zandronum and ZDoom: What to do?  

141 members have voted

  1. 1. Should a merge happen?

    • Yes, Zandronum should merge with modern ZDoom ports.
      69
    • No, Zandronum should stay it's own thing.
      55
    • I'm more of a ZDaemon/Odamex sort of guy.
      6
    • I don't play multiplayer.
      11
  2. 2. If you want Zandronum to stay it's own thing, what do you think should be done?

    • Zandronum should implement some Skulltag-Compatible ZScript fucntionality from the ZDoom family
      45
    • Zandronum should continue to do it's own thing
      29
    • Zandronum should ditch Skulltag and try to focus moreso on netcode and ZDoom compatibility
      25
    • [Not Applicable]
      42


Recommended Posts

33 minutes ago, ketmar said:

yet another source port. (sighs)

there can be only one several hundred

Share this post


Link to post
10 hours ago, Mr.Rocket said:

What would it take to change up the network protocol in Gzdoom so it works like Zandronum, or even Odamex in this case?

I mean Gzdoom has network functionality, so for it to work similar to Zandronum, isn't that basically a master server query and reply?

A significant rewrite of how gameplay states work? You pretty much would also have to stick to a stable base from which you can reply upon.

 

Things aren't as basically as they seem, or AlexMax/Graf would have made a move already...

 

FWIW, a CS-Branch does exist in GZ, but it only has limited development (Last commit December 21, 2019).

 

10 hours ago, V-Pariah said:

To be fair, Skulltag if I recall used to only allow at most 16 players.  Even then though 16 players in C/S is much more feasible that way than P2P.  Geez, I don't even know what version of Zdoom that build was using, heh.  I wonder...

Skulltag allows 32 player games, as this was added in 0.97b. Source.

The latest SkullTag (0.98b) uses ZDoom 2.3.1 r1551 and on the GZDoom r127 renderer. Source.

6 hours ago, Ru5tK1ng said:

So I was talking on discord and was directed to a source port that aims to do away with message based netcode and implemented delta-compressed game states. I'm not sure what @Ladna has in mind for his project moving forward but I'll link the repo below in case anyone is interested contributing or forking. This would probably be the best way for someone to implement their own netcode without having to worry about the woes brought upon trying to start with a forked g/zdoom.

 

Repo

I am not sure how forking a port that's still very much in development will help with GZ, given that GZ does have a CS-branch already.

 

One possible codebase where things like these are ideal to test and implement is QZDoom, since that's primarily focussed as a testing ground for new features.

29 minutes ago, ketmar said:

yet another source port. (sighs)

Atleast D2K has a clear cut concept. You can do far worse. Atleast D2K adds something to the table, instead of forking when a patch would be sufficient.

Share this post


Link to post
41 minutes ago, Redneckerz said:

Atleast D2K has a clear cut concept. You can do far worse. Atleast D2K adds something to the table, instead of forking when a patch would be sufficient.

for now, it is only network part. also, wow, no decorate support, and plans to introduce yet another scripting language.

 

of course, i cannot (and will not) tell people what they should/shouldn't do. i am just sad.

Share this post


Link to post
6 minutes ago, ketmar said:

for now, it is only network part. also, wow, no decorate support, and plans to introduce yet another scripting language.

I mean you do realize that you are going against the similar kind of grain with K8Vavoom, right? Yet another port.

 

D2K atleast has a good sounding concept. If you see stuff like WinMBF64, which is literally just a code change to make it 64 bit compatible, then that's a different story.

 

6 minutes ago, ketmar said:

of course, i cannot (and will not) tell people what they should/shouldn't do. i am just sad.

It also does not help that the major ports out there have their own fanbases and their own ideas on what a port should constitute. So getting anything significant done usually requires making your own fork with significant changes.

 

Maybe these port authors should come together and work towards one common port. That has worked out so well in the past. ;)

Share this post


Link to post
24 minutes ago, Redneckerz said:

If you see stuff like WinMBF64, which is literally just a code change to make it [*] 64 bit compatible, then that's a different story.

 

[*] break less obviously

Share this post


Link to post
1 hour ago, Redneckerz said:

A significant rewrite of how gameplay states work? You pretty much would also have to stick to a stable base from which you can reply upon.

 

Things aren't as basically as they seem, or AlexMax/Graf would have made a move already...

Ah I see.

1 hour ago, Redneckerz said:

FWIW, a CS-Branch does exist in GZ, but it only has limited development (Last commit December 21, 2019).

Well 4 months is a good sign, and seems to be a step in the right direction!

Wouldn't the codebase in Zandronum and Skulltag alike having to do with the in-game server scanner feature be of some use in this case?

 

1 hour ago, Redneckerz said:

One possible codebase where things like these are ideal to test and implement is QZDoom, since that's primarily focussed as a testing ground for new features.

By all means, if QZ is the primary lab rat:

mis.png.c3905e53fcd704942117de499e218b8c.png

Share this post


Link to post

The in-game server scanner that you speak of is really no more than a simpler version of what Doomseeker/Ide/Idese does/did.  So, it is jist a visual interface.  Thus, it would still need that C/S infrastructure in place for it to be of practical use.

Share this post


Link to post
18 minutes ago, V-Pariah said:

The in-game server scanner that you speak of is really no more than a simpler version of what Doomseeker/Ide/Idese does/did.  So, it is jist a visual interface.  Thus, it would still bee that C/S infrastructure in place for it to be of practical use.

Yes, of course. 

Not implying to add the feature to QZ in-game (visual), but the codebase in which to contact, query, with result. ;)

Although, it would be a nice addition if at all possible to add a "look for hosted games" to the network options menu.

But we'll say that if QZ was already at the point of doing this, then a plug-in for Doomseeker could be created.

And from my understanding C/S is partially implemented.

Edited by Mr.Rocket

Share this post


Link to post
1 hour ago, Redneckerz said:

I mean you do realize that you are going against the similar kind of grain with K8Vavoom, right? Yet another port.

with 20+ years of history, and unique features no other sourceport have (rendering, scripting, network). that's why i chose to continue its development instead of starting my own from scratch. k8vavoom IS Vavoom, i am doing what i think Janis would do if he would still be in charge. that's why it still has "vavoom" in its name.

Share this post


Link to post
46 minutes ago, fabian said:

 

[*] break less obviously

Indeed. But it goes without saying: Don't fork unless its substantial. How often i have found forks that only add a superfly minor feature which one could just submit as a pull request or a patch..

 

38 minutes ago, Mr.Rocket said:

Ah I see.

Well 4 months is a good sign, and seems to be a step in the right direction!

I mean GZ has a ton of branches. It does not mean its actually mainline stuff. They also have a branch for baked lightmaps, for instance.

 

38 minutes ago, Mr.Rocket said:

Wouldn't the codebase in Zandronum and Skulltag alike having to do with the in-game server scanner feature be of some use in this case?

As in... a scanner feature that seeks new servers??

 

4 minutes ago, ketmar said:

with 20+ years of history, and unique features no other sourceport have (rendering, scripting, network).

I mean it technically borrows a lot of it from an engine that isn't Doom ;)

4 minutes ago, ketmar said:

that's why i chose to continue its development instead of starting my own from scratch. k8vavoom IS Vavoom, i am doing what i think Janis would do if he would still be in charge. that's why it still has "vavoom" in its name.

But i thought you did things all by yourself and didn't like being noted by a boss. I am just kidding ofcourse.

Share this post


Link to post
2 minutes ago, Redneckerz said:

I mean it technically borrows a lot of it from an engine that isn't Doom ;)

actually, at least three other engines.

 

3 minutes ago, Redneckerz said:

But i thought you did things all by yourself and didn't like being noted by a boss.

only because The Boss doesn't want to do those things on his own! ;-) i waited for almost ten years for somebody to come and do it for me, because i am a lazy ass too.

Share this post


Link to post
25 minutes ago, ketmar said:

actually, at least three other engines.

The Difference Engine and the Analytical Engine don't count, Ketmar Babbage ;)

25 minutes ago, ketmar said:

only because The Boss doesn't want to do those things on his own! ;-) i waited for almost ten years for somebody to come and do it for me, because i am a lazy ass too.

Now you can understand Graf's positions from time to time a bit better too :P

Share this post


Link to post
3 hours ago, Redneckerz said:

I am not sure how forking a port that's still very much in development will help with GZ, given that GZ does have a CS-branch already.

I never said it was going to help Gzdoom. It was mainly for those who may potentially be interested in developing some new type of netcode. After all, not everyone wants to work with G/Zdoom code base.

 

As for the branch, that's good it's still being worked on in some form. It looks more like it's just picked at every now rather than being a priority. Basically it's going to be a while no matter what.

 

2 hours ago, ketmar said:

for now, it is only network part. also, wow, no decorate support, and plans to introduce yet another scripting language.

 

of course, i cannot (and will not) tell people what they should/shouldn't do. i am just sad.

Don't scoff at LUA, it's more of a language than ACS will ever be.

 

I'm fairly certain some folks said the same thing when you posted up your port. 'yet another source port. (sighs)' ;)

Share this post


Link to post
1 hour ago, Ru5tK1ng said:

Don't scoff at LUA, it's more of a language than ACS will ever be.

i know Lua, and used it alot. what i meant is that there seem to be yet inother incompatible scripting implementation instead of DECORATE support.

 

1 hour ago, Ru5tK1ng said:

I'm fairly certain some folks said the same thing when you posted up your port. 'yet another source port. (sighs)' ;)

they're late for at least 20 years then, because first Vavoom public release was in 1999. ;-) k8vavoom is not a new kid on the block, it is by all means Vavoom Revived.

 

still, i have nothing against more sourceports, i only become little sad when i see plans for more incompatible scripting implementations. yes, DECORATE is not the best thing out there, but it is supported by at least three sourceports already, which makes it de-facto crossport standard, i believe.

Share this post


Link to post
42 minutes ago, ketmar said:

i know Lua, and used it alot. what i meant is that there seem to be yet inother incompatible scripting implementation instead of DECORATE support.

 

still, i have nothing against more sourceports, i only become little sad when i see plans for more incompatible scripting implementations. yes, DECORATE is not the best thing out there, but it is supported by at least three sourceports already, which makes it de-facto crossport standard, i believe.

For what it's worth, it was laid out in the Goals of D2K that Decorate would be supported. LUA would just fill a similar role that VavoomC does.:

https://github.com/camgunz/totaltrash/blob/master/content/d2k/goals.md

 

This short faq explains why he went with a fork of prboom+:

https://github.com/camgunz/totaltrash/blob/master/content/d2k/faq.md

 

 

Share this post


Link to post
24 minutes ago, Ru5tK1ng said:

This short faq explains why he went with a fork of prboom+:

https://github.com/camgunz/totaltrash/blob/master/content/d2k/faq.md

Lets see what this says. Given that its written in 2014, it obviously does not reference stuff like GLOOME or GZDoom-GPL or the discontinuation of ZDoom which all happened in between. Since the user still pushes commits, that FAQ is rather outdated, to say the least. Atleast, the 2014 arguments cited there do not hold up at all with GZDoom's current licensing scheme.

 

Quote

''### What do you have against (G)ZDoom?

I am dismayed that ZDoom and its derivatives are what people think of as "Doom", when they are really entirely different engines that just happen to load Doom resource files.''

Honestly i can't see how this is GZDoom's fault (I removed the other bits, mind you.). This is solely down on popularity. ZDoom/GZ were the most popular for modding users.

 

A similar argument could be said that one can be dismayed that PrBoom+ and its derivatives are what people think of as ''Doom''.... especially when he uses that as a base for his own port. It means nothing. People who know what a source port is know that ZDoom is one, and people who don't know... well, one can reasonably assume they aren't that involved in the Doom community and just want to play Doom.

 

And there's nothing wrong with that. Even with GZDoom's licensing being different from what it was in 2014, this argument does not hold up. Not in 2014, and not 6 years later, in my opinion.

 

Quote

ZDoom is in no way compatible with Doom demos. It hasn't been for years. Furthermore, ZDoom breaks compatibility with its own demos haphazardly. One of Doom's strengths is its rich history, and ZDoom has no regard for preserving it.

ZDoom supports demoplay, its just not the focus of the port. ZDoom's focus is expandability for modders first and formost. But, ZDoom got discontinued in 2016, with version 2.8.1, so one could say that there is finally a compatible ZDoom for demomaking! :)

 

(And yes i know the author said he respects the devs.)

 

Quote

ZDoom's physics and renderer are also drastically different than Doom's, and it isn't possible to configure them to revert to original settings, because vanilla behavior is not a priority for ZDoom developers. Even the super-shotgun spread was changed. Such changes have huge effects on competitive play, but this is also not a priority for ZDoom developers.

If you want perfect Vanilla behavior, then there is Chocolate Doom, its deriviatives, or the original Linux Doom code.  Even multiplayer ports like ZDaemon and Odamex implement their own physics changes, its hardly worth a point of contention.

 

And besides, if you use ZDoom to capture vanilla behavior, then you obviously aren't using the right port. You become what you dismay - Someone who thinks what people think of when they hear ''Doom'' ;)

Quote

ZDoom continues to use features and code from non-free libraries and codebases, most infamously FMOD and BUILD. However, to their credit, ZDoom developers freely release their original code under the 2-clause BSD license, which, even though it allows the source to be closed, at least offers other source port developers the chance to incorporate those features in open ports.

Stuff like this is why the FAQ badly needs an update - The whole Build code has been licensed correctly now, and heck there is even a new port that relies on Build code, Raze!

 

I understand its not really fair to dunk on Camgunz in 2020 for a FAQ in 2014, but given that the user still makes commits, atleast update the FAQ to denote its outdated, no? :)

 

But yeah, its an interesting FAQ. Really shows what the sentiment was of some authors back in 2014.

 

Share this post


Link to post
5 hours ago, Redneckerz said:

I mean GZ has a ton of branches. It does not mean its actually mainline stuff. They also have a branch for baked lightmaps, for instance.

 

As in... a scanner feature that seeks new servers??

 

Neat, but I look forward to functionality over eye candy I suppose, and to me the C/S net code side of things would make more since.

 

As in, Yes, a scanner feature that seeks new servers.

Though, Doom Seeker (and the like) could accommodate for that I suppose. 

 

 

Share this post


Link to post
2 hours ago, Redneckerz said:

-snip-

Honestly, I'd say a better question to start the FAQ would have been 'Why aren't you forking Zdoom?'. D2K's aim is MP C/S and as expressed in this topic time and time again, just tacking C/S onto GZdoom isn't a 1 week feat. Essentially if you want to implement a netcode different from Zandronum, Zdaemon, and Odamex, you'll have to start somewhere different and that means not using ZDoom+csdoom as your base. Ladna came to the conclusion if he was going to refactor a lot of the engine, it would be slightly less painful to start with prBoom.

 

 This short bit gives a quick overview of why he even wanted to implement a netcode different from ZDaemon and Co.:

https://github.com/camgunz/totaltrash/blob/master/content/post/d2k.md

 

D2K appeals mainly to those who have long suffered with netcode problems that plague the 3 multiplayer ports listed. If you're a user who just plays SP mods by yourself, it wouldn't matter to you at all.

Share this post


Link to post

Hi Everyone 

The reason why we cannot merged the latest: because we need to deal with the network as it desyncs and a lot of you might end up having ridiculous issues and its take ALOT of time to fix this, including ZScript. but we do understand the rendering is so bad as of now but that's in the future.  

We are trying hard to fix all of the bugs regarding what's in the tracker, unless IRL stuff takes over. 

Share this post


Link to post
16 hours ago, Ru5tK1ng said:

For what it's worth, it was laid out in the Goals of D2K that Decorate would be supported.

em... i didn't noticed that, sorry. somehow i thought that decorate will be dropped for New Standard. my apologies.

 

p.s.: the language is named Lua. this is not an acronym, it is just a word "Moon". Lua authors want it to be "Lua" or "lua", but not "LUA".

 

p.p.s.: still, in 2014: (from goals)

Current plans include:

  • Implement console in scripting (Vavoom had it)
  • Implement new game modes in scripting (Vavoom had it)
  • Move Doom physics, game play, and assets to scripting (Vavoom had it)

and Vavoom had almost working network implementation with delta-compression and RPC (there was a small bug in packet sequencing, but the whole system was right). also, VavoomC is strongly typed language. support for Decorate, Dehacked, OpenGL rendering.

 

yep, no vanilla demo compatibility, and freestep engine instead of lockstep one. i wonder why Vavoom wasn't used as a base.

Edited by ketmar

Share this post


Link to post

The common myth being spread around is that gzdoom is "better for playing mods" but when you look at screenshots like these it is becoming harder and harder to defend that thesis. What I have noticed is significant improvement in framerate, but with this "faulty" (in my opinion) discolored pale renderer.

Would there be a way to make an one-shot release of this? Meaning: latest mod compatibility with this "Software Lighting Mode in OpenGL" feature added on top of it? This would not need to be maintained, it would be just a one-off, or maybe something done once a year.

 

composite.jpg.60db7770a760dde6570fd880afd15937.jpg

 

Source screenshots in higher resolution: https://imgur.com/gallery/ch7jBHU  (click on the 3 dots to Download file and compare them side to side)

 

On 4/19/2020 at 5:33 PM, drfrag said:

The software light mode was never removed, the fact that it doesn't work on your ancient card doesn't mean it's not there.

 

That seems to be another lie, I just downloaded the latest lzdoom to verify and the Software Lighting Mode is not present in opengl renderer, only in software renderer.

Share this post


Link to post

So now you're saying that GZDoom is better that GZDoom for playing mods?

And do you think you know better than me? Not only that one is in LZDoom but i also backported the new vanilla light mode.

Moreover now you say i'm a liar, the source is public so you could check.

I believe your card supports only GL 2.1, before you said that mode didn't exist and i pointed you to a software driver but seems you're using an old version of Mesa3D. Before they required GL 3.0 now since the modern path requires GL 3.3 you need a more recent version of the "emulator".

If your driver doesn't support them they are removed from the menu and those modes are only for OpenGL.

So stop talking nonsense. And if you stop posting pirated builds the better. This has been almost fun, almost.

https://imgur.com/a/ZxQy82A

Edit: and actually software is the default light mode in LZDoom but falls back to dark if it's unsupported by the hardware, if you distribute your ini you're effectively changing it to dark.

Edited by drfrag

Share this post


Link to post
4 hours ago, DwarfCleric said:

That seems to be another lie, I just downloaded the latest lzdoom to verify and the Software Lighting Mode is not present in opengl renderer, only in software renderer.

 

Blame your potato then.

 

Neither the SW sector light mode nor Vanilla will show up if your card doesn't support them, just like they don't show up in mainline either if running on unsupported hardware.

Share this post


Link to post
9 hours ago, DwarfCleric said:

The common myth being spread around is that gzdoom is "better for playing mods" but when you look at screenshots like these it is becoming harder and harder to defend that thesis.

If you go by outdated and custom builds you yourself made, then i agree, its very easy to attack the common thesis then. *

 

* It does not really prove your point though.

 

So what's a better argument then? Or even better, which port is "better for playing mods"?

9 hours ago, DwarfCleric said:

What I have noticed is significant improvement in framerate, but with this "faulty" (in my opinion) discolored pale renderer.

What's "faulty" about it?

 

9 hours ago, DwarfCleric said:

That seems to be another lie, I just downloaded the latest lzdoom to verify and the Software Lighting Mode is not present in opengl renderer, only in software renderer.

Implying Drfrag lied before - Nice. :/

 

I am not buying into the style of your retorts Cleric. Too often i see random insults and implications tossed in with the sole purpose of provoking the other party. Its a bad faith tool to use and it's trite to do so.

Share this post


Link to post
On 4/20/2020 at 11:20 PM, doomjoshuaboy said:

Hi Everyone 

The reason why we cannot merged the latest: because we need to deal with the network as it desyncs and a lot of you might end up having ridiculous issues and its take ALOT of time to fix this, including ZScript. but we do understand the rendering is so bad as of now but that's in the future.  

We are trying hard to fix all of the bugs regarding what's in the tracker, unless IRL stuff takes over. 

 

I think Zandronum's visuals are just fine.   I like them better than GZDoom's default settings.

 

Before this topic, I was actually worried a merge was actually happening which would kill online play for a lot of people.   I currently use an old 2012 AMD quadcore laptop (with 2011 ATI Radeon video) and a newer 2019 Intel i7 laptop (with GeForce RTX video).  And there's mod compatibility.   Some Brutal PSX Doom I found that's designed for GZDoom wouldn't run on newer versions but Zandronum plays it fine.

 

Only things I found Zandronum to be missing editing myself are UDMF not supporting multiple tags on the same sector (so I worked around setting more linedefs to transfer from the 3D sector), Lost Soul infighting behaving same as everything else instead of vanilla/vanilla compat/newer GZDoom where they may suddenly still charge at you (though GZDoom doesn't have their lost staring at the wall behavior), and setting lower wall fade under color/Doom 64-sector colors for sectors so I can have the walls of a pit fade into darkness doesn't work.   Of course there's mods by others than require newer GZDoom.

 

The most important thing is that, if any sacrifice of either performance or compatibility is made of any kind in some overhaul, Zandronum 3.0/3.01 should be kept operational as its own thing with servers designated as it.

Share this post


Link to post
11 hours ago, seed said:

 

Blame your potato then.

 

 

Precisely that. The lighting calculations for the software renderer are so totally different from how traditional graphics hardware works that it is impossible to implement there. Performant shader support is an absolute requirement, but that requires hardware being made for it, not some cheap-o vintage Intel graphics "accelerator". And as a result the menu items for those lighting modes do not appear on said old hardware.

 

Accusing others of being liars but then clearly showing a profound lack of understanding of the technical side of things is a very weak argument.

Share this post


Link to post
19 minutes ago, ketmar said:

the more you feeding the troll, the happier the troll is.

 

Truth has been spoken

Share this post


Link to post
25 minutes ago, ketmar said:

the more you feeding the troll, the happier the troll is.

I can't ignore you, though.

 

:P

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×