Fixed typo.

README.md

@@ -1,6 +1,8 @@
+Please refer to [DelayNoMoreUnity](https://github.com/genxium/DelayNoMoreUnity) for a Unity rebuild with .net backend.
+
 # Preface 
 
-This project is a demo for a websocket-based rollback netcode inspired by [GGPO](https://github.com/pond3r/ggpo/blob/master/doc/README.md). 
+This project is a demo for a websocket-based rollback netcode inspired by [GGPO](https://github.com/pond3r/ggpo/blob/master/doc/README.md).  
 
 [Demo recorded over INTERNET (Phone-Wifi v.s. PC-Wifi UDP holepunched) using an input delay of 6 frames](https://pan.baidu.com/s/1UArwqDShLoPjYppjjqsTqQ?pwd=10wc), and it feels SMOOTH when playing!
 
@@ -11,8 +13,8 @@ This project is a demo for a websocket-based rollback netcode inspired by [GGPO]
 ![Phone4g_battle_spedup](./charts/Phone4g_battle_spedup.gif)
 
 **Since v1.0.13, smoothness in worst cases (e.g. turn-around on ground, in air and after dashing) is drastically improved due to update of prediction approach. The gifs and corresponding screenrecordings above are not updated because there's no big difference when network is good -- however, `input delay` is now set to `4 frames` -- while `input delay = 6 frames` was used in the screenrecordings -- and smoothness is even better now (well there's [a new screenrecording for PcWifi vs Android4g here](https://pan.baidu.com/s/1iNrQ2l_wqbWkURMIfyG88w?pwd=fe2f)).** Key changes are listed below.
-- [change#1](https://github.com/genxium/DelayNoMore/blob/ea14ced958415dbf4ec1bef89088a3c7607fd8b3/jsexport/battle/battle.go#L647)
-- [change#2](https://github.com/genxium/DelayNoMore/blob/ea14ced958415dbf4ec1bef89088a3c7607fd8b3/frontend/assets/scripts/Map.js#L1446)
+- [change#1](https://github.com/genxium/DelayNoMore/blob/c582071f4f2e3dd7e83d65562c7c99981252c358/jsexport/battle/battle.go#L647)
+- [change#2](https://github.com/genxium/DelayNoMore/blob/c582071f4f2e3dd7e83d65562c7c99981252c358/frontend/assets/scripts/Map.js#L1446)
 
 As lots of feedbacks ask for a discussion on using UDP instead, I tried to summarize my personal opinion about it in [ConcerningEdgeCases](./ConcerningEdgeCases.md) -- **since v0.9.25, the project is actually equipped with UDP capabilities as follows**.
 - When using the so called `native apps` on `Android` and `Windows` (I'm working casually hard to support `iOS` next), the frontends will try to use UDP hole-punching w/ the help of backend as a registry. If UDP hole-punching is working, the rollback is often less than `turn-around frames to recover` and thus not noticeable, being much better than using websocket alone. This video shows how the UDP holepunched p2p performs for [Phone-Wifi v.s. PC-Wifi (viewed by PC side)](https://pan.baidu.com/s/1K6704bJKlrSBTVqGcXhajA?pwd=l7ok).
@@ -21,9 +23,9 @@ As lots of feedbacks ask for a discussion on using UDP instead, I tried to summa
 
 
 # Notable Features
-- Backend dynamics toggle via [Room.BackendDynamicsEnabled](https://github.com/genxium/DelayNoMore/blob/v0.9.14/battle_srv/models/room.go#L786)
+- Backend dynamics toggle via [Room.BackendDynamicsEnabled](https://github.com/genxium/DelayNoMore/blob/c582071f4f2e3dd7e83d65562c7c99981252c358/battle_srv/models/room.go#L147)
 - Recovery upon reconnection (only if backend dynamics is ON)
-- Automatically correction for "slow ticker", especially "active slow ticker" which is well-known to be a headache for input synchronization
+- Automatic correction for "slow ticker", especially "active slow ticker" which is well-known to be a headache for input synchronization
 - Frame data logging toggle for both frontend & backend, useful for debugging out of sync entities when developing new features
 
 _(how input delay roughly works)_
@@ -118,9 +120,9 @@ Just restart your `redis-server` process.
 The most important reason for not showing "PING value" is simple: in most games the "PING value" is collected by a dedicated kernel thread which doesn't interfere the UI thread or the primary networking thread. As this demo primarily runs on browser by far, I don't have this capability easily.
 
 Moreover, in practice I found that to spot sync anomalies, the following tools are much more useful than the "PING VALUE".  
-- Detection of [prediction mismatch on the frontend](https://github.com/genxium/DelayNoMore/blob/v0.9.19/frontend/assets/scripts/Map.js#L842).
-- Detection of [type#1 forceConfirmation on the backend](https://github.com/genxium/DelayNoMore/blob/v0.9.19/battle_srv/models/room.go#L1246).
-- Detection of [type#2 forceConfirmation on the backend](https://github.com/genxium/DelayNoMore/blob/v0.9.19/battle_srv/models/room.go#L1259).
+- Detection of [prediction mismatch on the frontend](https://github.com/genxium/DelayNoMore/blob/c582071f4f2e3dd7e83d65562c7c99981252c358/frontend/assets/scripts/Map.js#L968).
+- Detection of [type#1 forceConfirmation on the backend](https://github.com/genxium/DelayNoMore/blob/c582071f4f2e3dd7e83d65562c7c99981252c358/battle_srv/models/room.go#L1315).
+- Detection of [type#2 forceConfirmation on the backend](https://github.com/genxium/DelayNoMore/blob/c582071f4f2e3dd7e83d65562c7c99981252c358/battle_srv/models/room.go#L1328).
 
 There's also some useful information displayed on the frontend when `true == Map.showNetworkDoctorInfo`.
 ![networkstats](./charts/networkstats.png)

battle_srv/models/room.go

@@ -1213,13 +1213,13 @@ func (pR *Room) markConfirmationIfApplicable(inputFrameUpsyncBatch []*pb.InputFr
 		targetInputFrameDownsync.ConfirmedList |= uint64(1 << uint32(player.JoinIndex-1))
 
 		if false == fromUDP {
-			/*
-							   [WARNING] We have to distinguish whether or not the incoming batch is from UDP here, otherwise "pR.LatestPlayerUpsyncedInputFrameId - pR.LastAllConfirmedInputFrameId" might become unexpectedly large in case of "UDP packet loss + slow ws session"!
+            /**
+              [WARNING] We have to distinguish whether or not the incoming batch is from UDP here, otherwise "pR.LatestPlayerUpsyncedInputFrameId - pR.LastAllConfirmedInputFrameId" might become unexpectedly large in case of "UDP packet loss + slow ws session"!
 
-							   Moreover, only ws session upsyncs should advance "player.LastConsecutiveRecvInputFrameId" & "pR.LatestPlayerUpsyncedInputFrameId".
+              Moreover, only ws session upsyncs should advance "player.LastConsecutiveRecvInputFrameId" & "pR.LatestPlayerUpsyncedInputFrameId".
 
-				               Kindly note that the updates of "player.LastConsecutiveRecvInputFrameId" could be discrete before and after reconnection.
-			*/
+              Kindly note that the updates of "player.LastConsecutiveRecvInputFrameId" could be discrete before and after reconnection.
+             */
 			player.LastConsecutiveRecvInputFrameId = clientInputFrameId
 			if clientInputFrameId > pR.LatestPlayerUpsyncedInputFrameId {
 				pR.LatestPlayerUpsyncedInputFrameId = clientInputFrameId
@@ -1282,7 +1282,7 @@ func (pR *Room) markConfirmationIfApplicable(inputFrameUpsyncBatch []*pb.InputFr
 		snapshotStFrameId := (pR.LastAllConfirmedInputFrameId - newAllConfirmedCount)
 		refRenderFrameIdIfNeeded := pR.CurDynamicsRenderFrameId - 1
 		refSnapshotStFrameId := battle.ConvertToDelayedInputFrameId(refRenderFrameIdIfNeeded)
-		if refSnapshotStFrameId < snapshotStFrameId {
+		if pR.BackendDynamicsEnabled && refSnapshotStFrameId < snapshotStFrameId {
 			snapshotStFrameId = refSnapshotStFrameId
 		}
 		Logger.Debug(fmt.Sprintf("markConfirmationIfApplicable for roomId=%v returning newAllConfirmedCount=%d: InputsBuffer=%v", pR.Id, newAllConfirmedCount, pR.InputsBufferString(false)))
@@ -1336,7 +1336,7 @@ func (pR *Room) forceConfirmationIfApplicable(prevRenderFrameId int32) uint64 {
 func (pR *Room) produceInputsBufferSnapshotWithCurDynamicsRenderFrameAsRef(unconfirmedMask uint64, snapshotStFrameId, snapshotEdFrameId int32) *pb.InputsBufferSnapshot {
 	// [WARNING] This function MUST BE called while "pR.InputsBufferLock" is locked!
 	refRenderFrameIdIfNeeded := pR.CurDynamicsRenderFrameId - 1
-	if 0 > refRenderFrameIdIfNeeded {
+	if pR.BackendDynamicsEnabled && 0 > refRenderFrameIdIfNeeded {
 		return nil
 	}
 	// Duplicate downsynced inputFrameIds will be filtered out by frontend.

frontend/assets/scripts/Map.js

@@ -1003,7 +1003,7 @@ fromUDP=${fromUDP}`);
       const inputFrameId = inputFrame.inputFrameId;
       const peerEncodedInput = (true == fromUDP ? inputFrame.encoded : inputFrame.inputList[peerJoinIndex - 1]);
       if (false == self.allowRollbackOnPeerUpsync && inputFrameId <= renderedInputFrameIdUpper) {
-        // [WARNING] Avoid obfuscating already rendered history, even at "inputFrameId == renderedInputFrameIdUpper", due to the use of "INPUT_SCALE_FRAMES" some previous render frames might already be rendered with "inputFrameId"!   
+        // [WARNING] Avoid obfuscating already rendered history, even at "inputFrameId == renderedInputFrameIdUpper", due to the use of "INPUT_SCALE_FRAMES" some previous render frames might've already been rendered with "inputFrameId"!   
         continue;
       }
       if (inputFrameId <= self.lastAllConfirmedInputFrameId) {
@@ -1022,12 +1022,11 @@ fromUDP=${fromUDP}`);
         self.lastIndividuallyConfirmedInputList[peerJoinIndex - 1] = peerEncodedInput;
       }
       effCnt += 1;
-      // the returned "gopkgs.NewInputFrameDownsync.InputList" is immutable, thus we can only modify the values in "newInputList" and "newConfirmedList"!
+      // the returned "gopkgs.NewInputFrameDownsync.InputList" is immutable, thus we can only modify the value in "newInputList"!
       const existingInputList = existingInputFrame.GetInputList();
       let newInputList = existingInputFrame.GetInputList().slice();
       newInputList[peerJoinIndex - 1] = peerEncodedInput;
-      let newConfirmedList = (existingConfirmedList | peerJoinIndexMask);
-      const newInputFrameDownsyncLocal = gopkgs.NewInputFrameDownsync(inputFrameId, newInputList, newConfirmedList);
+      const newInputFrameDownsyncLocal = gopkgs.NewInputFrameDownsync(inputFrameId, newInputList, existingConfirmedList);
       //console.log(`Updated encoded input of peerJoinIndex=${peerJoinIndex} to ${peerEncodedInput} for inputFrameId=${inputFrameId}/renderedInputFrameIdUpper=${renderedInputFrameIdUpper} from ${JSON.stringify(inputFrame)}; newInputFrameDownsyncLocal=${self.gopkgsInputFrameDownsyncStr(newInputFrameDownsyncLocal)}; existingInputFrame=${self.gopkgsInputFrameDownsyncStr(existingInputFrame)}`);
       self.recentInputCache.SetByFrameId(newInputFrameDownsyncLocal, inputFrameId);
 
@@ -1048,6 +1047,15 @@ fromUDP=${fromUDP}`);
       self.networkDoctor.logPeerInputFrameUpsync(batch[0].inputFrameId, batch[batch.length - 1].inputFrameId);
     }
     if (true == self.allowRollbackOnPeerUpsync) {
+      /*
+      [WARNING] 
+
+      Deliberately NOT setting "existingInputFrame.ConfirmedList = (existingConfirmedList | peerJoinIndexMask)", thus NOT helping the move of "lastAllConfirmedInputFrameId" in "_markConfirmationIfApplicable()". 
+
+      The edge case of concern here is "type#1 forceConfirmation". Assume that there is a battle among [P_u, P_v, P_x, P_y] where [P_x] is being an "ActiveSlowerTicker", then for [P_u, P_v, P_y] there might've been some "inputFrameUpsync"s received from [P_x] by UDP peer-to-peer transmission EARLIER THAN BUT CONFLICTING WITH the "accompaniedInputFrameDownsyncBatch of type#1 forceConfirmation" -- in such case the latter should be respected -- by "conflicting", the backend actually ignores those "inputFrameUpsync"s from [P_x] by "forceConfirmation".
+    
+      However, we should still call "_handleIncorrectlyRenderedPrediction(...)" here to break rollbacks into smaller chunks, because even if not used for "inputFrameDownsync.ConfirmedList", a "UDP inputFrameUpsync" is still more accurate than the locally predicted inputs.
+      */
       self._handleIncorrectlyRenderedPrediction(firstPredictedYetIncorrectInputFrameId, batch, fromUDP);
     }
   },

frontend/build-templates/jsb-link/frameworks/runtime-src/Classes/ring_buff.cpp

@@ -100,7 +100,7 @@ bool RecvRingBuff::pop(RecvWork* out) {
     2. If "0 >= oldCnt", we need guard against another "pop" to avoid over-popping. 
     */
     if (0 >= oldCnt) {
-        // "pop" could be accessed by either "GameThread/pollUdpRecvRingBuff" or "UvRecvThread/put", thus we should be proactively guard against concurrent popping while "1 == cnt"
+        // "pop" could be accessed by either "GameThread/pollUdpRecvRingBuff" or "UvRecvThread/put", thus we should be proactively guarding against concurrent popping while "1 == cnt"
         ++cnt;
         return false;
     }

frontend/settings/project.json

@@ -76,7 +76,7 @@
     "shelter_z_reducer",
     "shelter"
   ],
-  "last-module-event-record-time": 1678432182471,
+  "last-module-event-record-time": 1680159688511,
   "simulator-orientation": false,
   "simulator-resolution": {
     "height": 640,

jsexport/battle/battle.go

@@ -786,7 +786,7 @@ func ApplyInputFrameDownsyncDynamicsOnSingleRenderFrame(inputsBuffer *resolv.Rin
 			// Revive from Dying
 			newVx, newVy = currPlayerDownsync.RevivalVirtualGridX, currPlayerDownsync.RevivalVirtualGridY
 			thatPlayerInNextFrame.CharacterState = ATK_CHARACTER_STATE_GET_UP1
-			thatPlayerInNextFrame.FramesInChState = ATK_CHARACTER_STATE_GET_UP1
+			thatPlayerInNextFrame.FramesInChState = 0
 			thatPlayerInNextFrame.FramesToRecover = chConfig.GetUpFramesToRecover
 			thatPlayerInNextFrame.FramesInvinsible = chConfig.GetUpInvinsibleFrames
 			thatPlayerInNextFrame.Hp = currPlayerDownsync.MaxHp