View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0004665||The Dark Mod||Coding||public||12.11.2017 21:20||26.05.2020 02:12|
|Product Version||TDM 2.06|
|Target Version||TDM 2.08||Fixed in Version||TDM 2.08|
|Summary||0004665: Mouse Sensitivity Tied to Framerate|
|Description||Mouse sensitivity and possibly movement input -- although that one's hard to gauge -- seems to be tied to the game's framerate in 2.06. The lower the FPS, the more sluggish your inputs are. |
Even opening and closing the console window is slower, which is not the case in 2.05.
Note that the reverse is not true, your inputs do not speed up when your FPS is very high. Related to this, switching com_fixedTic on/off does not to affect this bug in any way. With the multitude of bugfixes related to lifting the FPS lock, however, I doubt it isn't related in some way.
|Steps To Reproduce||Crank up r_softShadowsQuality up, easiest way to lose FPS.|
Move your mouse around.
If you wish to compare to 2.05, placing a lot of AI in a map in Dark Radiant and angering them is another, cross-version way to check this discrepancy.
|Tags||No tags attached.|
|related to||0004772||closed||nbohr1more||Bow draw speed: slower than 2.05|
|related to||0004663||resolved||stgatilov||Mouse Sensitivity Inconsistencies Between 2.05 and 2.06|
|related to||0004768||resolved||stgatilov||Support high-DPI mouse|
|related to||0004924||resolved||stgatilov||Rope physics mad when FPS is low and uncapped|
|So that's what's making the 2.06 console sluggish.|
What is fps number we're talking about here?
By moving mouse you mean player's looking around?
Yes, the player looking around (although, as I said, there's some extraneous oddities I noticed like the console for instance).
The baseline FPS would be 60, above which I don't notice any difference. Even a five to ten dip to 50 though and the problem manifests. If you manage to bring the FPS down to 10-20, the problem becomes very noticeable.
The movement input I talk about is generally, with lower FPS the player character feels much more sluggish to control when sidestepping or walking back, not really when walking forward.
Well, the time for console opening is definitely longer when you have lower FPS (on SVN).
But I do not notice serious input problems on 20 FPS: it is still well playable. And the the fact that console opens in 1 sec instead of 330 ms is not a serious problem.
Ok, when I noclip through the world in Debug version, I manage to reduce FPS to 6. Then I feel some input lag: about 1/3 of second. And console opening is very slow.
On 1 FPS (NHAT debug noclipping) I clearly see that player's input takes effect 2-3 frames later than I do it. And console opening is painfully slow.
Anyway, I do not notice anything like "tied to the game's framerate" as Spooks wrote. I see only two non-critical things which can be improved:
1. Open console quickly regardless of FPS.
2. Remove 2-3 frames input lag which is clearly present.
By the way, I won't be surprised if the input lag is there "by design". Having a 1/30 lag on 60 FPS may give somewhat different feel to the game. Like watching a movie in 24 FPS seems more cooler for someone than in 60 FPS =)
To give some context here: due to the threaded frontend/backend split, game tics are now calculated simultaneously to the backend rendering the current frame. This means that all game tic updates (including input processing, I assume) will only take effect on the next frame. So there probably is indeed an input lag of 1 frame "by design". If you cap the frame rate at 60 fps, that would be about 16.7 ms. At 20 fps, it would be 50 ms. Is that the amount of lag we are talking about?
For very low frame rates, it might even be close to a 2-frame lag, if your input arrives just at the moment that a game tic starts calculating, because then it'll only be seen in the next game tic, which gets active in the frame after that.
I must admit, I didn't really think about this when I implemented the threading support. I'm personally not very sensitive to input lag and also mostly interested in the uncapped framerate. Unless there's another issue overlapping here, this may not have an easy fix. I'll have a look at the input handling and also at the BFG code base; perhaps some things can be moved around to make it more responsive.
Speaking of input latency, I think it is worth looking into. If there is some clear problem which adds a frame, it may be fixed. But if there is nothing suspicious, then I don't think we really need to do anything.
TDM is not an fast-action game, it is a very slow and steady game and input lag should not be a problem.
I think the main reason why this lag is annoying is that mappers often need to noclip through the map, and then it gets bad.
Comparing with BFG, even Doom 3 BFG has this exact same behaviour. And thinking about it again, even though we are one frame behind, technically with disabled multithreading we would still be a frame behind because user commands can only be processed before the next frame.
So if there is such a noticeable change, there might be something else going on.
Off topic to this bug, but do we want to limit rendering when outside of any area? Skip dynamic models, models smaller than X units, postprocessing, etc?
I do noclip often on my side and would find that useful
|I think there IS another issue overlapping here, that being 0004663. With that said I'm not too fussed over player movement input lag, but mouselook lag is a downer that would possibly hamper precise actions such as aiming the bow. Speaking of precise actions, I've not even tested whether lockpicking would be harder on lower frames with this issue, but I assume it would be.|
I have noticed that opening console takes long time on low FPS only with "com_fixedTic 0". With "com_fixedTic 1", console opens almost instantly.
As for the mouse look, it seems that latency has increased from 1 frame to 2 frames. But if you try to aim bow at 5 FPS, you'll suffer anyway.
Is this a 2.06 blocker?
Edit: Thread confirms that com_asyncInput cvar has no effect here.
Blue_Pill's movement fixes have addressed much of this.
Moved to 2.07 for further review.
|Superseded by 4768|
nbohr1more, this cannot be duplicate of 4768.
0004768 covers only mouse in MAIN MENU, it does not affect in-game controls at all.
And this issue is clearly about mouse-look in-game, plus movement and whatever else.
There may be a relationship between this and "true fullscreen" mode.
Moving to 2.08.
I think this is solved via 0004924
The console is just as responsive to opening and closing at low FPS and movement tracks pretty well even with low FPS now.
|Closing until any further concerns are voiced.|
|12.11.2017 21:20||Spooks||New Issue|
|13.11.2017 00:54||VanishedOne||Note Added: 0009589|
|13.11.2017 10:48||duzenko||Note Added: 0009596|
|13.11.2017 20:52||Spooks||Note Added: 0009607|
|06.12.2017 14:31||grayman||Assigned To||=> duzenko|
|06.12.2017 14:31||grayman||Status||new => assigned|
|06.12.2017 14:31||grayman||Target Version||=> TDM 2.06|
|07.12.2017 01:01||stgatilov||Note Added: 0009742|
|07.12.2017 01:03||stgatilov||Note Edited: 0009742||View Revisions|
|07.12.2017 01:26||stgatilov||Note Added: 0009743|
|07.12.2017 01:27||stgatilov||Note Edited: 0009743||View Revisions|
|10.12.2017 10:05||cabalistic||Note Added: 0009754|
|10.12.2017 11:16||stgatilov||Note Added: 0009755|
|10.12.2017 11:22||cabalistic||Note Added: 0009756|
|10.12.2017 11:36||duzenko||Note Added: 0009757|
|10.12.2017 11:36||duzenko||Note Edited: 0009757||View Revisions|
|10.12.2017 18:43||Spooks||Note Added: 0009758|
|23.12.2017 10:30||stgatilov||Note Added: 0009872|
|25.03.2018 16:22||stgatilov||Assigned To||duzenko =>|
|29.04.2018 17:10||nbohr1more||Note Added: 0010412|
|29.04.2018 17:11||nbohr1more||Status||assigned => feedback|
|29.04.2018 21:47||nbohr1more||Note Edited: 0010412||View Revisions|
|29.04.2018 21:48||nbohr1more||Note Edited: 0010412||View Revisions|
|06.05.2018 21:04||nbohr1more||Relationship added||related to 0004772|
|06.05.2018 21:04||nbohr1more||Relationship added||related to 0004663|
|10.05.2018 13:58||nbohr1more||Product Version||SVN => TDM 2.06|
|10.05.2018 13:58||nbohr1more||Target Version||TDM 2.06 => TDM 2.07|
|10.05.2018 13:59||nbohr1more||Note Added: 0010457|
|05.07.2018 17:42||nbohr1more||Relationship added||related to 0004768|
|05.07.2018 17:42||nbohr1more||Note Added: 0010646|
|05.07.2018 17:43||nbohr1more||Assigned To||=> stgatilov|
|05.07.2018 17:43||nbohr1more||Status||feedback => closed|
|05.07.2018 17:43||nbohr1more||Resolution||open => duplicate|
|05.07.2018 17:43||nbohr1more||Fixed in Version||=> TDM 2.07|
|05.07.2018 18:22||stgatilov||Note Added: 0010647|
|05.07.2018 18:23||stgatilov||Note Edited: 0010647||View Revisions|
|05.07.2018 18:25||stgatilov||Status||closed => feedback|
|05.07.2018 18:25||stgatilov||Resolution||duplicate => reopened|
|29.07.2018 15:14||stgatilov||Assigned To||stgatilov =>|
|20.12.2018 05:32||nbohr1more||Note Added: 0010991|
|20.12.2018 05:32||nbohr1more||Fixed in Version||TDM 2.07 =>|
|20.12.2018 05:32||nbohr1more||Target Version||TDM 2.07 => TDM 2.08|
|13.05.2020 04:14||nbohr1more||Relationship added||related to 0004924|
|13.05.2020 04:16||nbohr1more||Note Added: 0012494|
|13.05.2020 04:17||nbohr1more||Assigned To||=> stgatilov|
|13.05.2020 04:17||nbohr1more||Status||feedback => assigned|
|13.05.2020 04:18||nbohr1more||Status||assigned => feedback|
|13.05.2020 04:18||nbohr1more||Resolution||reopened => open|
|26.05.2020 02:10||nbohr1more||Note Added: 0012561|
|26.05.2020 02:11||nbohr1more||Status||feedback => closed|
|26.05.2020 02:11||nbohr1more||Resolution||open => fixed|
|26.05.2020 02:11||nbohr1more||Fixed in Version||=> TDM 2.08|
|26.05.2020 02:12||nbohr1more||Status||closed => resolved|