[z64555]

While messing around with the input controls, I started wondering about the possibility of FSO being able to do split-screen coops and multiplayer, where there's more than just one pilot at a machine.

I see two variants possible, with several sub-variants:
  1. Each player has their own GL canvas on the screen

• Each player is their own pilot, and have their own craft
• One or more player(s) is a pilot, and the others are turret gunners on those craft

  2. Two or more players share a GL canvas on the screen

• One may be the pilot, and the others may be forward gunners (camera is controlled by the pilot only).
• No one is the pilot, and all are forward gunners (rail shooter, camera is controlled by AI).

I see four major hurdles to accomplishing this:
  1. Controls
  2. Graphics
  3. Multiplayer
  4. Pilot File

Controls should not be too big of an issue... just add another enum to identify which keyboard, mouse, joystick the input is coming from and map it to the action. Conflict checking would need to be expanded to check all currently active players in addition to checking across all attached input devices.

Graphics shouldn't be too big of an issue, either, thanks to advances in the camera codes as well as the experiments with the render canvases. Interface to determine which player/pilot uses which render canvas seems to be the biggest issue here.

Multiplayer would be a bigger issue, because it would have to cycle through all players on the local machine before constructing the packet. It may be simplified somewhat with turret controlling players, because their controls are more basic than the pilot.

The pilot file is going to be the big issue, because I can't really think of a good way of making it compatible with the additional preferences right now...

[headdie]

I nearly laughed at the idea of this in FSO until i saw who posted it.

As an idea i think it would be a great feature to have and I can see it contributing to multiplayer and if some coding wizard manages to make this work then massive thumbs up from me.  If someone does go through with this my personal preference would be for the separate craft idea, though the second idea with split screen would have some interesting possibilities.

As for the potential pilot file issues, how would the new pilot file(tm) code scale to this?

[karajorma]

I see bigger problems than that. You're going to have to check and maybe fix every single reference to Player_obj, Player and Player_ship. That's well over a 1000 references.

It's not impossible, but it is a massive task.

[z64555]

I nearly laughed at the idea of this in FSO until i saw who posted it.

As an idea i think it would be a great feature to have and I can see it contributing to multiplayer and if some coding wizard manages to make this work then massive thumbs up from me.  If someone does go through with this my personal preference would be for the separate craft idea, though the second idea with split screen would have some interesting possibilities.

As for the potential pilot file issues, how would the new pilot file(tm) code scale to this?

The new pilot file code offers sections, which means a new section could be added to handle the split screen controls. The split screen controls section differs from standard controls in the sense that a control device (namely keyboard) could be shared between two or more players. If we were to use the old controls config screen to configure the shared controls, it would likely be a big hassle for people to switch between a config screen per player just to find a set of keys to work. The simplest answer for this would be of course "one keyboard, one player," and then have support for multiple keyboards, mice, joysticks.

However, multiple mice, joysticks support is where things get interesting. The pilot file stores the axis to which an axis action is mapped. So, for example, for pitch, heading, bank, and forward thrust, you have an int axis_map_to[] array with a size of 4, and a bool invert_axis[] array of also 4. This is what the int's mean in those two arrays:

(Value of an axis_map_to[] or invert[] entry)
<0 = undefined axis (no axis is mapped)
 0 = X axis (joy and mouse)
 1 = Y axis (joy and mouse)
 2 = Z axis (joy)
 3 = Rx axis (joy)
 4 = Ry axis (joy)
 5 = Rz axis (joy)

As you can see right here, there's immediately a problem for split-screen coop because the mouse and joystick axes are linked together. It may be possible say 6 = mouse X and 7 = mouse Y and then copy that scheme for joystick 2, 3, 4, etc. and mouse 2, 3, 4, etc. to keep compatibility with antipodes as it is right now.

However, I dislike going this route because it is not scalable for joysticks/controllers that have more than 6 axes (such as those that have a trackball or a thumbwheel). I'm brainstorming for ideas on alternatives, but so far they all ditch the old axes setup (i.g. axis_map_to[] and invert_axis[]).

As mentioned before, split-screen controls which share a keyboard and/or joystick may be made into it's own section, since one of the goals here is to be able to have the same pilot file for both single screen and split-screen modes.

[EDIT] The E was kind enough to point out the new pilot file version system. This should make any future changes to any given section easy, since you can stuff the old data (for any given version) into the new formats (if any).

I see bigger problems than that. You're going to have to check and maybe fix every single reference to Player_obj, Player and Player_ship. That's well over a 1000 references.

It's not impossible, but it is a massive task.

Not to mention to figure out how to make sure that the mission doesn't end for everyone else when one guy dies, as well as ensure the sexp's and lua scripts still work... quite massive task, yes.

[MatthTheGeek]

Not to mention to figure out how to make sure that the mission doesn't end for everyone else when one guy dies

Well standard coop already does that. Don't invent yourself problems that are already implemented

[chief1983]

I see bigger problems than that. You're going to have to check and maybe fix every single reference to Player_obj, Player and Player_ship. That's well over a 1000 references.

It's not impossible, but it is a massive task.

Maybe there's a workaround that could be done, by somehow fooling the engine into running an additional instance within itself somewhat.  That would probably be a lot of work too, but if the layout is conducive to this, it could be a lot less.  Each instance would just think the other instance is a different mutiplayer pilot.

[Al-Rik]

While messing around with the input controls, I started wondering about the possibility of FSO being able to do split-screen coops and multiplayer, where there's more than just one pilot at a machine.

