Test_Project_Cocos/DelayNoMore
1
0
Fork 0
mirror of https://github.com/genxium/DelayNoMore synced 2024-12-26 03:39:00 +00:00
Code Issues Packages Projects Releases Wiki Activity

Minor fix.

Browse Source
This commit is contained in:
genxium 2022-09-25 23:30:34 +08:00
parent 114e6b0501
commit 50273c981b
1 changed files with 1 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
ConcerningEdgeCases.md
View File

@ -6,6 +6,6 @@ Under the current "input delay" algorithm, the lag of a single player would caus
players #2, #3 #4 would receive "outdated(in their subjective feelings) but all-confirmed commands" from then on, thus forced to rollback and chase many frames - the lag due to "large range of frame-chasing" would then further deteriorate the situation - like an avalanche.
In a "no-server & p2p" setup, I couldn't think of a proper way to cope with such edge case. Solely on the frontend we could only mitigate the impact to players #2, #3, #4, e.g. a potential lag due to "large range of frame-chasing" is proactively avoided in `<proj-root>/frontend/assets/scripts/Map.js, function update(dt)` for more information.
In a "no-server & p2p" setup, I couldn't think of a proper way to cope with such edge case. Solely on the frontend we could only mitigate the impact to players #2, #3, #4, e.g. a potential lag due to "large range of frame-chasing" is proactively avoided in `<proj-root>/frontend/assets/scripts/Map.js, function update(dt)`.
However in a "server as authority" setup, the server could force confirming an inputFrame without player#1's upsync, and notify player#1 to apply a "roomDownsyncFrame" as well as drop all its outdated local inputFrames.