View Issue Details

IDProjectCategoryView StatusLast Update
0004663The Dark ModGUIpublic06.05.2018 21:04
ReporterSpooks Assigned Tostgatilov  
Status resolvedResolutionfixed 
Product VersionSVN 
Fixed in VersionTDM 2.06 
Summary0004663: Mouse Sensitivity Inconsistencies Between 2.05 and 2.06
DescriptionThe Mouse Sensitivity setting in TDM 2.06 increases both in-game mouse sensitivity and menu sensitivity. This makes the menus potentially very unwieldy. Only in-game sensitivity is affected in 2.05.

IN ADDITION, while testing the FM "The Builder's Blocks" under 2.06 -- an FM that modifies mouse sensitivity -- my mouse sensitivity was set to 0, effectively breaking mouse input. I was only able to fix it by editing the corresponding line in darkmod.cfg (seta sensitivity "[number]"). Again, The Builder's Blocks works fine in 2.05.
TagsNo tags attached.


related to 0004403 resolvedduzenko Mouse input tweak 
related to 0004768 resolvedstgatilov Support high-DPI mouse 
related to 0004665 resolvedstgatilov Mouse Sensitivity Tied to Framerate 




23.12.2017 10:39

administrator   ~0009873

Last edited: 23.12.2017 15:03

I have checked: in 2.05 mouse sentitivity does not affect game menu, while in 2.06 beta it does.

Spooks, could you please provide a simple way to get mouse sensitivity changes in "The Builder's Blocks" ? I did not play the mission, and I imagine that it is done in some special place...

UPDATE: By the way, "Smooth Mouse" also should not apply to main menu. It is mostly to cure viewer thickness from fast camera turns.



23.12.2017 21:16

reporter   ~0009875

Hello, The Builder's Blocks' description says it modifies sensitivity, although I can't know if that's true. The FM is a mini-game that's controlled through an onscreen GUI with "nocursor" set to 0. It's builders_blocks.pk4/guis/gamescreen.gui The way the bug manifests, then, is that the cursor in the custom GUI can't be moved at all and you're softlocked in it. Quitting doesn't fix it, editing the cfg does.

GUIs are not my strong suit, so I can't spot anything strange in there.


24.12.2017 08:23

developer   ~0009877

Svn rev 7357
Cvar is toggled in game script.


24.12.2017 12:59

administrator   ~0009878

Last edited: 25.12.2017 14:50

This is a hack for specific map, not a proper fix.

It does not fix the issue that mouse sensitivity now affects game menu, which it must not.



24.12.2017 16:31

viewer   ~0009879

So is there no hope to have a "proper fix" in time for 2.06?


25.12.2017 09:47

administrator   ~0009880

Ok, here is the commit which caused this issue:

Revision: 6900
Author: duzenko
Date: 17 may 2017 18:47:59
Apply the cvar "sensitivity" to 2d mouse cursor as well
Modified : /trunk/renderer/Image_load.cpp
Modified : /trunk/ui/UserInterface.cpp

We can simply rollback it to fix the problem.
Well, we cannot directly rollback the commit, because Duzenko also committed unrelated changes in it (bad habit BTW), but we can revert the changes in file UserInterface.cpp.

Duzenko, could you please clarify what was the reason for the change?


25.12.2017 09:56

developer   ~0009881

I have a high-dpi (about 3000 AFAiR) mouse at work and it was too fast in GUI. That commit solves it.
For that reason I also changed the sensitivity cvar from integer to float.


25.12.2017 14:49

administrator   ~0009882

It seems that high-DPI mouse is a real problem:
There is no way to detect DPI of a mouse. Allowing to change sensitivity is the only way to adjust to such mouses (mice?).

What are we going to do?
Apply sensitivity to both menu and in-game (as now in 2.06)?
Add second sensitivity?
Try to measure DPI? =)

P.S. I was wrong about smoothness. It does not affect game menu, only sensitivity does.


25.12.2017 15:02

reporter   ~0009883

Second sensitivity option if possible is what I'd go for. Could the game not fetch raw input from the mouse settings in the control panel like other games do? Too much work, I suppose, I'm ignorant if that would even be feasible on Linux.


25.12.2017 15:35

administrator   ~0009884

It seems that SystemParametersInfo with SPI_GETMOUSESPEED returns mouse sensitivity from control panel as an integer ranging from 1 to 20.
According to this question:
the real sensitivity multiplier seems to be (speed/10.0), so it ranges from 0.1 to 2.0. I'm not very sure in it, it's hard to find any official docs.

Theoretically, we can use this as multiplier in TDM game menu, ignoring sensitivity setting. However, the mouse would not work as it works in Windows, because by default Windows has "mouse acceleration" or "enhanced pointer precision" feature enabled. This feature lowers sensitivity for small movements, and increases it for big movements.
We can also create another cvar like "menuSensitivity", with default value set from control panel in Windows, and to 1.0 on other platforms.

