3 ms·

There are some games this will simply not work for, like fighting games, where even the delay caused by the LCD rendering each frame is noticeable. The ADC in

by snarfy 12y ago

There are some games this will simply not work for, like fighting games, where even the delay caused by the LCD rendering each frame is noticeable. The ADC in the LCD is either too slow or has too much processing happening. Many hardcore fighting game fans prefer CRTs due to this. There is no cure for latency. The network is physical. Instead of trying to abstract it away in a library and assume lag doesn't exist, it should be designed for in the application. The last time Microsoft abstracted the network away, we ended up with asp.net WebForms.

moron4hire 12y ago
Assuming infinite bandwidth and rendering speed: It sounds like, for a connection of latency L, at time T-2L, the server sends to the client multiple fully rendered frames, each representing the render state for time T for every possible user input that could occur between T-2L and T. The client receives these frames at time T-L, while sending a user input state at T-L which the server will use for a future packs of images. At time T, the client chooses the frame to display based on the actual input the user performed at time T, discarding the rest, and the server receives the user's input from time T-L, using it to render and send the next pack of images for time T+2L. So while it is strictly true that latency is impossible to avoid for the first two rendered frames, that's only a small fraction of a second and only at the very beginning. After that it's eliminated. Now obviously, rendering speed and bandwidth change the equation and is probably why there is a limit to the latency it can correct for. But this does appear to be a cure for interframe latency. It's lazy tree culling of every render state at every point in time for every conceivable user input state at that time. It's certainly a big tree, but it seems they are making the statement that it's small enough to fit in modern bandwidth capacities. Of course, you wouldn't be able to use this in your fighting game example to counteract the relative slow speed of the LCD, but that is because there would be no way to cull the set of images at the LCD itself.
- snarfy 12y ago
  It's very similar to branch prediction in modern cpu architectures. Branches are expensive, so both sides are executed. It is a good idea, and I'm wrong for my remark equating any of this to webforms. I believe we have a lot we could do to make latency lower, and effort should be focused there. Branch prediction would not be necessary if branching were cheap. This latency prediction system would not be necessary either if latency was low, but it's not. Our hardware sucks. All of the layers of software suck. OculusVR is a testament to how much room for improvement there is in regards to latency.

by snarfy 12y ago

moron4hire 12y ago

Assuming infinite bandwidth and rendering speed: It sounds like, for a connection of latency L, at time T-2L, the server sends to the client multiple fully rendered frames, each representing the render state for time T for every possible user input that could occur between T-2L and T. The client receives these frames at time T-L, while sending a user input state at T-L which the server will use for a future packs of images. At time T, the client chooses the frame to display based on the actual input the user performed at time T, discarding the rest, and the server receives the user's input from time T-L, using it to render and send the next pack of images for time T+2L. So while it is strictly true that latency is impossible to avoid for the first two rendered frames, that's only a small fraction of a second and only at the very beginning. After that it's eliminated. Now obviously, rendering speed and bandwidth change the equation and is probably why there is a limit to the latency it can correct for. But this does appear to be a cure for interframe latency. It's lazy tree culling of every render state at every point in time for every conceivable user input state at that time. It's certainly a big tree, but it seems they are making the statement that it's small enough to fit in modern bandwidth capacities. Of course, you wouldn't be able to use this in your fighting game example to counteract the relative slow speed of the LCD, but that is because there would be no way to cull the set of images at the LCD itself.

snarfy 12y ago
It's very similar to branch prediction in modern cpu architectures. Branches are expensive, so both sides are executed. It is a good idea, and I'm wrong for my remark equating any of this to webforms. I believe we have a lot we could do to make latency lower, and effort should be focused there. Branch prediction would not be necessary if branching were cheap. This latency prediction system would not be necessary either if latency was low, but it's not. Our hardware sucks. All of the layers of software suck. OculusVR is a testament to how much room for improvement there is in regards to latency.