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

Updated documentation.

Browse Source
This commit is contained in:
genxium 2023-01-07 22:51:06 +08:00
parent 24e980c17f
commit 5b9b3a0b55
2 changed files with 17 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

21
battle_srv/models/room.go
View File

@ -1019,12 +1019,7 @@ func (pR *Room) sendSafely(roomDownsyncFrame *pb.RoomDownsyncFrame, toSendInputF
func (pR *Room) getOrPrefabInputFrameDownsync(inputFrameId int32) *battle.InputFrameDownsync {
/*
[WARNING] This function MUST BE called while "pR.InputsBufferLock" is locked.
Kindly note that on backend the prefab is much simpler than its frontend counterpart, because frontend will upsync its latest command immediately if there's any change w.r.t. its own prev cmd, thus if no upsync received from a frontend,
- EITHER it's due to local lag and bad network,
- OR there's no change w.r.t. to its prev cmd.
*/
var currInputFrameDownsync *battle.InputFrameDownsync = nil
tmp1 := pR.InputsBuffer.GetByFrameId(inputFrameId) // Would be nil if "pR.InputsBuffer.EdFrameId <= inputFrameId", else if "pR.InputsBuffer.EdFrameId > inputFrameId" is already met, then by now we can just return "tmp1.(*InputFrameDownsync)"
if nil == tmp1 {
@ -1036,6 +1031,22 @@ func (pR *Room) getOrPrefabInputFrameDownsync(inputFrameId int32) *battle.InputF
ConfirmedList: uint64(0),
}
/*
[WARNING] Don't reference "pR.InputsBuffer.GetByFrameId(j-1)" to prefab here!
Otherwise if an ActiveSlowTicker got a forced confirmation sequence like
```
inputFrame#42 {dx: -2} upsynced;
inputFrame#43-50 {dx: +2} ignored by [type#1 forceConfirmation];
inputFrame#51 {dx: +2} upsynced;
inputFrame#52-60 {dx: +2} ignored by [type#1 forceConfirmation];
inputFrame#61 {dx: +2} upsynced;
...there would be more [type#1 forceConfirmation]s for this ActiveSlowTicker if it doesn't catch up the upsync pace...
```
, the backend might've been prefabbing TOO QUICKLY and thus still replicating "inputFrame#42" by now for this ActiveSlowTicker, making its graphics inconsistent upon "[type#1 forceConfirmation] at inputFrame#52-60", i.e. as if always dragged to the left while having been controlled to the right for a few frames -- what's worse, the same graphical inconsistence could even impact later "[type#1 forceConfirmation]s" if this ActiveSlowTicker doesn't catch up with the upsync pace!
*/
for i, _ := range currInputFrameDownsync.InputList {
// [WARNING] The use of "InputsBufferLock" guarantees that by now "inputFrameId >= pR.InputsBuffer.EdFrameId >= pR.LatestPlayerUpsyncedInputFrameId", thus it's safe to use "pR.LastIndividuallyConfirmedInputList" for prediction.
// Don't predict "btnA & btnB"!

2
jsexport/README.md
View File

@ -1,4 +1,4 @@
GopherJs is supposed to be run by `go run`.
GopherJs is NOT supposed to be run by `go run` but `gopherjs <args>` instead.
If on-the-fly compilation is needed, run `gopherjs serve jsexport` and then visit `http://localhost:8080/jsexport.js` -- if 404 not found is responded, run `gopherjs build` to check syntax errors.