I see two variants possible, with several sub-variants:
  1. Each player has their own GL canvas on the screen

• Each player is their own pilot, and have their own craft
• One or more player(s) is a pilot, and the others are turret gunners on those craft

  2. Two or more players share a GL canvas on the screen

• One may be the pilot, and the others may be forward gunners (camera is controlled by the pilot only).
• No one is the pilot, and all are forward gunners (rail shooter, camera is controlled by AI).

First Strike, a Star Wars Mod for Battlefield 2142 has user controlled Ships with one player as pilot and up to 5 other players as gunners.
It's funny, especially for Cap Ship Combat, so IMHO the idea is good... but why a split screen ?

A setup with on server ( dedicated or not ) and a second PC for the client would be much easier.

[z64555]

First Strike, a Star Wars Mod for Battlefield 2142 has user controlled Ships with one player as pilot and up to 5 other players as gunners.
It's funny, especially for Cap Ship Combat, so IMHO the idea is good... but why a split screen ?

Split screen allows all cooperating players to aim/look in their own direction from the gun turret/starfighter while using the same screen. I think it's impractical for more than 2 players to do split screen on anything smaller than a 14" screen, those with screens at 19" or larger can benefit.

A setup with on server ( dedicated or not ) and a second PC for the client would be much easier.

The goal I see with same-screen coop support is to allow modders more room to experiment. Schump-style and rail shooter mods (such as SHMUPSpace would immediately benefit. As a side benefit, strategy style mods such as the FS RTS Mod (WIP) may make use of PIP graphics windows (like in the Earth 21xx series).

[Droid803]

Oh cool with dual monitors and splitscreen I can fly two fighters at once.
Finally something to do with those three extra hands I have.

[z64555]

Oh cool with dual monitors and splitscreen I can fly two fighters at once.
Finally something to do with those three extra hands I have.

Droid has been playing Mortal Kombat, I see.

[Valathil]

AHAHAHAHAHAHAHAHAHHAHAHAHAHAHAH no -_-

EDIT: Long answer: nooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo oooooooooooooooooooooooooooooooooooooo

[guitarfan01]

I really wish I could like Valathil's post.

[WMCoolmon]

This is a tough idea. To do it properly would be a big project.

However, as a mod with judicious use of scripting, I think there's some hope. But you'd still have to reinvent a lot of stuff.

Either way you'd have to adjust the graphics engine to render as part of the screen. Either way you'd suffer slowdown because you'd radically increase the number of state changes. I suspect this could be optimized dramatically but would require digging around the graphics rendering code and would be a gnarly, involved process to not introduce bugs.

But if you throw out the HUD and keyboard controls you save yourself a lot of work.

If you wanted to do this for a mod and have it be a project that's of the size that you could reasonably expect it to get done:
(1) Rework game_render_frame to render only to a specific subset of the screen. For future requests, you probably want to make it capable of an arbitrary number of subframes.
(2) Switch off the HUD and disable the keyboard controls involved in manipulating the player's ship. I know there's been some progress in making the HUD more customizable, but I'd be surprised if it's extensive enough to make this doable.
(3) This leaves you with escape, the function keys, and the capability to render 'subframes'
(4) Associate the 'player ship' with some bogus thing. The goal is to invoke the player ship as little as possible.
(5) Configure a HUD with scripting for the subframes you want. Any 3D->2D stuff will likely be messed up (eg rotating/projecting vertices). But you can do ship status and objectives and a crosshair.
(6) Map the controls to joysticks (Has somebody implemented this in scripting yet? ) to move two technically-AI ship, fire the weapons, adjust the speed, fire afterburners, etc.

This ruins a lot of stuff with scoring, difficulty, AI, etc. The controls will be borked and you'll likely have to reimplement a certain level of movement interpolation. But it does give you split-screen control of ships that you could use for a console-style deathmatch thing.

Bonus Round
I vaguely remember being concerned about RTT and game_render_frame when I was doing the scripting for mainhall backgrounds being rendered with a level. If I was concerned enough, I may have tried to make RTT work for game_render_frame.

If RTT already works for game_render_frame, all you'd have to do would be:
(1) Set a render target
(2) Set a camera
(3) Render the frame
Repeat for each subframe.

Then have the 'real' camera pointing at a 'ship' with the textures for each subframe.

I'd expect this to be horribly inefficient.

EDIT: This handles the problem of rendering, but not of controls/HUD. For that you'd have to use my above suggested approach.

[Nuke]

rtt was broke for awhile but last i checked it was fixed sometime during the last rc phase (likely as a result of my constant complaining). there is still some issues with transparency when drawing procedural stuff that im not sure how to resolve. but the general use of it to render from a camera works pretty well. you would have to patch one player's controls into an ai ship somehow and handle all the input and hud separately. i can see modes where you let a second player control a turret or the like, but i dont see split screen multi being an easy thing to do no matter how you attack the problem. you could probibly just run 2 instances of the game and use the loopback port for the connection and play multi that way.

*edit*
just tried the 2 instance approach with no workie. seems once an instance of the game grabs a tcp socket, no other instance can get at it. even if you try changing the ports and the like. there might be a way around it, like with a dedicated server or stronger network-fu. it should theoretically be possible, especially with 8 logical cores to work with, and large amounts of both graphics and system ram. assuming someone gets it to work could probibly just make freespace windows dockable and have the launcher work out the screen resolution for you to account for your native resolution plus window boundries, or use some kind of borderless window.