SSZDooM (Splitscreen ZDooM)

[Nash]

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

Awesooommmmmeee. RIP player 2.

[Danfun64]

...4 player mode would be nice. Also would be nice if you used the same variables that BananaSplit Eternity uses (namely LocalPlayers x).

[Rachael]

That will not be possible until I get to be more versed in playing with the input code. I'm trying to simplify what I have now, and make it more robust, so that future extension will be possible.

[Danfun64]

Even so, it's awesome that ZDoom might finally be getting split screen, and it's also awesome that Doom keeps getting more source ports with Split Screen that aren't Doom Legacy.

[Jaxxoon R]

Hell yeah, I've been fiending for some Doom couch coop for a while now. Never thought it might finally come to my sourceport of choice though, considering I've seen a lot of splitscreen Zdoom attempts come and go over the years.

[Rachael]

Making progress.

Good news: The status bar is now split between players.

Bad news: Both status bars are still attached to the same global system. The only way to get a unique HUD for players is to use the fullscreen Alt_HUD for now. Anything that uses SBARINFO is still unusable, as of now, in this implementation.

Everything is shared between both players, for now, unfortunately, including how pissed the marine mugshot is.

[Rachael]

I think I've gotten as far as I am going to get with this, for now.

Unfortunately, to do this properly it's going to require a lot more work. What I have available right now is the "gross hack" method - and by "gross hack" I mean it will not survive a refactor of some of its key underlying structures - which, last I talked to Graf, some are due to occur in the near future. It's also buggy - and probably will crash. In other words, it's so extremely alpha that there's a reason why this is not even on the master branch right now.

If you want a devbuild containing my progress so far, here it is: https://www.sendspace.com/file/otc7kb
Source code for this build: https://github.com/raa-eruanna/qzdoom/t ... a4a540a1de

There are several new commands, a couple are for debugging and testing, all of which have the potential to cause crashes: (in other words, no safety checks)
map <mapname> [<coop/dm> [<# of fake players>]]
control <player #>
When you execute this command with a number after coop/dm - this initiates "fake player" mode (a mode similar to what was in Duke Nukem 3D) - all it does is it spawns extra players. If player spots are not available it will exit the map and return you to the console.

After the players are spawned you can use "control #" to control the selected player slot. Note that this works on bots as well (but only if the game is started with fake players present).

These are likely not to make it to the final version (which will probably not occur until after the QZDoom merge), but if they are useful for local multiplayer testing they can certainly be considered.

These will probably also cause net/demo desyncs. You have been warned.

The purpose of the code behind this was mainly to find out how to actually "drive" the extra players.

[<set/toggle>] splitscreen [<true/false/1/0>] (cvar)
This "enables" the actual split-screen mode. This will spawn an additional player for you. You cannot leave the map with this player or it will crash, and if you spawn outside of a map and enter a map, it will crash then as well.

splitswap
This command simply swaps positions between player 1 and player 2 of the splitscreen, nothing more. It pretty much has the same effect as "control" for the fake players mentioned earlier.

*** What remains to be done ***

1) The code needs to be rewritten. Completely. I am not sure I have the motivation or the drive to do that right now, but the hacky and invasive method that this uses simply will not fly. Luckily, there are several systems and each system operates somewhat independently, so if one is rewritten it will probably not affect the others. As I said before - entering any level with splitscreen enabled causes a crash - you must disable it when you exit and re-enable after entering the level again.

2) The status bar code: Oh boy where to start. I can see where Graf had his gripes about it - the state of the status bar is actually stored in its loaded definition, itself! (At least from what I could tell) - In order to do this properly, I think the status bar code itself needs to be rewritten so that it doesn't do that. It was no wonder why when I had two completely separate status bar objects they shared the same data. Luckily, in Strife or with alternate hud enabled, this is not a problem. But otherwise - yeah - gross hack is gross hack. It works in Doom, but with any game that has an interpolated status bar (some mods, Heretic, Hexen) it will not work.

3) Sound code: Have not even tried to touch that, yet. Player 2 will have no sounds.

4) Input code: Right now only the analog sticks on the gamepad are coded. Everything else will direct to player 1. I don't even know if the gamepad will work. (I do not have one yet to test)

5) Software renderer: Due to the split with GZDoom and QZDoom I also have not touched this code. So in order to use this you must be running OpenGL with render buffers enabled.

So that's that. I don't plan to abandon this completely, but with the state this code is in, and with the current state of GZDoom and QZDoom in general, there is not much reason to continue this beyond finishing the input code. Once we commit to a unified sound backend (probably OpenAL) sound support can be considered.

Beyond that, have fun! If I haven't said it before - it'll crash.

[drfrag]

Both status bars are still attached to the same global system.

Perhaps it's best not to show the status bar in splitscreen mode.

[cmw1986]

Perhaps it's best not to show the status bar in splitscreen mode.

That actually might be good for a 4-player splitscreen game in my opinion.

[Danfun64]

Perhaps it's best not to show the status bar in splitscreen mode.

That actually might be good for a 4-player splitscreen game in my opinion.

Perhaps it doesn't work with ZDoom (yet), but having 4 player split screen with the status bar can be done with other versions:

Eternity (BananaSplit Fork)


Doom on Xbox 360 & Playstation 3

[Rachael]

The other versions do not have the problem with how the status bar and its actual data tracking is set up.

Also, it's impossible for me to code input filters without the proper input devices. I am still waiting for a controller to come in - and I promised someone that when it came in, that I would finish 3DGE's splitscreen support, first, before I did ZDoom's.

