this is a more complete version of my mouse patch in which I tried to remove this funny mouse-warping-stuff.
the mouse feels much better this way, but I am new to wine and maybe I missed something important and/or did not remove the mousewarping cleanly.
Errrm, do you understand exactly what you remove and why it was in the code ?
Basically, if you remove mouse warping, when you play games like Quake, you will only be able to turn to your right (or left :-) ) for a fixed amount... I.e. up until the point where the mouse will hit the right border of the window. I agree though that 2D games (like StarCraft or others) will feel a LOT better with a patch like that, but it's plainly wrong.
The only way to fix this is to sometimes warp the mouse back in the middle of the window (or to use DGAMouse (or to write a new X11 extension :-) )).
Lionel
No, not exactly. There are several things in wine I don't know yet (eg what does GEN_EVENT do exactly / what are these critical-sections / etc.). But I think doing mouse-warping in 3 states and across different functions is much to complicated and while it works great in MaxPayne, it behaves strangely in WWIIOL. I tried to do it in a simpler way. Maybe I'll just try to understand wine a little deeper and post a more elaborated patch later. Sound and joystick don't work too well in WWIIOL too (the joystick seems to send random data / I get only 1 channel of the sounds) so there's still a lot to do.
jda
Lionel Ulmer wrote: [...]
Errrm, do you understand exactly what you remove and why it was in the code ?
[...]
The only way to fix this is to sometimes warp the mouse back in the middle of the window (or to use DGAMouse (or to write a new X11 extension :-) )).
Lionel
No, not exactly. There are several things in wine I don't know yet (eg what does GEN_EVENT do exactly / what are these critical-sections / etc.). But I think doing mouse-warping in 3 states and across different functions is much to complicated and while it works great in MaxPayne, it behaves strangely in WWIIOL. I tried to do it in a simpler way. Maybe I'll just try to understand wine a little deeper and post a more elaborated patch later. Sound and joystick don't work too well in WWIIOL too (the joystick seems to send random data / I get only 1 channel of the sounds) so there's still a lot to do.
jda
Lionel Ulmer wrote:
Errrm, do you understand exactly what you remove and why it was in the code ?
[...]
The only way to fix this is to sometimes warp the mouse back in the middle of the window (or to use DGAMouse (or to write a new X11 extension :-) )).
Lionel
On Thu, Jun 17, 2004 at 09:19:29AM +0200, James Dean Anderson wrote:
No, not exactly. There are several things in wine I don't know yet (eg what does GEN_EVENT do exactly / what are these critical-sections / etc.).
Welln this is related to the way DInput works: you have two ways to get informations from your devices, either you get an immediate picture of the device state at a given time (GetDeviceState) or you can get all the individual timestamped events that occured since last time you queried the device (GetDeviceData).
So GEN_EVENT simply queues a hardwware event into the queue that can be queried via 'GetDeviceData'.
The critical sections are here because you can have one thread queuing events (Wine's hardware event thread) while another (the game) can access the data, which means you need to protect against concurrent usage.
But I think doing mouse-warping in 3 states and across different functions is much to complicated and while it works great in MaxPayne, it behaves strangely in WWIIOL.
The warping in three states has been disabled for a long time now (it is only enabled if you #define MOUSE_HACK). It's an idea that worked once, but not anymore due to mouse event compression in some core part of Wine's input handling. The idea was that, basically, as the fact of warping the mouse WILL generate an X11 event for you, you could detect when the warp was actually done by checking when the ext mouse position corresponds to your warp position. Which would prevent some 'glitches' if you got a queued X11 event back from before the warp buf after you issued the warp command to the X11 server.
As to doing it only in the 'mouse even hook' I agree that it is cleaner that way (I missed this line when checking your patch so I thought that you removed warping completely :-) ). The only problem here is that you may have a LOT more warps done that way than in the previous way. For example, if X11 generates 10 X mouse events for each game 'frame', you will warp your mouse 10 times more with your code than with the current one (which only warped the mouse when the game actually queries the device).
But the main way to rework this would be to put the complete warping stuff in the X11 driver (as the way it's done now is fundamentally flawed for some games).
Note also that it would be much nicer to do a 'rectangle' warp instead of a 'point' wrap: do not wrap on each mouse event, but only when the mouse goes out of a centered rectangle which would be about half the size of the screen. This would have the advantage of smoother mouse movements as it would minimize a lot the number of warps.
And DGAMouse support / X11 extension writing would be the other way :-)
Lionel
ok I see now that my warp-replacement isn't that much of an improvement. (stuff similar to 'if(a!=b) a=b;' set me in an agressive state about replacing (-: ). Thank you for explaining things, this gives me a better starting point for further work. I'd really like the joystick to work in that game for instance and maybe I'll come back to mouse input if I'm successful... it's just that threads and events always scared me (-:
jda
Lionel Ulmer wrote: [...]
But the main way to rework this would be to put the complete warping stuff in the X11 driver (as the way it's done now is fundamentally flawed for some games).
[...]
And DGAMouse support / X11 extension writing would be the other way :-)
Lionel
On Thu, 17 Jun 2004 14:43:54 +0200, James Dean Anderson wrote:
successful... it's just that threads and events always scared me (-:
I bugged Newman yesterday and because he's a total rockstar he fixed the bug in the doc generation script, so the latest developer guide is now on the net:
http://winehq.com/site/docs/wine-devel/threading
explains the Wine multi-threading in more detail than you probably want, however if you read the first section it may help. Basically a critical section is a mutex (or MUTual EXclusion): when one thread has entered the critical section all other threads that try to enter queue up at the entrance until the thread currently inside leaves.
This allows you to prevent multiple threads from running the same piece of code at once. It's essential for things like linked list manipulation. Because the entirety of Win32 is thread safe you will see this sort of thing all over the place.
If a thread deadlocks on a critical section (ie is queued up waiting to enter for a long time) you will see a message like this:
err:ntdll:RtlpWaitForCriticalSection thread 0x9 timed out waiting for thread 0x10 in 0x12345678 (?)
The ? means the critical section is unnamed. Virtually all Wine internal sections are named so you can identify them, so ? normally means the section was created by an application.
thanks -mike
-
James Dean Anderson -
Lionel Ulmer -
Mike Hearn