Is multiplayer getting any focus?

[JBro]

GZDoom is incredibly lacking on the networking front, resulting in the need for a multiplayer-centric sourceport. Is Raze going to suffer from the same issue?

[Graf Zahl]

Find me a developer willing to invest time here and we may talk again.
Keeping a multiplayer setup working is a far from trivial and often very time consuming task and surely needs someone with dedication and a lot of free time. Such developers are very hard to find as can be seen by Zandronum development having ground to a halt.

That said, doing a Zandronum for Build is pretty much impossible because it's not just one but four dffferent game engines and all these games are a lot less well structured than Doom.

So, for now, no there is no focus on multiplayer at all as it'd stall all the ongoing work to get the port out of alpha development.

[Redneckerz]

GZDoom is incredibly lacking on the networking front, resulting in the need for a multiplayer-centric sourceport.

There are a few:
ZDaemon
Odamex
Zandronum (Even has a OpenGL renderer)

Take your pick. These are the multiplayer-centric sourceports you are looking for.

Is Raze going to suffer from the same issue?

I don't like the suggestive tone of either this question or the one in the title. GZDoom 4.5.0 just released. It should be immediately aware what and where the focus of both GZDoom and Raze are.

Disregarding that, however: Its already quite impressive that Graf is managing not one source port project, but since this year, two of em - 3 if you count his PrBoom UM fork.

So... how much more does the man and everyone else involved with it need to do?

[Graf Zahl]

3 if you count his PrBoom UM fork.

I do not work on that.

[Redneckerz]

3 if you count his PrBoom UM fork.

I do not work on that.

That's why i said ''if you count'' Not anymore atleast.

[sinisterseed]

Well, it's basically what Graf said OP.

For now and the future, the focus is building a solid foundation and then uplift the games and the engine itself even further, so singleplayer is the main focus as a result, but more on that another time. Unlike GZDoom, the netcode in the Build games is entirely nonfunctional currently, and due to a variety of reasons, the only chance to see anything happening on that front is either a) a dedicated developer to join us, or b) external contributions.

As a result, multiplayer stays dead, unless the circumstances change - but at any rate, that's not happening anytime soon.

[Rachael]

Find me a developer willing to invest time here and we may talk again.
Keeping a multiplayer setup working is a far from trivial and often very time consuming task and surely needs someone with dedication and a lot of free time. Such developers are very hard to find as can be seen by Zandronum development having ground to a halt.

Need some experience too.

Multiplayer is not a trivial task even if you have lots of time on your hands. Keeping the game state in sync on multiple systems is not a task that is easily done without deep knowledge of both C++ and of the ZDoom code base.

[Redneckerz]

Find me a developer willing to invest time here and we may talk again.
Keeping a multiplayer setup working is a far from trivial and often very time consuming task and surely needs someone with dedication and a lot of free time. Such developers are very hard to find as can be seen by Zandronum development having ground to a halt.

Need some experience too.

Multiplayer is not a trivial task even if you have lots of time on your hands. Keeping the game state in sync on multiple systems is not a task that is easily done without deep knowledge of both C++ and of the ZDoom code base.

I kinda have a feeling the OP didn't arrive with the best of intentions when asking. I say that, admittely, purely by judging by his post count.

On that note, Multiplayer Doom is a different league of its own, to the point where the only GZDoom based fork of it is a different community altogether. Odamex focusses on stackable loading and 32 bit color rendering and ZDaemon is closed source with a ton of custom ACS additions thrown in (And admittely, it really does look impressive what that community pulls off) albeit both use a ZDoom 1.x chassis.

Perhaps in the future folks will look into a more modern source base - 2.8.1 is pretty perfect for that one since its a time capsule in terms of features. But alas, so are the thoughts of the (slightly) young and naive.

[Graf Zahl]

I kinda have a feeling the OP didn't arrive with the best of intentions when asking. I say that, admittely, purely by judging by his post count.

You are probably right there. It definitely smells fishy.

On that note, Multiplayer Doom is a different league of its own, to the point where the only GZDoom based fork of it is a different community altogether. Odamex focusses on stackable loading and 32 bit color rendering and ZDaemon is closed source with a ton of custom ACS additions thrown in (And admittely, it really does look impressive what that community pulls off) albeit both use a ZDoom 1.x chassis.

