View Issue Details

IDProjectCategoryView StatusLast Update
0004665The Dark ModCodingpublic20.12.2018 05:32
ReporterSpooks Assigned To 
PrioritynormalSeveritymajorReproducibilityalways
Status feedbackResolutionreopened 
PlatformOSWindowsOS Version7
Product VersionTDM 2.06 
Target VersionTDM 2.08Fixed in Version 
Summary0004665: Mouse Sensitivity Tied to Framerate
DescriptionMouse 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 ReproduceCrank 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.
TagsNo tags attached.

Relationships

related to 0004772 closednbohr1more Bow draw speed: slower than 2.05 
related to 0004663 resolvedstgatilov Mouse Sensitivity Inconsistencies Between 2.05 and 2.06 
related to 0004768 resolvedstgatilov Support high-DPI mouse 

Activities

VanishedOne

VanishedOne

13.11.2017 00:54

developer   ~0009589

So that's what's making the 2.06 console sluggish.
duzenko

duzenko

13.11.2017 10:48

developer   ~0009596

What is fps number we're talking about here?
By moving mouse you mean player's looking around?
Spooks

Spooks

13.11.2017 20:52

reporter   ~0009607

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

stgatilov

07.12.2017 01:01

developer   ~0009742

Last edited: 07.12.2017 01:03

View 2 revisions

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.

stgatilov

stgatilov

07.12.2017 01:26

developer   ~0009743

Last edited: 07.12.2017 01:27

View 2 revisions

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 =)

cabalistic

cabalistic

10.12.2017 10:05

developer   ~0009754

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

stgatilov

10.12.2017 11:16

developer   ~0009755

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

cabalistic

10.12.2017 11:22

developer   ~0009756

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

duzenko

10.12.2017 11:36

developer   ~0009757

Last edited: 10.12.2017 11:36

View 2 revisions

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

Spooks

Spooks

10.12.2017 18:43

reporter   ~0009758

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

stgatilov

23.12.2017 10:30

developer   ~0009872

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

nbohr1more

29.04.2018 17:10

developer   ~0010412

Last edited: 29.04.2018 21:48

View 3 revisions

Is this a 2.06 blocker?

Edit: Thread confirms that com_asyncInput cvar has no effect here.

nbohr1more

nbohr1more

10.05.2018 13:59

developer   ~0010457

Blue_Pill's movement fixes have addressed much of this.

Moved to 2.07 for further review.
nbohr1more

nbohr1more

05.07.2018 17:42

developer   ~0010646

Superseded by 4768
stgatilov

stgatilov

05.07.2018 18:22

developer   ~0010647

Last edited: 05.07.2018 18:23

View 2 revisions

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.

nbohr1more

nbohr1more

20.12.2018 05:32

developer   ~0010991

There may be a relationship between this and "true fullscreen" mode.
Moving to 2.08.

Issue History

Date Modified Username Field Change
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