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.

Created attachment 263 [details]
Patch that fixes poor win32 mouse input

Bah, copying and pasting that didn't work out so well. Anyway, here is the patch.

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

Created attachment 267 [details]
Version 2 of above

This new patch, I believe, addresses the issues that prevented DirectInput being used in windowed/OpenGL mode originally. DI is a relative input system and thus has no notion of absolute positioning and mouse cursors. Since SDL (currently) assumes no control over the mouse cursor, DI won't operate like the other drivers in absolute mode. This update fixes this issue by assuming control of the cursor when it's within the SDL window.

Also fixed is a problem where SDL_APPMOUSESTATE notifications ceased to be updated following a second call to SDL_SetVideoMode, due to the static variable in_window being out of sync.

Created attachment 269 [details]
Version 2.1 of above

Fix a stupid bug relating to focus with the windib driver.

I tried applying this patch and unfortunately, I lose all mouse control in full screen directx mode, including cursor. It used to work with directx as long as OpenGL wasn't enabled, but with this patch, it doesn't work at all fullscreen.

Seems to work in windowed mode directx and windib.

Built with mingw 3.4

Can you provide a test case?

Sure thing; testcursor.exe works normally, but if I modify it to start up full screen:

155c155
< 	screen = SDL_SetVideoMode(320,200,8,SDL_ANYFORMAT);
---
> 	screen = SDL_SetVideoMode(640,480,8,SDL_FULLSCREEN);

The cursor stops moving. Mouse clicks do work.

Created attachment 271 [details]
Version 2.2 of above

OK, there were a couple of things going on there. Firstly, when fullscreen DI was being granted exclusive access to the mouse. This meant that WM_MOUSEMOVE messages didn't get delivered and SDL_APPMOUSEFOCUS never got set. Incidentally, I've changed how this works a bit and it was probably only by "chance" that this worked before. Secondly, as a consequence of exclusive access being granted, the mouse cursor was hidden and the software cursor was being used. As the WM cursor is now forced to track the absolute state of the mouse position, it can be used instead of the software cursor.

In hindsight this is probably the reason that DI was disabled with OpenGL; you can't draw a software cursor on a GL surface.

Anyway, it seems to all work with testcursor.c and my other tests now... fingers crossed this is the last patch :).

Version 2.2 is definitely getting closer! But now I have problems launching with the windib driver, which I tracked down to SDL_SetGammaRamp. Sure enough, testgamma.exe fails with version 2.2 in windib :(

Why would changing the mouse code affect this, though?

(In reply to comment #9)
> Version 2.2 is definitely getting closer! But now I have problems launching
> with the windib driver, which I tracked down to SDL_SetGammaRamp. Sure enough,
> testgamma.exe fails with version 2.2 in windib :(
> 
> Why would changing the mouse code affect this, though?

The simple answer is that it shouldn't :). The only thing in there that could really be connected is that it checks if the app has SDL_APPINPUTFOCUS before setting the gamma. Even if the conditions here had changed though, I don't see how this would cause anything to fail. Speaking of which how does it fail? It just doesn't start at all?

In any case, I'll take a look tonight.

(In reply to comment #10)
> Speaking of which how does it fail? It just doesn't start at all?

Segfaults in SDL_SetGammaRamp, IIRC.

Hmm, it works fine for me. Though interestingly the official 1.2.13 SDL.dll crashes where you say it does. It is possible it was compiled with the same compiler that you're using and the compiler has a bug? Here is my SDL.dll, with the patches attached to bugs #611, #618 and #619 applied:

http://icculus.org/~tma/SDL.dll

tma@abraxas:~$ i586-mingw32msvc-gcc --version
i586-mingw32msvc-gcc (GCC) 4.2.1-sjlj (mingw32-2)

Let us know if this works for you?

I will give your DLL a try (I will have to recompile because I usually use a static .lib), but stock SDL-1.2.13 and previous versions of your patch do not exhibit this problem for me. So, I am dubious that my (old) compiler is at fault.

Please try http://libsdl.org/release/SDL-1.2.13-win32.zip as well if that's not what you tried before. (I assume it isn't because there is no static lib in this release).

Sure enough, your DLL works. The SDL-1.2.13 DLL does not. Static builds are just the opposite.

I am truly confused.

Perhaps give a different compiler a shot and see if it changes the behaviour you see? In any case I think (I hope!) we can chalk this one up as unrelated to the bug on topic here :).

Yes, I will try to get 4.2.1 installed--it's very difficult--and give it a try. Until then, seems valid to assume this patch is not at fault.

It was not my compiler, it was this: http://bugzilla.libsdl.org/show_bug.cgi?id=622

After fixing that, I was able to verify that mouse control works in all the situations the way I expect using your patch. Works great, thanks a lot for this.

Created attachment 311 [details]
A diff on the diff yo

I added version 2.2 of your patch to subversion.  I wasn't sure whether or not the "diff on the diff" was necessary, as it didn't apply cleanly.  Can you confirm whether it is?

Created attachment 316 [details]
Parts missing from subversion commit of above

First of all, thanks for committing this. Unfortunately it seems the patch has only partially applied to wincommon/SDL_sysevents.c and currently a clean SDL 1.2 checkout doesn't build. The new patch here (http://bugzilla.libsdl.org/attachment.cgi?id=316) fixes this.

The infamous diff of the diff (yo) isn't actually pertinent to this bug. Allow me to explain: we have been distributing a patch to SDL along with ioq3 that included the patches attached to SDL bugs 611, 618 and 619. A third party improved on this patch, but submitted it as a patch to this patch. I have now separated this and added it to bug 618.

In summary, if you could apply the following patches from 611, 618 and 619 respectively, it would mean we no longer need to distribute the patch (or use a patched SDL.dll when a new 1.2 release is made):

http://bugzilla.libsdl.org/attachment.cgi?id=316
http://bugzilla.libsdl.org/attachment.cgi?id=314
http://bugzilla.libsdl.org/attachment.cgi?id=315

Cheers.

I'll take a look, thanks for the well organized patches and bug reports!

It looks like your diff removes some of the GAPI fixes.  Was this intentional?

Ah, I see the comment that addressed that.

Patch committed, thanks!

(In reply to comment #23)
> I'll take a look, thanks for the well organized patches and bug reports!

No problem, I take the attitude that I should submit patches in a manner I'd like to have them submitted to me for my own stuff.

(In reply to comment #24)
> It looks like your diff removes some of the GAPI fixes.  Was this intentional?

Now you mention it I have noticed one small issue. The guard SDL_VIDEO_DRIVER_GAPI has been introduced at some point between me originally writing this patch and now, and there is a call in sdl_dibevents.c which is guarded with the original _WIN32_WCE as the patch wasn't updated when this happened. Patch forthcoming, sorry I didn't catch this before.

Created attachment 318 [details]
s/_WIN32_WCE/SDL_VIDEO_DRIVER_GAPI/

Last one, I promise!

Looks like this was addressed in r4508. Thanks, closing.