Mouse cursor stuck in middle of screen, old bug

[invictius]

If I move my mouse at all from the moment gzdoom starts running, I'll get the cursor stuck in the middle of the screen and there's nothing you can do about it. I run wads by double clicking them so the slightest movement after my second click means I have to restart to get rid of it. Happens when mouse is set to not work in menus either. It's been an issue for a long time but I only just got around to reporting it.

[Graf Zahl]

I think it's about time to remove the GUI mouse mode for good.

[Major Cooke]

Hold the phone there, D4D makes exclusive use of the mouse mode in D4D alpha 7 I think. Particularly, the akimbo weapon menu where you select your upgrades by mousing over and clicking on the weapon you want for the left or right side.

Albeit, I'm using ZZYZX's ZGUI thingy. So, unsure if that counts.

[Nash]

Whoa whoa whoa whoa that's really backwards progress, Graf. Keep note that OP is known to be a die hard fan of old machines so it could very well be just his computer. Besides, how many reports of mouse-related issues have there been the past years? Like, 3 maybe?

I use mouse in the menus exclusively and cannot imagine going back to keyboard controls.

[ZZYZX]

I don't care about the removal, but if GUI mouse mode is gone, please make it possible to capture the player input mouse... So that custom mouse cursor is also possible in windowed mode (currently only fullscreen).
Other than that the GUI mouse is pretty horrible since it's uncustomizable and is "hacked in" anyway.

[Xaser]

Maybe I'm mistaken, but I'm under the impression that what Graf means is keeping the "Touchscreen-like" mouse mode and ditching the other, more problematic input-capturing one.

[Nash]

That's still what I use... I need the selector to update in real-time as I move the cursor around, as is typical for any graphical user interface on the computer. The lack of visual feedback on the touchscreen mode drives me nuts.

Again, OP hasn't given much details. What machine he's using. Things like that. You can't possibly ditch a feature (and a basic essential feature too, IMO) just because one person made a vague report.

[invictius]

Whoa whoa whoa whoa that's really backwards progress, Graf. Keep note that OP is known to be a die hard fan of old machines so it could very well be just his computer. Besides, how many reports of mouse-related issues have there been the past years? Like, 3 maybe?

I use mouse in the menus exclusively and cannot imagine going back to keyboard controls.

Actually it happens on my i5 and i7, with versions from 1.9 to 3.x.

[Hellser]

Happens to me too on rare occasion, but I'd rather see this issue handled nicely. Not something that other people use to be removed on the basis that it's problematic on some systems / happens to someone rarely.

[ZZYZX]

btw, mouse in the middle is not caused by the capture anyway. It started happening on Zandronum 2.x when they backported raw input and associated mouse code, but they don't have mouse in menus yet.
There are multiple mouse-related bugs — mouse not registering at all, Windows cursor in the middle of the screen, mouse reacting with few second delay... Generally fixes itself by switching in_mouse to 1 and then back to the preferred value (bind something "in_mouse 1; in_mouse 3").

[Graf Zahl]

With GUI mouse I meant how the engine interfaces with the system to get the mouse coordinates. in_mouse == 1 contains code to reset the mouse position to the center and that seems to trigger here somehow.

There's also a second CVAR at play here. What value does 'mouse_capturemode' have when this happens?

[Graf Zahl]

There are multiple mouse-related bugs — mouse not registering at all, Windows cursor in the middle of the screen, mouse reacting with few second delay... Generally fixes itself by switching in_mouse to 1 and then back to the preferred value (bind something "in_mouse 1; in_mouse 3").

Actually, after having a closer look, it seems like in_mouse == 3 may be the problem. The RawInput handler also messes around with the mouse position, like the GUI mouse handler.
Unfortunately I have no idea why this is necessary but if you run into this problem, set in_mouse to 2, i.e. DirectInput. That handler does not center the mouse by force. What I cannot say is if RawInput provides any advantage for mouse handling.

Or if you feel no need to use RawInput at all, set 'norawinput' to true which uses DirectInput for everything.

[Wuerfel_21]

This sometimes happens to me. It can be fixed by opening the menu, but only when the mouse is enabled in the menu (including touchscreen mode)

[Hellser]

With GUI mouse I meant how the engine interfaces with the system to get the mouse coordinates. in_mouse == 1 contains code to reset the mouse position to the center and that seems to trigger here somehow.

There's also a second CVAR at play here. What value does 'mouse_capturemode' have when this happens?

mouse_capturemode is set to 0 when this happens. According to the wiki, this only effects Windowed Mode. I'm playing GZDoom in Fullscreen.
in_mouse is set to 0, setting it to 1 then back to 0 fixes the mouse in the center glitch.

P.S. I can force this glitch (mouse cursor shown on screen) to happen by alt-tabbing like crazy when GZDoom is loading.

[XxMiltenXx]

P.S. I can force this glitch (mouse cursor shown on screen) to happen by alt-tabbing like crazy when GZDoom is loading.

I can confirm that this bug happens a lot, when the game is somehow minimized during startup (e.g. firewall request etc.). Then you'll have the mouse cursor in the center if the screen.