Any ideas about whether it is worth it?


25.12.2017 18:24

developer   ~0009885

Last edited: 25.12.2017 18:24

I am still not sure about how GUI mouse sensitivity is a problem. Is it too slow?
Theoretically we could drop direcinput and just poll windows mouse cursor (too late for 2.06?). How is the Linux part of mouse input implemented?



26.12.2017 03:10

administrator   ~0009888

Even if you get rid of DirectInput, you'll have to use raw mouse input (WM_INPUT) for gameplay, and it will work exactly the same way as DirectInput works now.

DirectInput is not a problem at all. The problem could be removed if we use mixed mouse input: WM_MOUSEMOVE for game menus and DirectInput for gameplay.
This needs to be somehow befriended with Doom3's input system, and also some equivalent is needed for Linux.

Quite a lot of work.


26.12.2017 08:10

developer   ~0009889

I was thinking GetCursorPos
The problem here is that mouse data is passed as GenerateMouseMoveEvent params, and that function is called from quite a few places...


26.12.2017 16:19

administrator   ~0009890

GetCursorPos is also not suitable for first-person mouse look, so you can use it only for menu. So two types of mouse input, anyway.


28.12.2017 04:30

viewer   ~0009894

Since this discussion is still ongoing, I'm not inclined to include rev 7357 in 2.06 until the full issue is resolved.


28.12.2017 08:26

developer   ~0009901

Are we going to leave Builder's Blocks in the broken state then?


28.12.2017 14:03

viewer   ~0009902

How about doing what stgatilov suggested: rolling back the relevant changes in UserInterface.cpp, rev 6900?


28.12.2017 14:04

developer   ~0009903

That would return to the original problem - unusable hi-dpi mouse


28.12.2017 14:14

viewer   ~0009904

My vote would be that we don't support the hi-dpi mouse.

Sounds like you should take this to the forums for discussion; see what kind of mice people use, and see if there's a consensus as to how to handle this situation.

Some rules:

We try not to break existing missions.

We also try not to break functionality. In this case, mouse sensitivity in the menus is broken by 6900. If there's no way to unbreak it by going forward, we need to go backward and revert the change that broke it.


28.12.2017 14:16

developer   ~0009905

Broken - how?


28.12.2017 14:19

viewer   ~0009906

"The Mouse Sensitivity setting in TDM 2.06 increases both in-game mouse sensitivity and menu sensitivity. This makes the menus potentially very unwieldy. Only in-game sensitivity is affected in 2.05.

IN ADDITION, while testing the FM "The Builder's Blocks" under 2.06 -- an FM that modifies mouse sensitivity -- my mouse sensitivity was set to 0, effectively breaking mouse input. I was only able to fix it by editing the corresponding line in darkmod.cfg (seta sensitivity "[number]"). Again, The Builder's Blocks works fine in 2.05."

I assume what Spooks is talking about is the result of what stgatilov found: that rev 6900 caused the breakage.


28.12.2017 14:21

developer   ~0009907

7357 fixes Builder's Blocks
"potentially unwieldy" - don't understand


28.12.2017 14:38

viewer   ~0009908

I read this as a two-part problem:

1 - Menus are unwieldy. I assume that means the mouse is undershooting or overshooting the target as the player moves it around in the menus. Perhaps Spooks owes us more detail.

2 - Builder's Blocks is broken.

Perhaps stgatilov can expand on his comments about 6900 causing 1 & 2.

If 7357 fixes 2, where does that leave us with 1?

The above discussion is about detecting mouse sensitivity/speed, and how it might be difficult. It doesn't sound like something we'd be able to fix in what little time there is left for 2.06.

Which tells me that the simple fix for the reported problems is to revert 6900, which stgatilov says caused these problems.

Any issue doing that leaves for hi-dpi mouse support then gets pushed off to 2.07.


28.12.2017 14:46

developer   ~0009909

With 1 it leaves us not understanding what Spooks meant. Do you or @stgatilov have any problem with GUI menu? If not then why break it for me?


28.12.2017 15:17

administrator   ~0009910

Last edited: 28.12.2017 15:19

I have just checked Builder Blocks mission.
It is simply tetris game. When you enter it, the 3D rendering continues working, but additional GUI buttons appear. Moreover, the mouse cursor appears and you can move it. Clicking buttons with your mouse allows you to rotate/move tetris figures.
At the same time, the camera must not change when you move the mouse, which is achieved by setting sensitivity to zero. The old understanding of sensitivity is how fast mouse movement changes first-look camera. If it is changed to zero, then camera stays fixed. The GUI mouse works as usual, because sensitivity does not affect it.

