SSZDooM (Splitscreen ZDooM)

[DumdogsWorld]

Hello all! New to the forum!

Splitscreen....a feature requested by a small few for almost forever. I decided to finally get around to mapping out the code differences between the ZDooM engine and the vanilla engines, and I've found that my "hacks" used in some of my unreleased custom ports transitioned over quite nicely!

====Notes about this ZDooM fork====

==The Features==
-Splitscreen multiplayer, with 2 players.
-Based off of ZDooM 2.8.1.

==Notes==
-The second player is always in the game, so SSZDooM is designed to run in conjunction with a normal ZDooM 2.8.1 installation. It has a renamed executable, and uses a different file extension for saves.
-Saving currently doesn't work, but is in the process of being re-enabled. Netplay is disabled.
-Make sure you have a PC with Direct3D support. DirectDraw mode is broken.

If somebody can suggest a screen recording software that doesn't actually suck, I would be happy to upload a Youtube video of the program in action. (Fraps doesn't work because of how the port handles the Direct3D backbuffer.)

Until then, I'm uploading a screenshot. Everything is finished so far except for the second player's controls, which should only take an extra day or two to finish up.

====EDIT====

Here's a video of it in action:

[wildweasel]

Does OBS Studio capture the program correctly, I wonder?

[DumdogsWorld]

I'll check. BRB.

EDIT: It works in OBS if I set it to record the whole screen. I'm gonna post a Youtube video above...

[Nash]

That's amazing! Would you consider sending this as an official Pull Request so that it can be integrated into GZDoom? ZDoom has already been discontinued, while GZDoom continues to be active...

[DumdogsWorld]

I could try to request a merge with GZDooM, but there's some things that need to be done first. First of all, I really want to finish the normal ZDooM version first. Second, my changes are hacky and intrusive on the rest of the codebase. I would need to re-work a few things to only happen (or not happen) when the engine is in splitscreen mode, and only in that mode. Also, I need to upgrade my compiler and re-work the changes for the more modern GZDooM codebase. However, I'll likely do all of these things anyway. xD

[Nash]

Sounds promising! I wish you luck in all of these. This is some amazing work!

Also, here's the proper way to use Youtube tags (you can Quote my reply to see the source code)

[Graf Zahl]

Do you have any code that can be reviewed? Getting some feedback now might not be the worst idea.

[drfrag]

One of my old ideas was to make my own sourceport with splitscreen based on an early ZDoom version and WDPM (since both were derived from NTDoom). WDMP had 4 player support. BTW those early ZDoom versions up to 1.22 were unstable and crashed a lot, curious that the official "stable" release was 1.22 for years while 1.23 was beta. I wonder where you got the code from, doom legacy?
This looks interesting but i guess getting netplay and splitscreen working at the same time will be complicated, should be fun anyway.

[DumdogsWorld]

I didn't get the splitscreen code from other ports. I implemented it myself.

[cmw1986]

This is awesome!. Have you ever thought of giving players the option of using either a horizontal or vertical split?.

[DumdogsWorld]

Do you have any code that can be reviewed? Getting some feedback now might not be the worst idea.

I have some, but I want to make it more "friendly" with the rest of the engine before I submit it for review or anything. Shouldn't be too difficult, though. I just need to isolate the new behavior based on a CVAR or something.

This is awesome!. Have you ever thought of giving players the option of using either a horizontal or vertical split?.

Yes, this is going to be a feature. The only thing that I'm debating is whether this should be in the menus or not. Currently, my plan is to have it set as a command parameter.

[dpJudas]

I have some, but I want to make it more "friendly" with the rest of the engine before I submit it for review or anything. Shouldn't be too difficult, though. I just need to isolate the new behavior based on a CVAR or something.

Getting a rough idea on how you implemented it would be really useful to know. The latest release of ZDoom uses a rather old version of the codebase where I have made some changes to both the software renderer and the framebuffer classes.

Especially when it comes to QZDoom I refactored the r_* family of files to look completely different. GZDoom is not using that version of it yet, but there's a good chance down the road it will, so I'm interested in knowing exactly at which points in the rendering process you hooked in the split screen.

[Graf Zahl]

Not only that. Another big issue is that this is based on 2.8.1 which is pre-portals and pre-floating point, which has a high risk of the code already being somewhat obsolete. If we can do some reviewing now, it may save you quite a bit of work. We are not here to trash your work but to ensure that it can actually be used. It'd be a real shame if it went to waste because it turns out too late that some breaking issue prevents integration.

[Rachael]

Graf and dpJudas are right. To add to that, there hasn't even been a question answered about whether or not this will work in GZDoom yet. If there's a port the community would want catered to, that would be it.

The software renderer is nice (and we still do work on it when we can) but the OpenGL renderer is what receives the most play.

[DumdogsWorld]

I'll post some code once I get player controls implemented, but I'll go over the changes in a rough summary now.

First and foremost, the splitscreen mode marks the game as being in netplay mode with 2 nodes and 2 players, which handles the majority of the changes automatically. However, it disables various functions related to receiving network packets and suppresses a warning message about the game desyncing over the network.

As for the software renderer, it's like 99% untouched. I haven't touched anything related to the rendering of levels, sprites, etc.

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. Depending on the value of that variable, the present() function uses a different bounding box for the draw region on the window. (That's why Fraps doesn't record it correctly.)

StatusBar->AttachToPlayer() and StatusBar->Tick() are also called to prevent the need for two StatusBar instances. For this hack to work, stat interpolation (like the health counter in Heretic) had to be disabled. It also does some funky things to the preview of the player's head in DooM 1 and 2, so I'm disabling the player head preview in the status bar for now.