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

[seed]

10 minutes ago, ReaperAA said:

Truth has been spoken.

 

Besides, it's not like Cleric doesn't have a history here, he accused GZDoom of... I think it was mediocre optimization before?

 

And then proceeded to compare it with other games and engines and cite how they work better but GZDoom does not, and when people explained why that was to him, he resumed to basically calling people white knights...

[ketmar]

28 minutes ago, Redneckerz said:

I can't ignore you, though.

oh, sure you can! there is a built-in forum tool for this. but you know that Doomworld will not be the same without me. i am supercalifragilisticexpialidocious.

[Kizoky]

I don't think Zandronum will ever reach GZDoom
Wouldn't it be faster to develop C/S for GZDoom and then backport all Zandronum features into a different GZDoom fork?

[Redneckerz]

1 hour ago, ketmar said:

oh, sure you can! there is a built-in forum tool for this. but you know that Doomworld will not be the same without me. i am supercalifragilisticexpialidocious.

Musical reference gets a thumbs up.

 

17 minutes ago, Kizoky said:

I don't think Zandronum will ever reach GZDoom
Wouldn't it be faster to develop C/S for GZDoom and then backport all Zandronum features into a different GZDoom fork?

Regarding the bolded :

• You would need to find someone who wants to do that
• Graf and co have to be okay that all of this progression gets into a new Zandronum like fork because the amount of work ahead would be significant before it can be mainline GZ, which is highly unlikely
• At that stage however, that fork, as you say, would have to backport all Zandro stuff to the new fork -Which is also a surplus amount of work ahead. Since Zandro code is basing itself around older ZDoom/GZDoom code, backporting it to a newer GZDoom revision with a C/S model likely will introduce new issues, which will have to be kinked out

I am sure more pitfalls can be envisioned. Rule of thumb - Any significant merge/suggestion/new fork requires an amount of effort that either is not available by Graf, is incompatible, or too significant to be sensible, imo.

[DoomKrakken]

I voted that they'd merge... but only because I know that Zandronum is basically a lost cause at this point when it comes to updates, and a C/S multiplayer model is likely going to take years to implement since it's not at the top of their priority list.  GZDoom devs got the know-how, but they just don't want to right now (I guess it's boring?), 'cuz they've got other priorities...

 

Besides that, I'm curious to see what'd happen if Zandro's C/S code were used in GZDoom.  It'd be cool to have some of Skulltag's native actors (such as the Dark Imp) utilized in GZDoom, natively, as well as the... what'd they call 'em, runes?  Rage (double ROF), Strength (double damage), Spread (all attacks spawn an additional two sets of the same attack at +/- 45 degrees from the player), Haste (double movement speed), etc...

 

Other than that, I'd want Zandronum to remain its own thing and hopefully update to the latest GZDoom stuff.  I'd want mods like D4T and QC:DE to rely less on mad hacx to work, and to be more flexible for functionality's sake, while not losing their multiplayer aspects.

 

People keep asking for a Zandronum version of my mod, but I keep turning them down because my mod relies too much on ZScript, as ZScript is so flexible and the possibilities are just endless when using it.  Zandronum doesn't have it, but I'm sure I'd begin using it if it were updated to the latest GZDoom version.  I'd be programming multiplayer capabilities in my mod if I knew a major update like this was coming about, soon.

[V-Pariah]

Well,

I don't know really if there's anything else to say here in terms of Zandronum since there hasn't really been a hardened plan yet, but without a doubt the idea has entered their radar before.  Here is Torr's last commit for the clientserver branch, dated 19 August 2018.  It seems to have some "Zandronum stuff" in it, so I'm not sure whether or not to call it "Zandronum GZDoom" or "Zandronum Modern" or something like that, but even then the branch is very bare.

 

For the adventurous, feel free to check out the branch commits.  From the looks of it, hardly anything has happened since Zandevs don't know how the scripting VM works and GZDev doesn't have netcode experience.  For all intents and purposes, it's a stalemate.

