MrThunderwing wrote:Hey gm_matthew, hoping I might be able to catch your eye here:
So, I've finally been able to try out a proper 2 PC network: I get quite considerable slowdown on both machines when it's running - One of the PC's is pretty old, so I have to use the legacy 3D engine on it to play games at full speed on it,
but they do run at full speed like that. The other is an i5 that can normally handle multiple instances of Supermodel open on it, using the new 3D engine, without slowdown, so why would they get slowdown when linked? I'm definitely got the SimulateNet = 1 option, so I'm not accidentally using the old slow network. I've experimented with different resolution settings on both machines, just in case that made a difference, but the slowdown is no different with both machines running at native res, compared to being upscaled into 1080p.
This is over a wireless LAN BTW. Is there anything you can suggest to try and get them both running at the right speed when linked?
If I understand correctly, the games run in lock-step and actually use a blocking wait for the packet from the previous node in the ring. That means they can't really proceed until a full round trip has been made, which is likely to be longer than 16 ms. So your frame rate suffers. The actual hardware uses a very low latency fiber optic link so the developers didn't have to worry about any of the issues that occur over the Internet or slower links. They had the luxury of assuming the data would always be there every frame without fail.
Mitigating this would not be trivial. But I wonder if roll back netplay could one day be added. Matthew didn't think it would be possible but I wonder if something like this could work:
- Render frames and save the complete Model 3 state of each frame (32MB per frame, if done naively).
- When a packet finally arrives (N frames late, of course), we go back to the frame we know it was supposed to arrive at but didn't, and load that state, then run forward for N frames (don't render any of them, just run the CPU emulation) back to the present time.
- Now we have "replayed" the last N frames but with the correct packet data for that prior frame. The world will look slightly different.
- If this produces a jarring jump (I don't think it would unless vehicles collided), could probably smoothly interpolate the positions of objects over the next few frames from the old incorrect one to whatever the new one is (but would have to keep running the old, incorrect timeline side by side and that could get messy).
Packets would only be sent after being received (so that the receiver always knows the sender has always incorporated whatever was last sent). In the in-between frames where nothing has been received, we would have to supply fake data. Maybe writing the same packet over and over again is sufficient or maybe each game's packet has to be reverse engineered to supply some plausible fake data (e.g., for car positions, just keep moving them in a straight line).
In typical rollback netplay systems, I think that state information is *not* typically sent each frame (e.g., positions don't need to be transmitted), only inputs or special events ("bullet fired", "bullet hit player"), and these are compared to determine whether state needs to be rolled back (e.g., my client doesn't think your bullet hit me but suddenly gets a message saying "bullet hit player 1" from the other client, indicating the clients are out of sync).
Needless to say, even if this zany idea could work, it would require a tremendous amount of re-architecting of Supermodel itself.
Can you try with over Ethernet? What is your ping time between machines?