So yes, there are two issues:
1. The problem of unexpectedly high/low effective sensitivity in game menu.
With old behavior, high DPI mouses are too sensitive.
With new behavior, some players who modify game sensitivity have issues with menu (ask Spooks).
2. The broken Builder Blocks mission.
Ironically, commit 7357 _DOES_NOT_FIX_ the mission!
Yes, you can click GUI buttons, but camera also rotates as you do so, which makes tetris rather unplayable.

Yes, I vote for reverting both the old commit 6900 AND the new commit 7357 and then merging the reversion of 6900 to 2.06 branch. Note that commit 7357 also breaks Builder Blocks: if you leave it in place, reverting 6900 won't return the mission to its proper state.



28.12.2017 15:24

viewer   ~0009911

So it sounds like we revert the pertinent part of 6900 plus all of 7357.

We don't want SVN behaving badly, and we don't want the bad behavior in 2.06.

The problem of supporting hi-dpi mice should wait until 2.07, when we can devise good support that doesn't break BB or menus. This solution _might_ be extensive, from what st says above, and we don't have any runway left in 2.06 to do that now.


29.12.2017 12:59

administrator   ~0009915

Reverted in 7358 and 7359.

High-DPI mouse support should be opened as a separate feature request.
Be sure to link this issue there and note explicitly about the problematic Builder Blocks FM =(


29.12.2017 14:37

administrator   ~0009916

"Menus are unwieldy. I assume that means the mouse is undershooting or overshooting the target as the player moves it around in the menus. Perhaps Spooks owes us more detail."

For the record, that is exactly what happened to me.


01.04.2018 17:22

administrator   ~0010345

I have extracted high-DPI mouse into a related issue.
Thus, I resolve this one.

Issue History

Date Modified Username Field Change
12.11.2017 14:22 Spooks New Issue
12.11.2017 17:49 nbohr1more Relationship added related to 0004403
23.12.2017 10:39 stgatilov Note Added: 0009873
23.12.2017 15:03 stgatilov Note Edited: 0009873
23.12.2017 20:49 duzenko Assigned To => duzenko
23.12.2017 20:49 duzenko Status new => assigned
23.12.2017 21:16 Spooks Note Added: 0009875
24.12.2017 08:23 duzenko Note Added: 0009877
24.12.2017 08:23 duzenko Status assigned => resolved
24.12.2017 08:23 duzenko Resolution open => fixed
24.12.2017 12:59 stgatilov Note Added: 0009878
24.12.2017 12:59 stgatilov Status resolved => assigned
24.12.2017 12:59 stgatilov Note Edited: 0009878
24.12.2017 16:31 grayman Note Added: 0009879
25.12.2017 09:47 stgatilov Note Added: 0009880
25.12.2017 09:56 duzenko Note Added: 0009881
25.12.2017 14:49 stgatilov Note Added: 0009882
25.12.2017 14:50 stgatilov Note Edited: 0009878
25.12.2017 15:02 Spooks Note Added: 0009883
25.12.2017 15:35 stgatilov Note Added: 0009884
25.12.2017 18:24 duzenko Note Added: 0009885
25.12.2017 18:24 duzenko Note Edited: 0009885
26.12.2017 03:10 stgatilov Note Added: 0009888
26.12.2017 08:10 duzenko Note Added: 0009889
26.12.2017 16:19 stgatilov Note Added: 0009890
28.12.2017 04:30 grayman Note Added: 0009894
28.12.2017 08:26 duzenko Note Added: 0009901
28.12.2017 14:03 grayman Note Added: 0009902
28.12.2017 14:04 duzenko Note Added: 0009903
28.12.2017 14:14 grayman Note Added: 0009904
28.12.2017 14:16 duzenko Note Added: 0009905
28.12.2017 14:19 grayman Note Added: 0009906
28.12.2017 14:21 duzenko Note Added: 0009907
28.12.2017 14:38 grayman Note Added: 0009908
28.12.2017 14:46 duzenko Note Added: 0009909
28.12.2017 15:17 stgatilov Note Added: 0009910
28.12.2017 15:19 stgatilov Note Edited: 0009910
28.12.2017 15:24 grayman Note Added: 0009911
29.12.2017 12:59 stgatilov Note Added: 0009915
29.12.2017 14:37 Springheel Note Added: 0009916
01.04.2018 15:07 stgatilov Relationship added related to 0004768
01.04.2018 17:22 stgatilov Note Added: 0010345
01.04.2018 17:23 stgatilov Status assigned => resolved
01.04.2018 17:23 stgatilov Fixed in Version => TDM 2.06
01.04.2018 17:23 stgatilov Assigned To duzenko => stgatilov
01.04.2018 17:23 stgatilov Status resolved => assigned
01.04.2018 17:23 stgatilov Status assigned => resolved
06.05.2018 21:04 nbohr1more Relationship added related to 0004665