Hello, I have a a question about the mouse warp code in dlls/dinput/mouse.c
Why is MOUSE_HACK still defined? From reading the archives I concluded that warping the mouse in three states was disabled long ago(1), but MOUSE_HACK is still defined. I found a patch sent to wine-patches in 2003 which commented this define line(2).
My problem is that this MOUSE_HACK breaks the mouse in Settlers 3, bug 2475 (3). Is there any reason why the mouse hack is still/again activated?
Thanks, Stefan
References: (1)http://www.winehq.org/hypermail/wine-devel/2004/06/0325.html (2)http://www.winehq.com/hypermail/wine-patches/2003/01/0019.html (3)http://bugs.winehq.org/show_bug.cgi?id=2475
Stefan Dösinger wrote:
Hello, I have a a question about the mouse warp code in dlls/dinput/mouse.c
Why is MOUSE_HACK still defined? From reading the archives I concluded that warping the mouse in three states was disabled long ago(1), but MOUSE_HACK is still defined. I found a patch sent to wine-patches in 2003 which commented this define line(2).
My problem is that this MOUSE_HACK breaks the mouse in Settlers 3, bug 2475 (3). Is there any reason why the mouse hack is still/again activated?
Thanks, Stefan
References: (1)http://www.winehq.org/hypermail/wine-devel/2004/06/0325.html (2)http://www.winehq.com/hypermail/wine-patches/2003/01/0019.html (3)http://bugs.winehq.org/show_bug.cgi?id=2475
I think that it is time to really get rid of it I have two more demos that I have been playing with that work when MOUSE_HACK is not defined. Dominions II (1a) and Starlancer (2a). starlancer thinks it is running in a 640X400 window an the program itself is setting the cursor at x=320 and y=200 and dinput trys to put it at x=320 and y=240.
Does anyone know of a game that game that needs it? IE: does not work without it defined?
(1a) http://bugs.winehq.org/show_bug.cgi?id=2056 (2a) http://bugs.winehq.org/show_bug.cgi?id=1410
--
Tony Lambregts
I think that it is time to really get rid of it I have two more demos that I have been playing with that work when MOUSE_HACK is not defined. Dominions II (1a) and Starlancer (2a). starlancer thinks it is running in a 640X400 window an the program itself is setting the cursor at x=320 and y=200 and dinput trys to put it at x=320 and y=240.
I think you are over-reacting here... Your problem is not related at all to MOUSE_HACK (see my next message) but to the general 'mouse warping' problem.
At least I thought I explained it well in the bug report but it seems that it was not the case...
Does anyone know of a game that game that needs it? IE: does not work without it defined?
Well, take all FPS shooters and you will have a nice list :-)
Lionel
Why is MOUSE_HACK still defined? From reading the archives I concluded that warping the mouse in three states was disabled long ago(1), but MOUSE_HACK is still defined. I found a patch sent to wine-patches in 2003 which commented this define line(2).
Undefining MOUSE_HACK will enable a piece of code that worked well in Wine about 4 years back but was broken when AJ introduced event compression in the Wine event loop.
It will NOT disable the warping of the mouse to the middle of the screen, just do it less often...
My problem is that this MOUSE_HACK breaks the mouse in Settlers 3, bug 2475 (3). Is there any reason why the mouse hack is still/again activated?
Are you sure that by disabling MOUSE_HACK, it fixes your problem ? If yes, it's more a side effect of what exactly MOUSE_HACK is than a real fix.
If you could do a +cursor,+dinput trace we could see if it's the classical problem or not.
Lionel
Am Donnerstag, 14. April 2005 20:15 schrieb Lionel Ulmer:
Why is MOUSE_HACK still defined? From reading the archives I concluded that warping the mouse in three states was disabled long ago(1), but MOUSE_HACK is still defined. I found a patch sent to wine-patches in 2003 which commented this define line(2).
Undefining MOUSE_HACK will enable a piece of code that worked well in Wine about 4 years back but was broken when AJ introduced event compression in the Wine event loop.
It will NOT disable the warping of the mouse to the middle of the screen, just do it less often...
Good, that's what I wanted to know in the first place.
My problem is that this MOUSE_HACK breaks the mouse in Settlers 3, bug 2475 (3). Is there any reason why the mouse hack is still/again activated?
Are you sure that by disabling MOUSE_HACK, it fixes your problem ? If yes, it's more a side effect of what exactly MOUSE_HACK is than a real fix.
If you could do a +cursor,+dinput trace we could see if it's the classical problem or not.
I'll have a look at this tomorrow. I didn't test S3 very intensively indeed.
Stefan
Are you sure that by disabling MOUSE_HACK, it fixes your problem ? If yes, it's more a side effect of what exactly MOUSE_HACK is than a real fix.
Yes, it "fixes" the problem. The mouse wasn't moved once during my 2 minute test, but it looks like this is because the mouse warp is broken with MOUSE_HACK undefined.
If you could do a +cursor,+dinput trace we could see if it's the classical problem or not.
Log is attached.
I digged a little bit into the mouse warp thing. It looks like that the mouse warp is used for applications which read the mouse moves. But the cursor still exists and if it reaches the boarder of the screen X wouldn't report any changes in the mouse position, so wine constantly warps the mouse back to the middle of the screen.
MSDN states that there's no cursor handled by windows in ddraw fullscreen mode and that apps have to rely on mouse moves and draw the cursor themselves if they need one. Settler 3 seems to read the mouse moves and set the cusor, which is correct. But wine sets the cursor back to the center of the screen and thus eliminates the mouse move.
Are my observations correct? In this case any game which uses DDSCL_FULLSCREEN, DirectInput and the mouse cursor this this way will fail.
Settlers 3 has a strange problem with the fullscreen mode. It sets WS_CAPTION in it's main window's style and the DDSCL_EXCLUSIVE and DDSCL_NORMAL flags when calling DirectDraw_SetCooperativeLevel. In Managed mode my window manager draws the window caption and the contents of the window are missplaced. In Desktop mode wine reserves space for a window caption and missplaces the contents of the window and I get a black window caption inside the Desktop window. I worked around this problem by filtering the WS_CAPTION flag in Main_DirectDraw_SetCooperativeLevel, which is not correct but works for that game. This doesn't influence the mouse warp problem, but I thought it might be worth mentioning.
Stefan
On Sat, Apr 16, 2005 at 10:52:10PM +0000, Stefan Dösinger wrote:
Yes, it "fixes" the problem. The mouse wasn't moved once during my 2 minute test, but it looks like this is because the mouse warp is broken with MOUSE_HACK undefined.
No, I think it's due to a bug in Wine:
trace:dinput:SysMouseAImpl_GetDeviceData (0x77c60a80)->(dods=16,entries=-1,fl=0x00000001) trace:dinput:SysMouseAImpl_GetDeviceData Application discarding 2 event(s). trace:dinput:SysMouseAImpl_GetDeviceData Warping mouse to 400 - 300
So basically the application is trying to get the number of events in the queue and we just discard all of them.
As before, a patch will be done when I come back home (I really should have taken the time to install Linux on this laptopt :-) ) but I think it's pretty easy to fix (i.e. just handle the 'PEEK' attribute in the 'dod == NULL' case).
A real proper fix would need to handle the 'INFINITE' value for 'entries' and stuff like this, but well, I doubt it's really necessary.
Anyway, the bug is that we tell the application that there are two events in the queue (but erase them in the process of querying) and when the application actually asks for these two events, we do not return any as we flushed them.
So the game cursor will not move at all :-)
I digged a little bit into the mouse warp thing. It looks like that the mouse warp is used for applications which read the mouse moves. But the cursor still exists and if it reaches the boarder of the screen X wouldn't report any changes in the mouse position, so wine constantly warps the mouse back to the middle of the screen.
Basically yeah. It comes mostly from the fact that DInput requires relative mouse movements (a mouse does not report any absolute axis in Windows and if you request absolute mode, it's completely broken, even on Windows).
The problem is how to handle a case when the user continuously moves his mouse to - let's say - the right and that your mouse cursor reaches the edge of your screen ? X11 will always report the same X coordinate and thus even if the user moves his mouse, Wine will report to the game that the mouse did not move in the horizontal direction.
So a part from an X11 extension (which I plan to work on again one of these days with the X.org guys), the only way to support this is via mouse warping (note that DGA mouse exists, but well, it's a bit ugly and is a bit frowned upon by the X people now).
Lionel
-
Lionel Ulmer -
Stefan Dösinger -
Tony Lambregts