http://bugs.winehq.org/show_bug.cgi?id=2507
Summary: Fallout: mouse doesn't move at all Product: Wine Version: unspecified Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: wine-directx AssignedTo: wine-bugs@winehq.org ReportedBy: wsapplegate@myrealbox.com
Executive summary : ~~~~~~~~~~~~~~~~~~~ Fallout is and old (circa 1997) RPG, published by Interplay. Upon recently trying to reinstall the game, I came across a problem : the mouse wouldn't move. Even performing the installation through the keyboard wasn't of much help, since the game exhibited the same problems (it also grabbed my pointer, I needed to escape the uncontrollable game window by changing virtual desktop and moving the pointer out of the way).
Analysis : ~~~~~~~~~~ Quite frankly, I really don't know enough about DirectInput to know why that problem appeared, but I've at least found what causes it. The problem appears since WINE 20040615, which has seen an overhaul of several DirectInput-related files. The problem is located in the file dlls/dinput/device.c and has apparently been caused by a CVS commit on 2004-06-02[1]. In the function create_DataFormat(), the following lines are changed :
- (wine_format->rgodf[i].dwType & asked_format->rgodf[j].dwType)) { + (/* Then check if it accepts any instance id, and if not, if it matches Wine's + * instance id. + */ + ((asked_format->rgodf[j].dwType & 0x00FFFF00) == DIDFT_ANYINSTANCE) || + (DIDFT_GETINSTANCE(wine_format->rgodf[i].dwType) == DIDFT_GETINSTANCE(asked_format->rgodf[j].dwType)))) {
Reverting this change makes the mouse to work again.
[1] http://cvs.winehq.com/cvsweb/wine/dlls/dinput/device.c.diff?r1=1.16&r2=1...
How to reproduce : ~~~~~~~~~~~~~~~~~~ Assuming you have a Fallout CD in drive D:,
* run "wine 'd:\_setup.exe'" (alternatively, if the game is already installed, run "wine <path to the game directory>\falloutw.exe") * notice you cannot move the mouse
Solutions and workarounds : ~~~~~~~~~~~~~~~~~~~~~~~~~~~ I've found no workaround for this problem. Reverting the change in create_DataFormat() works for me, but is probably incorrect (I haven't been able to ascertain what effects it could have on other DirectInput-based software).