Zdoom is rather mouse greedy

[edward850]

I noticed that when zdoom takes control of the mouse cursor when the game starts, it seems to be a little too greedy and makes it impossible for any on-screen programs to use it (steam and xfire being examples). The issue mostly stands that you can move the mouse, but zdoom still responds to the mouse movement (causing you to turn in the background), and clicks don't respond. This means that although the display shows up, you can't use it.

Foot note: Yes, I know I didn't include [Build number], but on trying older builds, I got to the point where any older ones wouldn't actually run for some odd reason.

[randi]

Eh? I haven't noticed any trouble with the mouse grabbing. I don't really know what you're talking about.

[edward850]

Zdoom grabs the mouse fine (the bug itself is not zdoom), but it seems to make it impossible for on-screen applications to use it. Example:
(Cursor doesn't show, but that's because of print screen).
The overlay works, moving the mouse works, but it doesn't seem to respond to mouse clicks (or its movement, for that matter). Zdoom seems to be a little overzealous in grabbing the mouse.

[randi]

How did you get the Steam overlay on there?

[edward850]

Non-steam games still support the overlay, as long as they can show it. You have to launch the game from the steam menu though (add it as a non-steam game).

[randi]

Set in_mouse to 1 to use the Win32 API for reading the mouse instead of DirectInput. This is really more of a feature suggestion to autoselect it when launched from Steam, but I'm not sure how to detect that.

[edward850]

Ah. Well the only logical way would be to set it as an option in the mouse menu. Other programs may do the same, so making it auto detect would be beyond annoying. I'm assuming there is a reason why you don't use 'in_mouse 1' as the default option in the windows build?

[Graf Zahl]

Of course there is. The Win32 mouse API is not particularly good for games. Using the GUI mouse functions is not particularly efficient. For games DirectInput should always be preferred.

[randi]

Also, in_mouse 0 is already an autoselect. 1 is always Win32, and 2 is always DirectInput. So I think it's reasonable to extend the autoselection logic from "Is this NT 4?" to "Is this NT 4, or is the Steam Community UI loaded?" when deciding if Win32 calls should be used to read the mouse.

N.B. I found the log file for the Steam Community UI DLL, and it appears to recognize that ZDoom uses dinput8.dll and claims to hook it, so I don't know why it's failing to intercept the mouse events.

[Xaser]

Being the incredibly lazy individual I am, I somehow feel the need to present my own terrible, probably-will-be-ignored-but-still-necessary solution:

Windowed mode. ;P

[Macil]

I use windowed mode all the time - mainly because for some stupid reason on Ubuntu (or on most linux overall?) the volume keys and multimedia don't do anything if some program has control of the mouse or a menu is open in a program.

[Zippy]

If you're curious enough you can try emailing the Steam engineers about it to see what they say. I've gotten personal responses from them before so they may have some idea about the hows and whys.

[edward850]

And you be rather pleasantly surprised that they are rather helpful (regardless of how swamped with e-mails they tend to get).

[randi]

Turns out this wasn't that hard to fix so that it works without selecting Win32 mouse. I just needed to change the way I obtain the DirectInput interface to one that GameOverlayRenderer.dll hooks.