Hi,
I'm new to Wine and DirectX development, but I've dug around a bit in the Wine source code to get Determinance, a sword-fighting game to work. I've submitted an entry for it to the application database.
The main problem I had was with strange mouse behaviour in full screen mode. The player can rotate his character by holding down the right mouse button and moving the mouse. In Windows, this allows you to turn as much as you want. In Wine, the rotation stops at a certain point. You can't see the cursor, but I'm fairly certain the point at which movement stops is when the cursor hits the edge of the screen.
When this has happened and you return to the main menu, it can occur that for example the cursor can't reach the top part of the screen anymore. It's as if an invisible rectangle that keeps the cursor inside the screen has moved. In such a case, moving the cursor all the way to the bottom and back up again restores normal behaviour.
I've isolated the problem to the following line in dlls/dinput/mouse.c :
This->need_warp = (pt.x || pt.y) && dwCoop & DISCL_EXCLUSIVE;
Changing it to This->need_warp = TRUE; as a quick test makes the mouse behave correctly.
I've read about the mouse warping hack over here: http://www.kernel-traffic.com/wine/wn20040618_227.html#2 . Inserting a TRACE statement displaying the variables in that line of code revealed that:
- it is only executed in full screen mode, and not in windowed mode - dwCoop is DISCL_NOWINKEY , causing the expression to evaluate to false.
So it seems the DISCL_EXCLUSIVE constraint is too restrictive. Reading about the meanings of the dwCoop values at msdn ( http://tinyurl.com/2lmgbw ), I'm guessing the Determinance developers might not have entirely been following the rules. However, it works properly on Windows. Would it be acceptable to drop the DISCL_EXCLUSIVE constraint?
Raf Geens
Hi similar bug with mouse in TES IV: Oblivion was introduced in wine 0.9.31
Mirek
Raf Geens napsal(a):
Hi,
I'm new to Wine and DirectX development, but I've dug around a bit in the Wine source code to get Determinance, a sword-fighting game to work. I've submitted an entry for it to the application database.
The main problem I had was with strange mouse behaviour in full screen mode. The player can rotate his character by holding down the right mouse button and moving the mouse. In Windows, this allows you to turn as much as you want. In Wine, the rotation stops at a certain point. You can't see the cursor, but I'm fairly certain the point at which movement stops is when the cursor hits the edge of the screen.
When this has happened and you return to the main menu, it can occur that for example the cursor can't reach the top part of the screen anymore. It's as if an invisible rectangle that keeps the cursor inside the screen has moved. In such a case, moving the cursor all the way to the bottom and back up again restores normal behaviour.
I've isolated the problem to the following line in dlls/dinput/mouse.c :
This->need_warp = (pt.x || pt.y) && dwCoop & DISCL_EXCLUSIVE;
Changing it to This->need_warp = TRUE; as a quick test makes the mouse behave correctly.
I've read about the mouse warping hack over here: http://www.kernel-traffic.com/wine/wn20040618_227.html#2 . Inserting a TRACE statement displaying the variables in that line of code revealed that:
- it is only executed in full screen mode, and not in windowed mode
- dwCoop is DISCL_NOWINKEY , causing the expression to evaluate to false.
So it seems the DISCL_EXCLUSIVE constraint is too restrictive. Reading about the meanings of the dwCoop values at msdn ( http://tinyurl.com/2lmgbw ), I'm guessing the Determinance developers might not have entirely been following the rules. However, it works properly on Windows. Would it be acceptable to drop the DISCL_EXCLUSIVE constraint?
Raf Geens
Raf Geens wrote:
When this has happened and you return to the main menu, it can occur that for example the cursor can't reach the top part of the screen anymore. It's as if an invisible rectangle that keeps the cursor inside the screen has moved. In such a case, moving the cursor all the way to the bottom and back up again restores normal behaviour.
I've isolated the problem to the following line in dlls/dinput/mouse.c :
That's the consequence and not the real place where the problem is.
This->need_warp = (pt.x || pt.y) && dwCoop & DISCL_EXCLUSIVE;
Wine'd dinput warps mouse in some cases (much lesser number then it was before) while it shouldn't do that at all!
The real issue is in x11drv which should warp mouse and report "relative" mouse moves while it doesn't. I've sent two patches that haven't been applied yet.
See bug 6971 for more info.
Vitaliy.
-
Mirek -
Raf Geens -
Vitaliy Margolen