3 ms·
Yeah, it's part of the problem, but that would normally only give you ~60 - 100 ms lag (at least if you're on a decent connection, close-ish to the server). But
by FredrikNoren 3y ago
Yeah, it's part of the problem, but that would normally only give you ~60 - 100 ms lag (at least if you're on a decent connection, close-ish to the server). But we're experiencing another bug where WebTransport doesn't get a chance to send/receive data when the framerate is < 60fps (because the thread is starved), which makes it much worse than that. We're aware of it and working on it. This is the core issue: https://github.com/w3c/webtransport/issues/543 https://github.com/w3c/webtransport/issues/543
- xeonmc 3y ago> but that would normally only give you ~60 - 100 ms lag 60 ms is already borderline even for conscious discernment of transactional state changes. For self locomotion feedback that is a huge value. And for proprioceptive signals like mouse input it is absolutely astronomical.
- FredrikNoren 3y agoOh yeah, absolutely agree, we're not stopping at 60 ms. Client side prediction is planned (see Philpax answer https://news.ycombinator.com/item?id=37767359 https://news.ycombinator.com/item?id=37767359 and our netcode roadmap: https://github.com/AmbientRun/Ambient/issues/671 https://github.com/AmbientRun/Ambient/issues/671).
- xeonmc 3y agoThis is IMO a pretty good reference example for making a framework-based solution that can be reused by non-coders: https://www.youtube.com/watch?v=5jP0z7Atww4 https://www.youtube.com/watch?v=5jP0z7Atww4