[after r3601] Multiplayer Desync

[Ed the Bat]

I'm not entirely sure when this began, but I know this wasn't present in r3601, and it is present in r3607 (which is the next SVN available from DRD Team). When running a multiplayer game, the players will invariably and almost immediately go out of sync with one another. I've tried this with numerous setups, several different computers and network connections, both LAN and internet. Rolling back to r3601 or older fixed the issue immediately. I can only guess that something added between r3602 and r3607 (inclusive) is causing a problem.

I lack any proper debugging tools so I'm afraid I can't sniff out any more specifics...

[Gez]

Okay, I've uploaded ZDoom r3602--3606 to DRD Team.

[edward850]

Possible user error? I'm unable to make it go out of sync in r3607 or r3631.

[Ed the Bat]

Hrm, user error is always a possibility. I'm far from infallible. I was not able to reproduce the error with just ZDoom. I can do it in GZDoom, but in fairness I should point out that one of my machines is forced to run the software renderer, and the sync happened when the other machine was using hardware rendering, so I wouldn't be surprised about desyncing. As for the sync problems I was having during internet play, I don't have all the variables from the other party's end, so I can't really say anything definitively.

Regardless, thanks for those SVNs, Gez! And my apologies for wasting everyone's time. =P

If I find this problem persisting and with a solid enough root cause, I'll report it again.

[Kinsie]

I'm getting reports of people trying Reelism co-op online not being able to pick up or use guns. Is this related?

[Xaser]

There's some sort of broken something-or-other (GZDoom r1362 shows it) in some version of ZDoom somewhere. I experienced that very problem when trying to play a co-op game in Reelism, but we tried it with a different mod later and got the same problem. We since switched to ZDoom r3620 and had it work fine.

[Ed the Bat]

Hm, then maybe I'm not insane after all... I was seeing the sync issues only when the GL renderer was involved somewhere. Having both parties use software mode, things are smooth as silk. And I only saw the sync issues with versions later than r1368(r3601). I hadn't stopped to think it might be due to the renderer... Sadly, since I only have one available machine that supports the GL renderer, and I don't have a reliable second party to test it with internet games, I'm not going to be able to narrow down the problem any further than this... Plus, if it turns out to be due to the GL renderer somehow, that would be something to report on the GZDoom forums, wouldn't it?

[Kinsie]

From another forum:

A friend and I were trying to play Reelism 1.2 earlier, but the latest (May 6th) SVN build wouldn't work for us at all and would immediately crash any attempts at multiplayer. We were able to play, and everything went smoothly, when we rolled back to the April 24th build though. Any ideas on why this is happening?

[edward850]

It does indeed look like a GZdoom issue, although the issue is rather blunt (and most certainly not exclusive to Reelism).
The console player is not "alive" on spawn. They have no active weapon, let alone capable of interacting with anything. It goes out of sync because every player that is not the console player on each session still somehow work.

Edit: More testing: GZdoom r1368 works, GZdoom r1371 is broken. I believe this to be related to r1369, due to the changes to R_SetupFrame() for player prediction.

[Ed the Bat]

I believe this to be related to r1369, due to the changes to R_SetupFrame() for player prediction.

That was exactly my first theory. The fact that the problem only happens with the GL renderer, though, is what's beyond me. Granted, I don't know the first thing about coding a renderer, so...

[edward850]

Zdoom (in multiplayer) predicts player movement by rendering the player/camera in the expected location. Recently, Randy fixed an issue with the chasecam (the camera was predicted, the the player actor wasn't), and that worked fine in Zdoom. This was soon merged into GZdoom, but wasn't tested with it's hardware rendering.
What you are seeing is the predicted view-point not attaching(?) properly to the local player you are supposed to be controlling. I can't say why it's not attaching though.

Simplified: Player prediction is done by rendering it earlier in the game state. Gzdoom's GL render hasn't accounted for the changes yet.

[Ed the Bat]

Sounds reasonable to me, I suppose. I remember watching the predictor bug for the past few years. I was kinda surprised when it got fixed, but I guess the fix wasn't entirely complete...

I'll admit, I may start to miss the old buggy multiplayer chasecam. It made the action more dramatic and cinematic. =P

[edward850]

So it's definitely something to do with the GL portion of GZdoom. Either setting cl_noprediction to true or forcing GZdoom to use software rendering "resolves" the issue. However, I don't seem to be able to understand why the prediction would even break like this.

[Ed the Bat]

True enough! Though I've become so spoiled with the rich color and true 3D geometry of GL rendering that software mode hurts my eyes (and using vertical freelook makes me want to puke!).

Disabling prediction may be a feasible stopgap until the real root of the problem is discovered and ironed out, though. As is, of course, sticking with r1368 for the time being. =P

[Graf Zahl]

Simplified: Player prediction is done by rendering it earlier in the game state. Gzdoom's GL render hasn't accounted for the changes yet.

Grrr... Not again. Gez never seems to check if some change in the code requires adjustment of the GL parts.



I added the missing call to the equivalent point to where it is in the software renderer - but I'm currently on a computer where I can't compile the engine so someone else will have to do any checks.


Still, why is this call buried somewhere deep in the rendering code? Shouldn't it be done by the play engine before calling the renderer and reset after rendering finishes (like, in the 2 places that call the renderer - D_Display and FCanvasTextureInfo::UpdateAll ())

I spent some time last year to untangle the renderer from such stuff but it seems there's still some interactions left that need to be handled. In an ideal state the renderer should never - even temporarily - alter play data - just process it for display.