[Graf Zahl]

And furthermore, as nice as this all is, I think the first priorities now should be to finish ongoing construction, not open up new areas. Some stuff about how status bars are done needs changing for splitscreen, I also have a few ideas here ( the most important one being that status bars need to be owned by players and not by global variables), but this will have to wait until after a 3.0 release which merges GZDoom and QZDoom into one engine again. Changing this stuff now in a branch that depends on lots of other unmerged features only makes things harder in the long term. The most important thing to do now is to get a unified code base again so that the necessary refactorings that are necessary to stabilize the software renderer's multithreading support can finally be done - and only after that - when the work on the low level code is sufficiently complete, then it is time to think about the status bar. (Of course this will also mean that any refactoring on it is on hold until this far more fundamental issue can be resolved.

To summarize, for me personally the priorities are:

- get GZDoom 2.4 out some time in March, i.e. I just stopped with major code refactoring and will concentrate on bug fixes, small additions and code cleanup from now on.
- get the software renderer into a genuinely stable state again. I think dpJudas is close but I'd need some info about what's still missing.
- after 2.4 is out, merge both ports again and work towards a 3.0 release.

Once this is sufficiently complete we may actually do some planning and scheduling how different features are approached. To do splitscreen really right it needs some design changes in the basic foundations of the engine and to be honest, while I appreciate the work that has been done here, it started from the wrong end. The first thing this needs is to build the foundations in the renderers to actually render two viewpoints properly and then extend the feature from there. But like I said above, this absolutely REQUIRES that both renderers get merged first so it won't end up a coding mess that's hard to put together again later.

Right now the entire branch is extremely experimental and most of it will very likely not end up in the final product before seeing some major rework.

-

[Rachael]

Right now the entire branch is extremely experimental and most of it will very likely not end up in the final product before seeing some major rework.

My thoughts exactly. I did what I got done to learn the systems needed, and that should make it a lot easier for my next attempt at it. As I clearly said in my distribution post, this is not done and will require an extensive rewrite - not only of itself, but of the underlying systems that it depends on.

If nothing else, though, it has proven to be a nice coding diversion. It will be impossible to maintain this past the 2.4 release when the fundamental systems do start getting reworked, and inevitably the affected parts will have to be done from scratch.

After I finish 3DGE's support, I do plan to complete the input code for this version if nothing else to serve as a proof of concept for what can be done. The real version can take what little bits of code that are usable from this branch and that should speed development along from that end.

But as I plainly said - much of this code is way too invasive. This penetrates way too deeply into the game's systems, much more than I am comfortable with, and if the systems had been written correctly the first time around that would not have been necessary.

And furthermore, as nice as this all is, I think the first priorities now should be to finish ongoing construction

If you think I can handle something that will help you out, please point me in a direction you want me to start working.

[Graf Zahl]

If nothing else, though, it has proven to be a nice coding diversion. It will be impossible to maintain this past the 2.4 release when the fundamental systems do start getting reworked, and inevitably the affected parts will have to be done from scratch.
[/quote]

As a future guideline the code is very helpful. But the very first thing that needs to be done for this to work well is to refactor R_SetupFrame to lose its dependence on global variables and instead fill in some struct with the calculated data so that multiple viewpoints won't trash it. Of course this will have some repercussions throughout the entire renderer because it may suddenly no longer be able to depend on these global variables.

And furthermore, as nice as this all is, I think the first priorities now should be to finish ongoing construction

If you think I can handle something that will help you out, please point me in a direction you want me to start working.

[/quote]

The most important thing is to get the software renderer refactoring completed.

I am currently working through the old feature suggestions forum and add everything that is easily doable and move interesting stuff for later to the "on hold" forum. Most I will dump, though, because a lot of it is either of low interest, can be done with scripting now (or soon will be doable) or is just too much work, and with Randi gone I just do what I otherwise would have done on sight: Nix it.

[dpJudas]

On the subject of the software renderer refactoring, its status right now is that globals/class refactorization is done.

I have two known regressions: decals in pal mode uses the wrong light, and voxel blend modes are not working. Other than that I'm not aware of anything broken (when compared to GZDoom, not last ZDoom official release). There also needs to be added a few #ifdefs that will allow things to build and link on systems with no SSE. Of those things, probably only the voxel blend modes will take a little time to get fixed. I sacked the rt family of drawers, but the voxel blend code was relying on it.

In the longer term, what would be really nice to get fixed in the software renderer is the crime against humanity known as r_walldraw. That file does some amazingly complicated stuff that really boils down to "draw a wall column taking light planes into account". I've been trying to simplify the logic in r_line to try figure out what the code is trying to do. If this could be cleaned up, it would allow for specifying texture coordinates and light in a more sane human friendly way.

The other thing that would be nice to fix is to somehow streamline the drawer capabilities. We have four main drawer groups: wall, span, sprite and sky. The wall and sprite drawers are both column drawers. They are pretty much alike, except the blend functions are different. Sprite supports translations, walls do not. The span drawers can draw textures with rotated texture coordinates, the wall and sprite drawers cannot. If we could merge wall with sprite and add rotated texture coordinates, then the renderers could get support for using a matrix transform for UV calculations.

Both of those things are probably better to do as a new project in a new branch. While I have no doubt that a final version here would be 1000 times more pleasant to work with codewise, the rules in the current code are so convoluted this is almost certain to cause some regressions and require a lot of testing before it would be ready.