ZDoom

Even then, it's not a ZDoom thing.

Please don't bump threads in closed bugs/suggestions. If you want to refer to this thread, link it. I suggest to move these two posts on a new thread in 'Bugs' forum.

I'm still [url=http://forum.zdoom.org/viewtopic.php?f=4&t=34308&p=648957#p648957]getting a problem in r3881/r1456[/url], but apparently only while loading skyboxes, glows or dynamic lights (but, apparently, only when a dlight is visible from the very start).

Okay, did that.

On second thought about this whole thing, I am even more convinced that the current way prediction is handled is wrong. Right now it's done for each single view that gets rendered. And all gets started at FRenderer::RenderView. So wouldn't it be best just wrap the call to that with P_PredictPlayer and P_UnPredictPlayer?
That way prediction is cleanly moved to the play code and the renderer kept clean of the intricacies of the play simulation.

The only other place where the renderer is called is for savegame pictures and there it hardly matters whether players are predicted or not.

Of course that's one for Randy to decide so for now I'll leave this thread open.

:oops: I didn't think of that either. And yes, that fixed it.

Figures...

The one time I can't check I get the case wrong...

[quote="Graf Zahl"]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.[/quote]
I'm getting "identifier not found", even after including p_local.h.

[quote="edward850"]
Simplified: Player prediction is done by rendering it earlier in the game state. Gzdoom's GL render hasn't accounted for the changes yet.[/quote]


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 [u]before[/u] 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.

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

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.

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

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.

[quote="edward850"]I believe this to be related to [url=http://cia.vc/stats/project/GZDoom/.message/b956f]r1369[/url], due to the changes to R_SetupFrame() for player prediction.[/quote]

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...

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 [url=http://cia.vc/stats/project/GZDoom/.message/b956f]r1369[/url], due to the changes to R_SetupFrame() for player prediction.