We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 265 - no mouse control with directx driver, fullscreen OpenGL
Summary: no mouse control with directx driver, fullscreen OpenGL
Status: RESOLVED DUPLICATE of bug 611
Alias: None
Product: SDL
Classification: Unclassified
Component: video (show other bugs)
Version: 1.2.13
Hardware: x86 Windows (XP)
: P2 normal
Assignee: Ryan C. Gordon
QA Contact: Sam Lantinga
URL:
Keywords:
: 266 (view as bug list)
Depends on:
Blocks:
 
Reported: 2006-06-26 21:10 UTC by Gregory Smith
Modified: 2008-08-12 11:22 UTC (History)
1 user (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Gregory Smith 2006-06-26 21:10:59 UTC 
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;
        }
Comment 1 Ryan C. Gordon 2007-02-15 03:37:31 UTC 
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.
Comment 2 Ryan C. Gordon 2007-02-15 03:48:30 UTC 
*** Bug 266 has been marked as a duplicate of this bug. ***
Comment 3 Tim Angus 2008-07-31 05:35:05 UTC 
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...
Comment 4 Gregory Smith 2008-07-31 06:50:48 UTC 
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.
Comment 5 Tim Angus 2008-08-11 05:09:14 UTC 
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.
Comment 6 Tim Angus 2008-08-12 11:22:33 UTC 
Duping as I've added new bug which incorporates this problem.

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