Closed dtugend closed 9 years ago
This isn't a bug, it's delayed a tick to be interpolated so that local movement isn't choppy.
Thank you for your reply.
But aren't the entities already predicted by the engine and isn't the smoothing already being done before on the entity in the client.dll? To be more exact in CBasePlayer::CalcPlayerView through C_BasePlayer::GetPredictionErrorSmoothingVector?
Local prediction just means it shows local movement before the server confirms it. It can't predict what happens on the next tick because the player can press a button mid-tick, so it needs to buffer by a tick to know what it needs to interpolate to.
GetPredictionErrorSmoothingVector is used when the client predicts incorrectly and the server does something different. It's not for the linear interpolation of the local player that happens between ticks.
Thank you, that makes sense, though as player I'd want it to react immediately and not additionally interpolate the view :|
Also I honestly wonder why this additional smoothing isn't done in the client.dll, since the keypresses etc. go through there too, afaik.
So I guess there is nothing I can do about the additional view smoothing by the engine, apart from "correcting" the view matrix before it gets send i.e. to the the shaders?
Edit: If there was a hidden development cvar, that wouldn't be a problem. But I already looked around and tried a few cmds/cvars, including hidden ones, and they didn't help :|
Also this additional smoothing should be bad for things like VR headsets, because it will be observed as additional delay I guess.
There's no way to remove it without introducing choppiness aside from turning up tickrate.
Did you forget a "no" before way, or an "a"?
If you mean "no way to remove it without introducing choppiness", is there a way with potentially introducing choppiness, because I do the camera interpolation anyway, meaning it will be smooth already?
Since your answer is most likely "still no way", I'll close this isse :-(
Thank you for your replies.
Try cl_interpolate 0
I tried that cvar earlier and tried it again, it doesn't turn off the additional view smoothing :-(
I am very sorry, since I have to report that this problem was caused by an issue on my end, I requested WorldToScreenMatrix() too early from VEngineClient, so that it would be off by one frame.
Thank you for all contributions to this issue.
In short this issue can be ignored.
EDIT: This problem was caused by an issue on my end, I requested WorldToScreenMatrix() too early from VEngineClient, so that it would be off by one frame
Hello.
This problem affects probably many different games, tested it for CS:S and CS:GO.
I am using the tool framework for setting camera position and angles, which is obeyed in the client's view.cpp through ToolFramework_SetupEngineView.
Now there is a problem:
Somehow unwanted view smoothing is going on, which you can see in this video: Video link
Basically the purple rectangle is part of the front of a wireframe camera and represents the camera parameters given through ToolFramework_SetupEngineView. If the actual view to DirectX wouldn't be smoothed, the purple rectangle should stay steady in the middle of the screen and not move. But it moves around, unless the demo / game is paused, meaning the engine smoothes out the actual view used, meaning it does not match the given parameters accurately anymore.
Now my questions: 1) Is this a bug or a feature? 2) I had a quick look around the SDK and couldn't find any smoothing of the view in the client.dll explaining this behaviour. So my seconds question is: Can the smoothing be turned off through code / cvars and if so how?
Any help would be greatly appreciated. The position being accurate is important for 3D composition with game footage.