Mouse sensitivity on title/pause screen changes with resolution

[HardDiskDog]

I'm playing on Windows 11, and the sensitivity for moving the cursor in the title/pause menu gets too high and oversensitive at low resolutions (ie. 480), and too low and sluggish at higher ones (1440p, 4K). Mouse movement seems to be unaffected and fine in the game itself.

Also, using DSR to play at 4K and downsample to my 1440p monitor causes all the icons in the rightmost column of my desktop to get moved left one column. If I put them back, running dhewm3 displaces them again with every launch.

[inf78]

I'm on Linux with Gnome, so no icons problem, but the disproportion of sensitivity in menu and the game is probably the same here. I use 1440p and the menu has much lower sensitivity than the game, nothing major though. But definitely different behaviour compared to vanilla Doom3.exe (in Wine at least).

[DanielGibson]

Also, using DSR to play at 4K and downsample to my 1440p monitor causes all the icons in the rightmost column of my desktop to get moved left one column. If I put them back, running dhewm3 displaces them again with every launch.

dhewm3 does not move anything on your desktop, this must be a bug in Windows or your graphics driver or something, probably related to dhewm3 changing the display resolution (if you're using fullscreen)

Not sure what's happening with the cursor speed, it's supposed to be the same as the desktop one, but it's possible that something goes wrong due to HiDPI, where mouse coordinates, window sizes and actual pixels on the screen don't always use the same coordinate system (though I thought that on Windows it does use the same coordinate system, as dhewm3 tells Windows that it handled DPI scaling itself and that it should get a window of exactly the size in pixels that have been requested, so mouse coordinates, window size and opengl framebuffer should all use the same resolution).

[DanielGibson]

Ah right, regarding cursor speed with DSR: I think that's just the normal cursor speed you'd also see on the Windows desktop when running that at DSR resolution (is that possible?).

Your system mouse cursor speed is probably configured to something like "1cm of mouse movement moves cursor by 20 pixels" - or whatever speed feels good for the mousecursor at 1440p.
But when using DSR, the resolution is twice has high in both width and height (5120x2880 on a 1440p screen), so moving it 20 pixels looks like 10 pixels on the screen => the perceived cursor speed is only half as fast.
For ingame mouse movement this isn't relevant, because there it's more like "a mouse event with 20 pixels movement will turn the camera by 5°" (5° is just an example value, no idea what's the right ballpark and it depends on the configured mouse sensitivity anyway) - no matter if 20 pixels are 5mm on your screen or 10mm or whatever.

---

On Linux (and probably also macOS and other systems) with HiDPI the problem is different, as I wrote it must have something to do with DPI scaling turning drawn pixels, window size and mouse coordinates into different units.
(On Windows this shouldn't happen, because dhewm3 explicitly tells Windows that it wants everything in real pixels - of course the definition of "real pixel" gets kinda blurry with DSR, but that's because DSR is just a hack by the GPU driver.)

Usually, when running dhewm3 in windowed mode and (while in the main menu) moving the cursor inside and out of the window, the Doom3 menu cursor and system cursor should switch seamlessly, i.e. if you move the mouse out of the window the system cursor will appear at the closest position outside the window, and vice versa - at least for the upper and lower window edges, left/right you'll usually have those black bars from scaling the menu to 4:3, where no cursor is rendered (or it's clamped into the non-black area).
Similarly, this will allow you to compare the cursor speed inside and outside the dhewm3 window, which should be the same.
However, this only works if the render size and window size in mouse coordinates are the same - maybe I can fix this in the future, not sure.

Original Doom3 behaved differently: Doom3 (and dhewm3) menu UIs always use coordinates based on a 640x480 UI size, so the internal mouse coordinates in menus are always between (0,0) and (639,479).
Original Doom3 just grabbed the mouse cursor (so it couldn't leave the window) and used the relative mouse coordinates it got from mouse events to move the cursor inside the UI.
So if it got a mouse event (from the system) that said "the mouse moved 100 pixels to the right and 15 pixels down", it moved the cursor 100 pixels to the right and 15 pixels down. Of course, the coordinates from the system are based on the window size, so the higher the resolution, the faster the Doom3 mouse cursor got (at 2560x1440, moving the cursor 100 pixels to the right is just about 4% of the window width, but at 640x480 it's 16% of the window width => 4x as fast as one would expect!).
I fixed this in dhewm3 by scaling the values from mouse events by 640/window_width and 480/window_height before moving the Doom3 menu mouse cursor with them (see idUserInterfaceLocal::HandleEvent(), so the cursor in the menu should behave pretty much like the one on the desktop. At least as long as mouse coordinates and window size in pixels agree, see above.

UPDATE: Oh, and another thing: The perceived mousespeed in the menu and in the game (esp in the PDA) differs, because the PDA is a real ugly hack. Technically it isn't implemented as a regular fullscreen menu that gets input events through the mechanism I fixed the mouse speed in, but it's a weapon with a UI that happens to be rendered over the whole screen, and all that is done in the gamecode (while the normal UI code is in the engine).
The gamecode doesn't even get the real input events, it gets information like "player is pressing the shoot button", "the players view angles are now X,Y,Z" and some weird "continous mouse coordinate" that just adds the mouse x/y movement each frame.
From that incomplete information, the gamecode then generates fake events, like "player fired => generate left mouse click if PDA is open" and sends those fake events to the PDA UI (see idPlayer::RouteGuiMouse() and idPlayer::Weapon_GUI()).. it's really ugly, and the reason why the PDA behaves differently from the main menu, even though both look like reasonable fullscreen UIs.

[inf78]

Hm, seems rather complicated ;) I don't think that it's such a problem though. But would it be possible then to make the mouse wheel to actually really scroll the PDA logs? Clicking on the small bullet to move the text is a bit annoying. But nothing major of course. :D

[DanielGibson]

Funny thing: It might be more feasible to make the mouse in the PDA not too fast (I looked at it again and have an idea..) than making the mouse wheel scroll - because the information what key (or button or wheel or whatever) triggered an action is not available to the PDA :-/

I think best I could (maybe!) do is make next/previous weapon scroll, whatever it's bound to.. but then there are people who use scroll up for next weapon and others (like me) use scroll down for next weapon, so for half the people (that have the mouse wheel bound to next/prev weapon at all) scrolling with the mouse wheel would scroll in the wrong direction..

(and yes, it annoys me as well that I can't scroll with the mousewheel in the PDA, the only place in the whole frigging game where scrolling is really desirable - the main menu barely uses any scrolling (maybe the mods menu if you have shittons of mods installed, or the server list in the multiplayer menu, if there were more than 3 dhewm3 servers online..)

[inf78]

Hehe! Alright, no problem. I also use scroll down for next weapon, I guess most people do, but who knows.

Well, that lack of a need to use the scroll wheel in menu is actually something I sort of appreciate these days. When I was those 26-27, I could spend a lot of time going through a crapload of Quake mods, but for Doom3, really only few are good enough in terms of design, flow and general polish. So no problem ;)

[DanielGibson]

Hmm though I guess I could add a CVar that configures if next or prev weapon scrolls down..
I hope I'll get around to figure this out some time, but right now I'm working on something else :)

[DanielGibson]

I implemented HighDPI support in #576, @inf78 can you test if this makes the cursor speed in the menu feel more normal in gnome?
If you're using Wayland, you may have to set the SDL_VIDEODRIVER=wayland env var before starting dhewm3, otherwise it goes through XWayland - not sure if DPI scaling works correctly with XWayland on gnome.

[inf78]

Of course.
I just tried it with clean config and it feels the same, that is, the mouse is a bit slow. I'm still using X primarily, but I tested on Wayland as well with same result.
I don't have any specific scaling options in Gnome enabled, so scaling is just 1, if it's in any way related.

But very cool menu! For a while I thought Force Engine was silently executed. :D