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>]
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.
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.