Split-screen theory

[leileilol]

Seeing as there's a lack of local play....

Doom Legacy pulled it off ages ago (as well as a similar client/server system to quake (and other fishy stuff similar to quake implying use of the 1.01 leaked code, many months before the GPL source release)).

FTEQW has it (Weirdly implemented IMO)

Bind2/3/4 commands to handle control configuration of other players?

joy_assign2, 3, 4, to assign multiple gamepads to specific players?

No bf/palette shift effects?

stuffcmd'ing stuff like cl_maxspeed to the second player locally?


Was this ever explored in homebrew console ports?

[Spike]

doom has it quite easy in that every client has a complete copy of the entire game state. you can presumably just set some variable and you're instantly viewing the game from someone else's eyes.

for quake, you need a separate copy of each player's settings. you can achieve that either through multiple network connections to the server (spammy!) or by merging all players into a single connection (which is what fte does).

single-connection may require custom servers, but on the up side, bprint sanity becomes trivial.

stuffcmds are always going to be evil. doubly so if the engine has 4 clients but only one console. that's never going to work well. same issue with binds. which is why fte has some 'p2' and '+p2' or so prefix command to direct commands to specific players. name+colour+etc are all stored in the quakeworld userinfo rather than actually in cvars which at least keeps server-visible stuff boxed up. all the input/button commands pay attention to that prefix command stuff so binds etc work. also it nests, so 'bind a "+p2 forward" ' will move player 2 forward even if its pressed on player 1's keyboard, for people that have only one keyboard, and without the p2 part, you can move the right player forward based upon the keyboard device index (if pressed on player 3's keyboard, it becomes "+p3 p2 forward" thereby forcing player 2 forward even on player 3's keyboard, and without the p2 it correctly controls player 3 rather than 1).
yeah, you can't bind different keyboards differently, but I'm just not sure how much point in doing so there is. the same kinda goes with gamepads. user-visible complexity for complexities sake.

so yeah, you can either identify the input device and control the appropriate player and not care about player-specific binds (good for dual mice or gamepads), or you can explicitly bind each button to some action (good for keyboards, but pretty much useless for anything else).

bf can be implemented either globally (software I guess, all bf commands add up), or player-specific (glquake typically draws these with a fullscreen quad, just draw it sub-screen instead, you get the idea).

stuffcmds of cl_maxspeed are evil. mods that use that should expect their stuffcmds to get ignored by cunning binds. You cannot break what is already broken, so I wouldn't bother separating such cvars for such mods. I know quakerally messes with that stuff, but quakerally at least messes with that stuff for every player equally so nothing is actually broken.

[andrewj]

Spike, with your single-connection approach, do you (for example) SV_WriteEntitiesToClient independently for each player, or optimise the network traffic by sending each entity only once (i.e. if it touches the PVS of either player) ?

P.S. there is a Quake 3 port with splitscreen capability, be interesting to see how they handled the input side of things (etc).

[Spike]

only once. yes this breaks viewmodelforclient. few mods use that anyway, and the ones that do would ideally use csqc instead. and yes, csqc+splitscreen is another world of pain, but if the csqc is aware and does the grunt work all the problems go away (like in q3 console ports)