But in terms of the near future for Zandronum, I think the thread @Redneckerz pointed out before on the Zandronum forum seems to indicate the next step will be to get Zan 3.1 out of the way ASAP, if not also 4.0 which in and of itself might actually take Zandronum to Zdoom 2.8.1 or whatever but I'm not entirely sure on that.  They could still that GZDoom clientserver branch, I guess, and let it transform itself into "Zandronum Modern" (as opposed to being just a branch on git) and any able developers can hop on it should they choose.  Hypothetically, there could be two Zandronum versions, Zan 4.0 with no ZScript and "Zan Ultra" with the scripting VM.  Note that I haven't bothered to talk about the renderers yet, but obviously there would be differences between the two.

 

Milestones might also be ineffective and I may boldly suggest Scrum sprints as an alternative: https://en.wikipedia.org/wiki/Scrum_Sprint .  It might sound insanely crazy, but it might somehow work to get a reasonable "due date" for particular items of interest, bug fixes, whatever might come up.  But, I have no idea how to interface it with the bug tracker that Zan uses.

Lastly, I'd like to point out that even despite what I've written here, absolutely nothing is, uh, "set in stone" as far as I'm aware and by looking at the Zandronum forum.  My suggestion for any serious supporters of this kind of idea, bring it to Torr's attention in the thread aformentioned.  If there's any developers here interested in taking on the netcode challenge for such a project, can you let me know if you'd follow a fork of GZdoom c/s and/or scrum sprints and how long the sprint cycles should be?  School, work, etc. notwithstanding of course, because Zandev will probably need people like that if tackling ZScript full on.

 

PS. It seems Torr prefers hg over git so I don't know if that might have an effect.  Just be wary of that!

[dpJudas]

11 minutes ago, V-Pariah said:

For the adventurous, feel free to check out the branch commits.  From the looks of it, hardly anything has happened since Zandevs don't know how the scripting VM works and GZDev doesn't have netcode experience.  For all intents and purposes, it's a stalemate.

I have plenty of netcode experience, that isn't really the problem. The netcode on that branch is working perfectly fine at this point - i.e. player prediction is working as intended and so is the object replication.

 

What is missing is that my knowledge of the playsim is very limited. It more less amounts to: ok I know it tics thinkers, something loaded a level and there's spaghetti everywhere in this part of the codebase. This makes it very difficult to plot a plan for how to deal with finishing a level and replicating the few remaining things (sounds, sector/line changes) without studying it further. Unfortunately my interest in the Doom playsim isn't big enough to do that, so that's why the branch is not evolving.

 

I do work on it a bit every xmas when I get bored enough, so who knows maybe one day it will be finished enough to be usable for something. :)

[V-Pariah]

@dpJudas Okay, would you be okay with working on it whether it be a branch or a fork altogether?

[Redneckerz]

58 minutes ago, V-Pariah said:

But in terms of the near future for Zandronum, I think the thread @Redneckerz pointed out before on the Zandronum forum seems to indicate the next step will be to get Zan 3.1 out of the way ASAP, if not also 4.0 which in and of itself might actually take Zandronum to Zdoom 2.8.1 or whatever but I'm not entirely sure on that.  They could still that GZDoom clientserver branch, I guess, and let it transform itself into "Zandronum Modern" (as opposed to being just a branch on git) and any able developers can hop on it should they choose.  Hypothetically, there could be two Zandronum versions, Zan 4.0 with no ZScript and "Zan Ultra" with the scripting VM.  Note that I haven't bothered to talk about the renderers yet, but obviously there would be differences between the two.

 

35 minutes ago, dpJudas said:

I have plenty of netcode experience, that isn't really the problem. The netcode on that branch is working perfectly fine at this point - i.e. player prediction is working as intended and so is the object replication.

 

What is missing is that my knowledge of the playsim is very limited. It more less amounts to: ok I know it tics thinkers, something loaded a level and there's spaghetti everywhere in this part of the codebase. This makes it very difficult to plot a plan for how to deal with finishing a level and replicating the few remaining things (sounds, sector/line changes) without studying it further. Unfortunately my interest in the Doom playsim isn't big enough to do that, so that's why the branch is not evolving.

 

I do work on it a bit every xmas when I get bored enough, so who knows maybe one day it will be finished enough to be usable for something. :)

