Compare commits
2 Commits
v1.0.13
...
v1.0.13-dd
Author | SHA1 | Date | |
---|---|---|---|
|
59d6300880 | ||
|
6713feded1 |
11
README.md
@@ -6,7 +6,7 @@ This project is a demo for a websocket-based rollback netcode inspired by [GGPO]
|
||||
|
||||

|
||||
|
||||
(battle between 2 celluar 4G users using Android phones, [original video here](https://pan.baidu.com/s/1RL-9M-cK8cFS_Q8afMTrJA?pwd=ryzv))
|
||||
(battle between 2 celluar 4G users using Android phones, [original video here](https://pan.baidu.com/s/1m50d-VZxEGT3IgeZtww49g?pwd=eqx1))
|
||||
|
||||

|
||||
|
||||
@@ -96,7 +96,14 @@ The easy way is to try out 2 players with test accounts on a same machine.
|
||||
- Open one browser instance, visit _http://localhost:7456?expectedRoomId=1_, input `add`on the username box and click to request a captcha, this is a test account so a captcha would be returned by the backend and filled automatically (as shown in the figure below), then click and click to proceed to a matching scene.
|
||||
- Open another browser instance, visit _http://localhost:7456?expectedRoomId=1_, input `bdd`on the username box and click to request a captcha, this is another test account so a captcha would be returned by the backend and filled automatically, then click and click to proceed, when matched a `battle`(but no competition rule yet) would start.
|
||||
- Try out the onscreen virtual joysticks to move the cars and see if their movements are in-sync.
|
||||

|
||||
|
||||

|
||||
|
||||

|
||||
|
||||

|
||||
|
||||

|
||||
|
||||
## 2 Troubleshooting
|
||||
|
||||
|
BIN
charts/How-to-play-1.png
Normal file
After Width: | Height: | Size: 24 KiB |
BIN
charts/How-to-play-2.png
Normal file
After Width: | Height: | Size: 24 KiB |
BIN
charts/How-to-play-3.png
Normal file
After Width: | Height: | Size: 92 KiB |
BIN
charts/How-to-play-4.png
Normal file
After Width: | Height: | Size: 64 KiB |
Before Width: | Height: | Size: 4.4 MiB After Width: | Height: | Size: 22 MiB |
Before Width: | Height: | Size: 684 KiB |
@@ -512,7 +512,8 @@ cc.Class({
|
||||
window.clearBoundRoomIdInBothVolatileAndPersistentStorage();
|
||||
window.initPersistentSessionClient(self.initAfterWSConnected, null /* Deliberately NOT passing in any `expectedRoomId`. -- YFLu */ );
|
||||
};
|
||||
resultPanelScriptIns.onCloseDelegate = () => {};
|
||||
resultPanelScriptIns.onCloseDelegate = () => {
|
||||
};
|
||||
|
||||
self.gameRuleNode = cc.instantiate(self.gameRulePrefab);
|
||||
self.gameRuleNode.width = self.canvasNode.width;
|
||||
@@ -1443,6 +1444,10 @@ othersForcedDownsyncRenderFrame=${self._stringifyGopkgRdfForFrameDataLogging(oth
|
||||
if (hasInputFrameUpdatedOnDynamics) {
|
||||
const ii = gopkgs.ConvertToFirstUsedRenderFrameId(j);
|
||||
if (ii < i) {
|
||||
/*
|
||||
[WARNING]
|
||||
If we don't rollback at this spot, when the mutated "delayedInputFrame.inputList" a.k.a. "inputFrame#j" matches the later downsynced version, rollback WOULDN'T be triggered for the incorrectly rendered "renderFrame#(ii+1)", and it would STAY IN HISTORY FOREVER -- as the history becomes incorrect, EVERY LATEST renderFrame since "inputFrame#j" was mutated would be ALWAYS incorrectly rendering too!
|
||||
*/
|
||||
self._handleIncorrectlyRenderedPrediction(j, null, false);
|
||||
}
|
||||
}
|
||||
|