Statistics: Posted by OffSync — November 16th, 2017, 9:39 pm
Basro wrote:
Yes, it is pretty hard. It's the most complex of the remaining missing flash features. I hope I'll have it implemented sometime in december.
Basro wrote:
The physics are the same, I guarantee this since the code hasn't changed.
Basro wrote:
HaxBall internal logic has always run at 60hz, it still does in the html5 version.
Basro wrote:
No, there's no interpolation in the netcode now or then. Which is why you see objects immediately teleport to a different location when there's lag. Interpolation would smooth that out but I find it hurts more than it helps since it delays the information you are actually interested in (the real position of the ball).
Basro wrote:
Yes, html5's WebRTC has considerable advantages over what is available in flash RTMFP.
In flash network events are handled in sync with the screen updates. Meaning that when a network message arrives it might add 1/60th of a second of additional latency before my code even gets to see it. This happened in both the host and the client so it would add about 33msecs of lag. In html5 my code is notified immediately when a new message has arrived.
There's some other advantages of webrtc, like supporting multiple data channels with different message reliability. But they aren't as significant as the message latency fix.
HaxBall netcode itself is also improved in ways unrelated to WebRTC or RTMFP, these improvements also reduce latency and make the netplay more stable when there's lag spikes or packet loss.
Statistics: Posted by OffSync — November 16th, 2017, 9:30 pm