Sideways related, I do like to make note of a project called QZandronum. It was initiated by ZDoom's Eruanna back in October 2016 when the first QZDoom releases came out with True Color support. It sought to bring the True Color renderer to Zandronum back then. Its currently found here.

 

In the thread, it mentions this post by @Edward-san:

Quote

''I think we can discuss about this after 3.0 is released, as long as we don't forget about it :P''

It seems that ultimately, it was forgotten after all :P

 

The software renderer was referenced on the Zandronum tracker in January 2017, but back then most of the developers stated not to want it ported over because it was not stable yet. (This argument is also found in the DRDteam thread linked here.)

 

I am mentioning this because the mindset shown there may halfway be applied to the C/S netcode discussion aswell. And if an attempt was to be made, you may aswell haul the TC code over. ;) especially now that it is matured and fully functional (One would have to backport it to QZandronum first i reckon though).

 

Either way some additional food for thought.

[V-Pariah]

@Redneckerz Yeah, I thought about that but I don't know if that can follow Zan 4.0's path (e.g. be a branch of Zan 4.0) or if it would rather be its own thing altogether in which case you have what, Zan 4.0 "Classic/Legacy", Zan "TC Rollback", and Zan "Ultra"?  If fully forking this branch is even considered ideal and people want to Scrum sprint that.  I could see a double sprint if anything... Zan 4.0 would eventually just be completely taken over by whatever comes of ZScript C/S....

[Redneckerz]

33 minutes ago, V-Pariah said:

@Redneckerz Yeah, I thought about that but I don't know if that can follow Zan 4.0's path (e.g. be a branch of Zan 4.0) or if it would rather be its own thing altogether in which case you have what, Zan 4.0 "Classic/Legacy", Zan "TC Rollback", and Zan "Ultra"?  If fully forking this branch is even considered ideal and people want to Scrum sprint that.  I could see a double sprint if anything... Zan 4.0 would eventually just be completely taken over by whatever comes of ZScript C/S....

For test messing, one sensible (as in, won't touch official branches yet) would be to see if you could merge that CS-server branch with the QZandronum branch.

 

I realize that the QZ branch is quite a bit older than mainline Zandro, but atleast you could also test out the TrueColor code by doing so. The resultant contraption though (if possible at all) would be rather Frankensteinic in nature, but hey. There are building blocks, to say the least. :)

[dpJudas]

3 hours ago, V-Pariah said:

@dpJudas Okay, would you be okay with working on it whether it be a branch or a fork altogether?

 

The plan for the branch was to get C/S up and running for ZScript in GZDoom itself. That is, it would get merged into GZDoom. The scope of the branch is intentionally so that it only deals with the C/S aspect and not building any kind of server browser. That would be built on top by downstream Zandronum.

 

This is all highly theoretical anyway because without the finished branch any talk about how to release it isn't very useful.

[V-Pariah]

@dpJudas Okay, so that makes sense.  However, without interfacing that branch with something like Zandronum which is where large-scale build testing would normally happen, how would it get tested on a large scale by itself?  Is there some sort of unit testing procedure for it?

Well, I can try my best anyway to get some net coders on a Discord server/channel or whatever.  There isn't much in terms of scrum bots for Discord, but if anything like that might help out I can try to set it up.

[dpJudas]

Thanks, but there is no point of doing large-scale build testing of anything until it reached a state where at least all the basics have been implemented.

[V-Pariah]

1 hour ago, dpJudas said:

Thanks, but there is no point of doing large-scale build testing of anything until it reached a state where at least all the basics have been implemented.

I don't know if the second option would help; the scrum bot.  It seems like maybe that would be a good start.  If it's Discord, we could interface it with the other common channels Zandronum developers use with a relay bot.  It might be worth it if a commit a day (a week? heh) will be pushing it too hard when it comes to getting the basics down.  I would strongly suggest it to get more raw manpower.

[dpJudas]

3 hours ago, V-Pariah said:

I don't know if the second option would help; the scrum bot.  It seems like maybe that would be a good start.  If it's Discord, we could interface it with the other common channels Zandronum developers use with a relay bot.  It might be worth it if a commit a day (a week? heh) will be pushing it too hard when it comes to getting the basics down.  I would strongly suggest it to get more raw manpower.

