Mouse Temporarily Escapes from GZDoom - Dialogue
Moderator: GZDoom Developers
Forum rules
Contrary to popular belief, we are not all-knowing-all-seeing magical beings!
If you want help you're going to have to provide lots of info. Like what is your hardware, what is your operating system, what version of GZDoom/LZDoom/whatever you're using, what mods you're loading, how you're loading it, what you've already tried for fixing the problem, and anything else that is even remotely relevant to the problem.
We can't magically figure out what it is if you're going to be vague, and if we feel like you're just wasting our time with guessing games we will act like that's what you're really doing and won't help you.
Contrary to popular belief, we are not all-knowing-all-seeing magical beings!
If you want help you're going to have to provide lots of info. Like what is your hardware, what is your operating system, what version of GZDoom/LZDoom/whatever you're using, what mods you're loading, how you're loading it, what you've already tried for fixing the problem, and anything else that is even remotely relevant to the problem.
We can't magically figure out what it is if you're going to be vague, and if we feel like you're just wasting our time with guessing games we will act like that's what you're really doing and won't help you.
Mouse Temporarily Escapes from GZDoom - Dialogue
I think this is more likely a technical issue than a bug. Indeed, it may not be either because I know that the dialogue system is actually a menu and so this behaviour may be expected.
I run a two monitor system (nothing unusual in that, but it lets me see the problem). Typically, if I am exploring files, I will have the relevant window open on my secondary monitor, and this includes if I have an Explorer Window open on my GZDoom directory. If I double click GZDoom, it will open on my primary monitor (all as intended).
However, what I have noticed is that if I open a Strife-like chat dialogue in game, the mouse click can get sent to explorer too. Typical example:
I drag and drop a mod with dialogues on to gzdoom.exe (which starts immediately in Doom2 because I don't have query IWAD set to true). So now what appears on my monitors is GZDoom on the main monitor and half of my desktop with a file explorer window open on the other. Everything proceeds as I would expect until I find a actor that can allow me to open a dialogue. I have secondary-click (right-click) bound to [USE] in game. When I press the [USE] button to open the dialogue (which happens correctly), a right-click event also gets sent to the Operating system.
So, as well as the dialogue opening in game, a context-sensitive menu opens wherever the mouse pointer was - this could be a file properties menu for whichever file the mouse was sitting over, the desktop properties menu etc.
Focus immediately reverts to the game, and the dialogue works as intended, but I now have a context-sensitive menu on my system just sitting there waiting for input. Perhaps the same thing happens on single monitor systems too, but can't be seen because GZDoom is in the way?
Is there any way to stop this happening?
Windows 10 64 bit - fully updated. Logitech G300 gamin mouse (drivers up to date) nVidia GeForce GTX 1080 Drivers also up to date. GZDoom running in full screen at 1920x1200.
I run a two monitor system (nothing unusual in that, but it lets me see the problem). Typically, if I am exploring files, I will have the relevant window open on my secondary monitor, and this includes if I have an Explorer Window open on my GZDoom directory. If I double click GZDoom, it will open on my primary monitor (all as intended).
However, what I have noticed is that if I open a Strife-like chat dialogue in game, the mouse click can get sent to explorer too. Typical example:
I drag and drop a mod with dialogues on to gzdoom.exe (which starts immediately in Doom2 because I don't have query IWAD set to true). So now what appears on my monitors is GZDoom on the main monitor and half of my desktop with a file explorer window open on the other. Everything proceeds as I would expect until I find a actor that can allow me to open a dialogue. I have secondary-click (right-click) bound to [USE] in game. When I press the [USE] button to open the dialogue (which happens correctly), a right-click event also gets sent to the Operating system.
So, as well as the dialogue opening in game, a context-sensitive menu opens wherever the mouse pointer was - this could be a file properties menu for whichever file the mouse was sitting over, the desktop properties menu etc.
Focus immediately reverts to the game, and the dialogue works as intended, but I now have a context-sensitive menu on my system just sitting there waiting for input. Perhaps the same thing happens on single monitor systems too, but can't be seen because GZDoom is in the way?
Is there any way to stop this happening?
Windows 10 64 bit - fully updated. Logitech G300 gamin mouse (drivers up to date) nVidia GeForce GTX 1080 Drivers also up to date. GZDoom running in full screen at 1920x1200.
- drfrag
- Vintage GZDoom Developer
- Posts: 3141
- Joined: Fri Apr 23, 2004 3:51 am
- Location: Spain
- Contact:
Re: Mouse Temporarily Escapes from GZDoom - Dialogue
What happens when you right click while in the regular menus? Could you post a link to the mod?
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49056
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: Mouse Temporarily Escapes from GZDoom - Dialogue
This sounds more like a bug in Explorer that it doesn't properly release the mouse capture when dragging & dropping in cases where its window focus is taken away by force.
Re: Mouse Temporarily Escapes from GZDoom - Dialogue
Same deal actually - with vanilla (no mods). I never noticed it because I don't right click (or click at all for that matter) in the menus.drfrag wrote:What happens when you right click while in the regular menus? Could you post a link to the mod?
In fact, what I now notice (or rather, I noticed some time ago, but now realise it might be relevant) is that pressing Esc to call up the menu frees the mouse and the pointer appears as the default arrow wherever it was before I started GZDoom. Then, with the menu still active, if I move my mouse across from wherever it was (e.g. on the second monitor), as it moves from the explorer window/desktop/whatever to the GZDoom monitor, the cursor changes to the bunny-head and when I move the mouse back off GZDoom it reverts to the default arrow.
Re: Mouse Temporarily Escapes from GZDoom - Dialogue
When GZDoom hides the cursor it saves its current location. Then it keeps recentering on the GZDoom window (while being hidden) so that any mouse clicking ends up being sent to the GZD window. When you press escape it moves the cursor back to where it was when it got hidden and is then shown. This ensures the cursor is always where the user left it. So in that sense this is doing exactly what it is meant to be doing.Enjay wrote:In fact, what I now notice (or rather, I noticed some time ago, but now realise it might be relevant) is that pressing Esc to call up the menu frees the mouse and the pointer appears as the default arrow wherever it was before I started GZDoom. Then, with the menu still active, if I move my mouse across from wherever it was (e.g. on the second monitor), as it moves from the explorer window/desktop/whatever to the GZDoom monitor, the cursor changes to the bunny-head and when I move the mouse back off GZDoom it reverts to the default arrow.
If the strife dialog shows the cursor then that probably explains the buggy behavior. As you left the cursor initially outside the window, the position is saved, the cursor is hidden and centered on GZD. When you right click the mouse down event gets sent to GZD, it restores the cursor position and shows it. When you then release the mouse button the mouse up event gets sent to what is now below the cursor, which happens to be Explorer. It probably shows the context menu on a mouse release event.
There's two possible ways to fix this. One is to constrain the cursor position to be within the GZD window when it gets shown again. The other is to capture the mouse on press, because then it will send the release to GZD regardless of where the mouse cursor is released.
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49056
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: Mouse Temporarily Escapes from GZDoom - Dialogue
The third option would be to switch mouse input to DirectInput which does not do this mouse centering stuff. I found this to be the least problematic input option by far. RawInput may be more modern but this centering bullshit really hurts.
Re: Mouse Temporarily Escapes from GZDoom - Dialogue
Yes, there's always the option of not fixing a bug.
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49056
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: Mouse Temporarily Escapes from GZDoom - Dialogue
I consider that entire mouse centering thing broken by design, so yeah, what do you suggest?
Re: Mouse Temporarily Escapes from GZDoom - Dialogue
Broken by design or not, solving things by using DirectInput is a dangerous thing to do. Like DirectDraw, the thing is in a legacy maintenance mode where it just barely works. I actually had to write a replacement dinput.dll for UT99 just to make it work properly on my system.
In any case, it doesn't seem to be rawinput's fault. At least I'm unable to reproduce what Enjay is experiencing with a simple raw input test program (see attachment).
In any case, it doesn't seem to be rawinput's fault. At least I'm unable to reproduce what Enjay is experiencing with a simple raw input test program (see attachment).
- Attachments
-
- MouseTest.zip
- (49.24 KiB) Downloaded 27 times
Re: Mouse Temporarily Escapes from GZDoom - Dialogue
I did a little more research on raw input. It turns out that the way we've been using it is not the correct way.
Raw Input can function exactly like DirectInput did, but it requires creating a separate hidden window with exactly the RIDEV_CAPTUREMOUSE | RIDEV_INPUTSINK | RIDEV_NOLEGACY flags. This captures the mouse in exclusive mode where no recentering is required. The main catch is that all mouse presses are generated as RAWINPUT events.
Edit: GZDoom already sets the RIDEV_CAPTUREMOUSE | RIDEV_NOLEGACY flags, so it doesn't have to do the centering at all.
I managed to reproduce the error Enjay is experiencing now. The problem is caused by the RIDEV_NOLEGACY flag. Whenever it is active the normal WM messages (WM_LBUTTONDOWN, etc.) aren't being processed, even inside Windows itself. The internal input state gets out of sync. For example, it sees the WM_RBUTTONUP message but never saw the WM_RBUTTONDOWN. Unfortunately the capture mouse flag doesn't work without the nolegacy flag.
My guess is that DirectInput is breaking in the same way, because it is implemented with RAWINPUT by creating a window on a worker thread with the same exact flags. Unfortunately the capturemouse flag doesn't work without nolegacy. Honestly this seems like a bug in the system that's probably been there for 20 years now soon.
Raw Input can function exactly like DirectInput did, but it requires creating a separate hidden window with exactly the RIDEV_CAPTUREMOUSE | RIDEV_INPUTSINK | RIDEV_NOLEGACY flags. This captures the mouse in exclusive mode where no recentering is required. The main catch is that all mouse presses are generated as RAWINPUT events.
Edit: GZDoom already sets the RIDEV_CAPTUREMOUSE | RIDEV_NOLEGACY flags, so it doesn't have to do the centering at all.
I managed to reproduce the error Enjay is experiencing now. The problem is caused by the RIDEV_NOLEGACY flag. Whenever it is active the normal WM messages (WM_LBUTTONDOWN, etc.) aren't being processed, even inside Windows itself. The internal input state gets out of sync. For example, it sees the WM_RBUTTONUP message but never saw the WM_RBUTTONDOWN. Unfortunately the capture mouse flag doesn't work without the nolegacy flag.
My guess is that DirectInput is breaking in the same way, because it is implemented with RAWINPUT by creating a window on a worker thread with the same exact flags. Unfortunately the capturemouse flag doesn't work without nolegacy. Honestly this seems like a bug in the system that's probably been there for 20 years now soon.
Re: Mouse Temporarily Escapes from GZDoom - Dialogue
I pushed a workaround fix for this thing. Also removed the need for centering the mouse when using raw input.
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49056
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: Mouse Temporarily Escapes from GZDoom - Dialogue
I can't say this comes as a surprise.dpJudas wrote:I did a little more research on raw input. It turns out that the way we've been using it is not the correct way.
Regarding DirectInput, I've been using it for the simple reason that it works better than RawInput with the old code, deprecated or not. And the only reason I've been keeping it operational is that the RawInput version seemed broken to me. If you really got that fixed, I'll ditch the legacy input code - keyboard and mouse - immediately and keep DInput only for controllers.