That's also an issue. From what I understand, even the multiplayer communities around the different ports are quite insular, too.
But as it stands, there's still two ways to do multiplayer, either as a classic P2P setup or as a dedicated C/S port. The latter one requires a lot of work on the game code to optimize the data. EDuke32's solution of brute forcing a snapshot of an entire play frame simply won't work for Doom because the game data is not really in a state to do that efficiently, much less for GZDoom.
And P2P is a lot more hit and miss with Build games than with Doom as well, there's simply too much undefined behavior in the engine and the games that may trigger at the most inconvenient points. There's also the issue that some of the games run play effects in the render code at render frame rate. As long as everything is locked to 60 fps that will probably work fine, but not if things run faster. I only today fixed an issue with Redneck Rampage Rides again where code ran way too fast with VSync off. For multiplayer games such things are deadly.

[Duke91]

I was about to create a topic about it but I think it's better to ask here: what about splitscreen? any chances to be added in Raze in the future?

[Graf Zahl]

How about something realistic?

Sorry, the answer is the same 'no' I have given for GZDoom all those years.

[Rachael]

I don't think we can even begin discussing this until each of the games are abstracted somewhat a little bit more. This is literally putting the cart before the horse - if work was invested in multiplayer now, it would be 4 times the work to support all the supported games, plus adding on top of it the extra amount of work to abstract the games later due to separate multiplayer implementations. All of that would be saved by just waiting a bit until more of the individual components of the engine can be organized and combined in better ways to serve all of the games while constructing narrower code paths to allow for some code de-duplication.

I don't know how far Raze can go with this particular goal, but I imagine it isn't anywhere near the point where it wants to settle on this particular issue in order to be able to take on more complicated things layer on, which logically would include multiplayer.

[Redneckerz]

You are probably right there. It definitely smells fishy.

At this point that fish has become dirty rotten over the smell.

On that note, Multiplayer Doom is a different league of its own, to the point where the only GZDoom based fork of it is a different community altogether. Odamex focusses on stackable loading and 32 bit color rendering and ZDaemon is closed source with a ton of custom ACS additions thrown in (And admittely, it really does look impressive what that community pulls off) albeit both use a ZDoom 1.x chassis.

That's also an issue. From what I understand, even the multiplayer communities around the different ports are quite insular, too.

Agreed. All 3 MP ports deliver in spades in terms of quality, especially considering what they are running in the first place. But yes, both ZDaemon, Zandro and Odamex are their own little islands - ZDaemon a bit more so than Oda. So there is little interchangement of code or feature talks between them.

It does highlight how stable the ZDoom 1.x framework is though. Recently found a very obscure and old bot port based on ZDoom 1.22 (and DoomBot 5.1) and it just runs pretty flawlessly. Same with Xmas99 and Xmas00 - Its approaching two decades of old code and it still just runs nigh on perfect sans for the 8 bit palette conversion.

I was about to create a topic about it but I think it's better to ask here: what about splitscreen? any chances to be added in Raze in the future?

Unfortunately what for you just requires one sentence to ask requires the developer several lines of code to implement. Its easier said than it is actually done, especially with new features that weren't already inherited from other ports.

[Valken]

I was just searching for this subject because Skornedemon released his Five Nights for Freddy 4 Doom here https://gamejolt.com/games/five-nights- ... mod/230296.

GZDoom supports background video and sound, but NOT joypad Dinput or Xinput BACKGROUND yet.

But I found that this build of LZDoom from DRFRAG can support splitscreen play with controllers that are out of focused:

viewtopic.php?f=231&t=62157

Can GZDoom at least build in this support for the variable "joy_background" true or false, so dinput / xinput can be intercepted while defocused?

This will free up the KB and Mouse for one player and up to X players can have control pads.

Even better if GZDoom can allow multiple USB KB+M combos on the SAME PC.

My PC is hooked up to the living room TV so our family can play some splitscreen games together.

This would be great for somewhat "family" friend GZDoom mods, even if not online.

[Rachael]

I personally do not mind this. But I am not the one calling the shots on that one.