This is not really how open source development works. The horror concepts from the corporate world, such as Scrum and sprints, do not apply here as there's nobody to fire me when I do not do what your bot tells me to do. :) If I wanted to commit every day to this branch then I would just do so. Needless to say I don't feel like doing that so that's why there's not coming daily (or weekly) commits in.

 

Likewise, having a bot write to the Zand devs that they should commit to this branch won't really solve any of the reasons why they aren't doing so already. It is nice of you to try help any way you can, but adding more process is not the solution. Ultimately what is required is sufficiently experienced developers willing to commit to doing actual work here and the Doom community just doesn't have that right now. If it did, they'd already be working hard on the problem.

[DoomKrakken]

What's the plan if you can't find sufficiently experienced developers, though?  I don't think it's as productive to leave the project to stagnation... although I totally understand not leaving it in the hands of people who have no idea what to do with it.

 

But how does one even begin to learn to start working with this stuff?  I almost wanna start learning how to write netcode just so that I can get easier multiplayer going for GZDoom, but I've no idea where to start.

[ketmar]

11 hours ago, dpJudas said:

It is nice of you to try help any way you can, but adding more process is not the solution.

yeah. i believe that the basic idea was to "shape" the workflow, remind people about things they may forget, engage them into some sort of competiion, and set timeframes, so the intentions were good. but even the best intentions failing to work sometimes. ;-)

 

7 hours ago, DoomKrakken said:

What's the plan if you can't find sufficiently experienced developers, though?

then the project will keep moving at its current slow pace.

 

7 hours ago, DoomKrakken said:

although I totally understand not leaving it in the hands of people who have no idea what to do with it.

this is something you cannot control with FOSS project. anybody can fork it, regardless of their knowledge and expirience.

 

7 hours ago, DoomKrakken said:

But how does one even begin to learn to start working with this stuff?

learn the codebase. read articles to learn about various multiplayer implementations. apply your knowledge of implementations to your knowledge of the codebase. done, problem solved.

Edited April 26, 2020 by ketmar : typos

[Redneckerz]

Is my suggestion of merging the CS GZDoom branch with QZandronum as a starting point exceptionally silly (as in, doing so will spit out enough errors to blast you back to the days of ZDoom 1.x) or does it have some merit?

[dpJudas]

It would be easier to backport the modern GZDoom renderer to Zandronum than backport the clientserver branch to Rachael's QZandronum branch. Not that there are any volunteers for doing that either.

[ketmar]

@dpJudas did you used q3-like "full snapshot" model, qw-like message model, or unreal-like "channels"? sorry, i can look at the code, of course, but i am just curious, and like to get a very "broad, rough and simple" answer instead of digging GZDoom codebase i don't fully understand. ;-)

[dpJudas]

At the lowest level it uses basic message sending using UDP where each message can be flagged as important or not. Important messages are guaranteed to be received and messages always arrive in order.

 

On top of that it uses a system where the client playsims starts empty. The level is loaded and only completely static things are spawned. From there it receives spawn messages for each dynamic object in the map from the server. As the objects change, delta messages are sent to keep the clients in sync. Player prediction is performed the same way as normal ZDoom's P2P: P_PredictPlayer is called and it simulates the extra tics the client is ahead. Before the next playsim tic those are rolled back by P_UnpredictPlayer. Just like today's P2P model the input data is also sent to the server and its PlayerPawn is the authoritative object for where the client is located.

 

Since ZScript can pretty much do anything, the basic idea for object replication is that each server side class can be spawned as a different client side class. Unless specified otherwise, objects from the server spawns as the NetSyncActor class on the clients. This actor is a dumb slave object that only replicates just enough to maintain visuals: the position, rotation, sprite, audio and so on. In other words, the client will not be running exactly the same actors as the server.

 

An actor class can customize which actor gets spawned by using a keyword in zscript. The spawned client actor can send/receive messages to/from its server actor. The class can also declare member variables that should be kept in sync automatically. If actors in the client playsim spawns additional objects they will not appear on the server. Object synchronization is strictly server to client.

 

