This bug report was migrated from our old Bugzilla tracker.

Reported in version: 1.2.13
Reported for operating system, platform: Windows (XP), x86

Comments on the original bug report:

On 2006-06-26 21:10:59 +0000, Gregory Smith wrote:

Mouse control doesn't seem to work with OpenGL in fullscreen, when using the directx driver. This patch appears to fix that:

Index: src/video/windx5/SDL_dx5events.c

--- src/video/windx5/SDL_dx5events.c (revision 2570)
+++ src/video/windx5/SDL_dx5events.c (working copy)
@@ -299,8 +299,7 @@
}

    /* If we are in windowed mode, Windows is taking care of the mouse */

•   if (  (SDL_PublicSurface->flags & SDL_OPENGL) ||
  

•        !(SDL_PublicSurface->flags & SDL_FULLSCREEN) ) {
  

•   if ( !(SDL_PublicSurface->flags & SDL_FULLSCREEN) ) {
            return;
    }
  

On 2007-02-15 03:37:31 +0000, Ryan C. Gordon wrote:

This works here without the patch on Windows XP (tried windowed, fullscreen, directx and windib driver, SDL_OPENGL surface). Perhaps something else changed since this bug was reported that fixed it?

--ryan.

On 2007-02-15 03:48:30 +0000, Ryan C. Gordon wrote:

*** Bug 266 has been marked as a duplicate of this bug. ***

On 2008-07-31 05:35:05 +0000, Tim Angus wrote:

I think perhaps there is a misinterpretation of the description going on here. It seems to me like the original reporter is saying that DirectInput is never used in conjunction with OpenGL and my experiments confirm this.

The reason I'm interested in this is because since moving ioquake3.org to use a universal SDL backend from the original platform specific code, we've been getting widespread complaint about the quality of the mouse input. Without DX SDL resorts to the low quality WM_MOUSEMOVE stuff. I and others have skirted the issue on the mailing list once or twice. I originally thought the problem was due to the way SDL processes events (http://lists.libsdl.org/pipermail/sdl-libsdl.org/2008-March/064567.html), but more recent investigation indicates that this bug is the real problem.

It looks as though any OpenGL based SDL app is unable to use the DirectInput backend. This isn't such a big deal for a point and click adventure or whatever, but for a twitch shooter such as Q3 it's pretty much make or break. The change that prevents the DX backend being used was introduced in r581 (http://www.libsdl.org/cgi/viewvc.cgi?view=rev&revision=581). If I revert these changes it all apparently works much better. I can't seem to find any bug report on the issue it is fixing, has anyone any idea what the problem was more accuracy? I realise it was committed 6 years ago :)...

I'm fully aware that all the development effort is going towards 1.3 right now (and it looks like this changes input handling significantly enough that this bug is not relevant) so I understand if there is resistance to addressing this, particularly as it hasn't been an obviously important issue for anyone in the past 6 years. That said, this bug is really a big-deal(tm) for anyone wanting to use SDL 1.2 for a Windows based FPS game.

If push comes to shove we can always just ship our own SDL.dll with the r581 changes reverted, but it would be nice to get this fixed in svn if another 1.2 release is planned.

Cheers...

On 2008-07-31 06:50:48 +0000, Gregory Smith wrote:

Your interpretation is correct: using the directx backend, and OpenGL, there is no mouse control at all. Aleph One (a Marathon 2 FPS engine) currently works around this by using using windib when OpenGL is enabled, but we lose DirectInput and full range gamma ramps.

Some users with SDL_VIDEODRIVER=directx set in their environment preferences (for whatever reason) have reported this as recently as a few months ago, so I can confirm the problem still exists.

On 2008-08-11 05:09:14 +0000, Tim Angus wrote:

Bit of an update. We've resorted to including a patch against SDL 1.2 with our source tree: http://svn.icculus.org/quake3?view=rev&revision=1443 . This does the following:

• DirectX (and thus DirectInput) driver not functional when using an OpenGL SDL_Surface.
• DirectX (and thus DirectInput) driver not functional in windowed mode.
• Mouse buttons 4-7 unusable with the DirectX driver due to DirectInput 5 not exposing the required functionality. Use DirectInput 7 instead.
• Low quality mouse input data when using the windib driver due to use of WM_MOUSEMOVE events. Use GetCursorPos API call instead.

Hopefully this is some use to people having win32 mouse input troubles.

On 2008-08-12 11:22:33 +0000, Tim Angus wrote:

Duping as I've added new bug which incorporates this problem.

*** This bug has been marked as a duplicate of bug 611 ***