51
Melty Blood Auditorium / Re: The MB:AA:CC:PC thread: at least the netplay will be good
« on: August 29, 2011, 08:59:01 AM »Sorry, I'm not really sure I understand what you are saying here. Are you saying, if I set an input delay of 5, and press a button, the game wont actually try to send the packet until 5 frames later?? That seems kinda bad?
If the scenario I posted above was correct (apart from some minor maths fail ), then doesnt it mean that a person who sets his input delay to 0, will get instant response on his own screen, and cause maximum skipping and rollbacks on his opponent's screen? Doesnt it mean that setting zero delay gives you an advantage over your more considerate opponent?
No, this is wrong. It's about the synchronization between the two systems. Take the following example.
- There is a buffer value of 5 frames set for the match, to indicate an upper bound on the latency between the players. This is used to synchronize the games and prevent them from becoming too far apart, eg through packet loss or one computer slowing down.
- Current frame is represented here by the value N.
- The synchronization frame is N+Buffer-Input_Delay. This is because literally the only reason you would add input delay is to reduce the amount of visible rollbacks.
- Player A has input delay 0 set. When he presses a button, it sends data for the frame N+0. Player A synchronizes for time N+Buffer-Input_Delay = N + 5, and will not proceed until this data is received. Player A will see 5 frames of rollbacks from Player B.
- Player B has input delay 5 set. When he presses a button, it sends data for the frame N+5. Player B synchronizes for time N+Buffer-Input_Delay = N + 0, and will not proceed until this data is received. Player B will see no rollbacks from player A.
- Player A and Player B are thus waiting on different frames(N+5 vs N+0), and sending data for different frames(N+0 vs N+5), causing a net change of zero.
- Both players will be showing the opponent's data as soon as it is received, it's simply a matter of trading off input delay vs rolling back.
- In the event that both players are sending data for N+0, they will still synchronize at N+5, causing both players to run the game 'ahead' by 5 frames. You can't erase latency.
RollCaster has few special rules for handling packet loss, allowing one frame of drop before holding the game up, is handled as follows:
- There is a GracePeriod value that is initialized to zero.
- If the data for the next synchronization frame is not received and the GracePeriod value is zero, flag GracePeriod and run the game one frame anyway.
- If GracePeriod is non-zero and not all data for frames up to the synchronization frame are received, block and wait.
- If the data for all frames up to now are received, reset GracePeriod to zero.