Note: I'm only describing the rough plan here because ketmar asked. I'm specifically not looking for input on how I should do it completely differently because engine XYZ does it that way. A large part of this design was dictated by what is realistic to implement without the freedom you have when starting from scratch.

[V-Pariah]

The first order of business is to just get Zan 3.1 Beta updated within a week or so.  I think that's all I can really add to this thread right now.  From what time I can spend trying to get more momentum/traction, I'll do my best to integrate some way to help, perhaps an HTTP push API or something that can give people on other chat mediums like Discord or IRC a way to see real-time commits on the client-server branch.

 

That is if other willing and able people will be there to have a more focused approach to its development.  I still think the scrum bot would also be useful in the case that development picks up because once the traction picks up and everyone can discuss the project from wherever they want, then it'll be at a point of no return so to speak.  And don't worry about changing approach, @dpJudas  since that's not on the radar.

My suggestion for those who are eager to get Zandronum moving forward in any way, right now, even if you don't work net-code development that's completely fine as long as you hop on TSPG or wherever testing will happen and we grind those tests! :-)

[ketmar]

@dpJudas thank you alot! this is much more detailed answer than i expected to get. ;-)

[DwarfCleric]

 

On 4/22/2020 at 5:21 AM, Gokuma said:

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.

 

Exactly. It's not only about looks but also core gameplay changes. Being done at will without consulting the community first.

There's no technical argument to isolate a bunch of people from playing the game on "ancient hardware" (as they call it) either. Otherwise we would see this in other OpenGL games as well, like Quake ports, Quake 2 ports and such.

If this merge happens, we're going to see modders also making multiplayer maps that require gzdoom to run, and that will ultimately kill it for a lot of people. It's also part of the modders' vanity that prefer to win cacowards and such at the expense of making lots of people unable to play the maps.

 

There's also this video that talks about some other core gameplay changes implemented in gzdoom variants:

 

 

And this list of issues that contributes to gzdoom being such a CPU hog that it is (and barely using GPU resources at all... the whole premise of it is "hardware acceleration" but it barely uses it)

 

[Gokuma]

Here's something that bothers me...   So A_PlaySoundEx was deprecated back in 2009.   Alright and it's probably still supported fine anyway.

But now as of 04-Jan-2020, regular A_PlaySound is deprecated.   Why that now in the year 2020?   Of course it will surely be supported for a long time to come.  But screw it, I'm going to keep using it instead of A_StartSound that you're supposed to use now.

[Ru5tK1ng]

2 hours ago, DwarfCleric said:

There's also this video that talks about some other core gameplay changes implemented in gzdoom variants:

 

The video you linked is over 2 years old and outdated:

 

 

 

[ketmar]

45 minutes ago, Ru5tK1ng said:

The video you linked is over 2 years old and outdated

everything he's talking about is like this: either outdated crap fixed long time ago, or completely baseless "facts" pulled straight from his ass. and he never ever admited that he was wrong. so there is little reason to correct him, i believe.

[ReaperAA]

3 hours ago, DwarfCleric said:

There's also this video that talks about some other core gameplay changes implemented in gzdoom variants:

 

Ironically enough, newer GZDoom versions have fixed this issue while Zandronum probably still has it (because it is based on an old version of GZDoom).

[Graf Zahl]

3 hours ago, Gokuma said:

Here's something that bothers me...   So A_PlaySoundEx was deprecated back in 2009.   Alright and it's probably still supported fine anyway.

But now as of 04-Jan-2020, regular A_PlaySound is deprecated.   Why that now in the year 2020?   Of course it will surely be supported for a long time to come.  But screw it, I'm going to keep using it instead of A_StartSound that you're supposed to use now.

 

Why? Because it was suffering from a design flaw, so it got replaced with a function that doesn't have the design flaw - the design flaw being that it mixes sound channel number and flags in the same parameter. In January I lifted the limit of 8 sound channels per actor but the way A_PlaySound is implemented makes it impossible to go beyond the 8 original channels with it as there are only 3 bits available for the channel index. So a new function was added that can address all of them and to point modders in the right direction the old one was deprecated. If I didn't, the outcome would be inevitable: Getting bug reports about "Why can't I use channel 16 with A_PlaySound? Why does it play the sound all wrong?"