 |
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. |
 |
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. |
 |
Svn rev 7357 Cvar is toggled in game script. |
|
|
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. |
 |
So is there no hope to have a "proper fix" in time for 2.06? |
|
|
Ok, here is the commit which caused this issue: Revision: 6900 Author: duzenko Date: 17 may 2017 18:47:59 Message: 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? |
|
|
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. |
|
|
It seems that high-DPI mouse is a real problem: https://stackoverflow.com/questions/7182199/how-i-can-get-the-pointer-resolution-or-mouse-dpi-on-windows 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. |
|
|
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. |
|
|
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: https://stackoverflow.com/questions/36862013/raw-input-and-cursor-acceleration 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? |
|
|
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? |
|
|
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. |
|
|
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... |
|
|
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. |
|
|
Since this discussion is still ongoing, I'm not inclined to include rev 7357 in 2.06 until the full issue is resolved. |
|
|
Are we going to leave Builder's Blocks in the broken state then? |
|
|
How about doing what stgatilov suggested: rolling back the relevant changes in UserInterface.cpp, rev 6900? |
|
|
That would return to the original problem - unusable hi-dpi mouse |
|
|
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. |
|
|
Broken - how? |
|
|
"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. |
|
|
7357 fixes Builder's Blocks "potentially unwieldy" - don't understand |
|
|
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. |
|
|
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? |
|
|
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. |
|
|
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. |
|
|
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 =( |
 |
"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. |
|
|
I have extracted high-DPI mouse into a related issue. Thus, I resolve this one. |
- Anonymous
