SSZDooM (Splitscreen ZDooM)

You should not need to mark the game as "netgame" - just "multiplayer" should be sufficient. (Check the CCMD (map) in g_level.cpp for info) - that alone should fix quite a number of hacks related to disabling netcode.

What you do need, obviously, is some way for the second player to receive input.

The way I would suggest doing this is creating 3 CCMDs: console # <command>, +console # <command>, and -console # <command>

There's also gamepad considerations, where one gamepad can control player 1 and one can control player 2.

As for the renderer, I really am not sure the best way to handle that, to be honest, but I am not sure I would handle it in such a hacky way - especially considering the potential framerate loss.

One thing to consider about the software renderer - especially considering most screens are widescreen these days - the narrower your X field, the faster it goes. All calculations are done per-column and the Y-field is nothing more than texture bursts (with the exception of the span drawer, but that's a different story).

I'm implementing some of your suggested changes now. Honestly, the game runs at full playable speed regardless, and such a method was necessary IMO to prevent having to butcher half of the rendering code. xD

EDIT:

Changing netgame to false and multiplayer to true results in a crash on startup.

Last edited by DumdogsWorld on Fri Feb 03, 2017 2:44 pm, edited 1 time in total.

The render part is the least of my worries. In GZDoom at least due to the Stereo3D stuff by Biospud it is already set up to be capable of rendering two viewpoints in one scene. It will only require minor tweaking to change that code to render two distinct viewpoints.

The biggest challenges will be sound playback and proper integration with the playsim and this code really needs reviewing rather sooner than later because so much has changed.

I just don't want to post anything before it's ready. Buuuuut...I see the logic in not sticking ZDooM at this point.

So here's what I'm going to do.

I'm going to download the latest GZDooM source code from GitHub (or where ever it is that I would find it) and I'll carry over the changes once I finish installing a newer version of Visual Studio. As for sound playback, I'm most likely going to find where the sound distance checking is done for fade, and use the lesser of the two distances from each player from the sound source origin. (Assuming sound fading is the issue we're talking about...which for all I know it might not be...)

I just don't want to post anything before it's ready.

That's actually what I would ask you not to do. What you consider "ready" may well turn out unusable for reasons you may just have overlooked.
I had to reject PRs of good ideas in the past for the sole reason that the implementation had some deficiencies which were not obvious to the submitter.

The sooner I can have a look and give feedback, the lower the risk of something shitty happening late in the game.

I see. Well, I'm still gonna do some things first, but not as much. I wanna rename some of the new functions and variables to use proper naming conventions, make new functionality only operate when splitscreen mode is "turned on", etc. I guess I'm not looking to "finish" the project now, but just to polish it so it doesn't look like a 4-year-old wrote it. xD I'll have you the code by tonight.

The function which calls Renderer->RenderView() (well, actually the function which calls that function) alternates back and forth between player 1 and player 2, essentially dedicating half of the framerate to one player and the other half of the framerate to the other player. The actual class which handles the Direct3D calls (specifically, D3D9's present() function) has a new variable which indicates whether or not the current player being handled is the first or second player.

The references to DirectX concern me. Are you saying that this is Windows only? If that's the case, I doubt this would ever get a merged into GZDoom proper, and the rest of us would have to use other source ports for split screen (ATM edward850's BananaSplit fork of Eternity is the best option, though it's out of date with the Eternity upstream (nothing a git merge can't fix) and Heretic is broken, requiring the use of *cringe* Doom Legacy until either said support is fixed or 3DGE completes both its Split Screen and Heretic support... preferably the former)

He's talking about the Windows backend of the software renderer which uses Direct3D 9. And you are mostly correct in that this is a part that shouldn't require many changes. Normally you just render two scenes in sequence and then see to it that they get copied to the screen.

I'll have you the code by tonight.

Umm..... where is it? Did something happen that caused delays? Did by "I'll have you the code" you meant by PM? What's going on?

When a playable build is available, I'll be sure to test this. Looking forward to it.

I started some experimentation. There's no actual split screen yet, but the code does actually demonstrate how to spawn additional players, and also allows you to somewhat take control (at least in terms of movements) of the other player(s). This, by itself, could be used as a tool to learn how to properly implement it with multiple screens.

If someone wants to continue this, the variable "playerfornode[0]" is the key - somehow G_BuildTicCmd needs to be run twice, and there's a lot of code in c_dispatch.cpp and elsewhere that will also have to be replicated and changed to filter between input devices. I would suggest creating new variables specifically for splitscreen - "consoleplayer1" and "consoleplayer2" - that playerfornode[0] swaps between for each input.

Don't change the actual "consoleplayer" variable though - that just gets glitchy as fuck and it doesn't work.

(the experiment can be started with "map map01 coop 2" and then bind keys to "control 1" and "control 2")

The render part is the least of my worries. In GZDoom at least due to the Stereo3D stuff by Biospud it is already set up to be capable of rendering two viewpoints in one scene. It will only require minor tweaking to change that code to render two distinct viewpoints.

The biggest challenges will be sound playback and proper integration with the playsim and this code really needs reviewing rather sooner than later because so much has changed.

Okay, I've thought about this and have gone ahead and started planning this out. What I am going to do is hook the VR code directly - i.e. in order to use splitscreen you have to select a VR mode - the reason why I want to do it this way is because there's multiple ways one may want to execute this splitscreen thing - and row-interleaved mode might actually be the best way but some people might like side-by-side views also. That being said - there's just a whole bunch to choose from - so as long as you have two separate pairs of goggles that can handle it - any of them will do.

With that in mind - it should not be that difficult to reset the VR code so that the left viewpoint is always player 1 and the right viewpoint is always player 2.

Sound will indeed be a bit of a challenge but I think if I can at least get a player spawned and a viewpoint set for that player, that will get the biggest hurdles out of the way. I already know how to control both players with the code - I just need to figure out how to filter the inputs (or at the very least, make an external gamepad only affect player 2, or something like that).

Sounds promising Rachael! Too bad the OP disappeared... or maybe he forgot about this. Or maybe his brain split into two trying to figure the code out... we'll never know. :S

I don't quite understand how sound would work though. Does that mean there will be 2 stereo mixes laid on top of each other/ Or will the mix for each player be downmixed to mono and player 1's mix panned to the left, while player 2's to the right... ?

Or maybe his brain split into two trying to figure the code out... we'll never know. :S

This seems to be the most highly likely possibility to me.

I don't quite understand how sound would work though. Does that mean there will be 2 stereo mixes laid on top of each other/ Or will the mix for each player be downmixed to mono and player 1's mix panned to the left, while player 2's to the right... ?

I think this should be left to the user to decide. Especially considering I do plan to allow row interleaved splitscreen.

So if it's row-interleaved, it makes sense to overlay the stereo mix, or even output to two different stereo devices. (They can play with headphones, right? )

If it's side-by-side though, it would make a lot more sense to down-mix to mono, as you said, and have player 1 on the left.

(As a side note: One idea I've toyed with was opening multiple windows for the "splitscreen" - allowing you to play on two separate monitors, two separate keyboards, two separate mice - and yes, even two separate audio devices. Ah, pipe dreams. D: )

Still lots to be done - but I think actually now, the hardest part is out of the way.