Deus Ex: Human Revolution - update.
Version 1.1.622.0 released by Eidos Montreal, on 25 Aug, 2011.
Changelog for this patch:
General Fixes:
Control Fixes:
Deus Ex: Human Revolution - hot-fix update.
Version 1.1.620.0 released by Eidos Montreal, on 23 Aug, 2011.
Changelog for this hot-fix patch:
Deus Ex: Human Revolution initial release.
Version 1.0.618.8 released by Eidos Montreal, on 23 Aug, 2011.
The initial release version for DXHR.
Application Details:
Version: | 1.1.622.0 |
License: | Retail |
URL: | https://www.deusex.com/game/dx... |
Votes: | Marked as obsolete |
Latest Rating: | Garbage |
Latest Wine Version Tested: | 1.3.29 |
Maintainers: About Maintainership
What works
What does not
Workarounds
What was not tested
Hardware tested
Graphics:
Additional Comments
Tested at AMD Phenom II X3 710 with nV GFX 560, nV proprietary drivers version 280.13 To play the game you need: * to make menu work - raw-input patch 8-8-2011 from bug#20395 * to get rid off graphic glitches - edit registry with regedit and set D3D workarounds mentioned in how-to * if you have GFX 560 you might need a patch from bug#28321 Garbage rating given, because game doesn't run with native wine at the moment.
Operating system | Test date | Wine version | Installs? | Runs? | Used Workaround? | Rating | Submitter | ||
Current | Slackware64 -current | Oct 01 2011 | 1.3.29 | Yes | Yes | No | Garbage | Zdenek Styblik | |
Show | Arch Linux | Nov 18 2011 | 1.3.28 | No, but has workaround | Yes | No | Garbage | an anonymous user | |
Show | Arch Linux x86_64 | Oct 02 2011 | 1.3.28 | Yes | Yes | No | Garbage | TT | |
Show | Ubuntu 11.04 "Natty" amd64 (+ variants like Kubuntu) | Sep 11 2011 | 1.3.28 | Yes | Yes | No | Garbage | Samuel | |
Show | Ubuntu 11.04 "Natty" amd64 (+ variants like Kubuntu) | Sep 08 2011 | 1.3.27 | Yes | Yes | No | Garbage | CaptainRedShirt |
These notes were last updated: 28 November 2017
Follow these guidelines to avoid embarrassment when your Test Submission is immediately rejected!!
These guidelines ensure your submitted test results are actually relevant to other users of Wine and WineHQ.
1 The console version of the lshw utility is your friend. This command will dump your System hardware specification in a clean format. Post command and output in the Extra Comments section:
sudo lshw -short | egrep -v '(volume|disk|bus)'
2 glxinfo can be used to display your OpenGL and graphics driver versions. Post the command and output in the Extra Comments section:
glxinfo | egrep '^[[:alpha:]]'
DirectX 11 Support
As of Wine version 1.7.53(+) there are tests enabled to see if your graphics hardware supports DirectX 11... Unfortunately a significant amount of the DirectX 11 translation layer has still to be implemented in Wine.
On supported hardware, Deus Ex: Human Revolution will start in DirectX 11 mode. The menus may display correctly. In game there will be a lot of graphical corruption and missing textures.
The workaround is to disable support for the DirectX Graphics Infrastructure (DXGI) in Wine:
wine reg.exe ADD "HKEY_CURRENT_USER\Software\Wine\AppDefaults\dxhr.exe\DllOverrides" "/v" "dxgi" "/t" "REG_SZ" "/d" "" /f
Graphical Corruption
Wine, by default, does DirectX draw calls in a different order from Deus Ex: Human Revolution running under Windows.
The workaround is to enable strict draw ordering (via a registry key):
wine reg.exe ADD "HKEY_CURRENT_USER\Software\Wine\AppDefaults\dxhr.exe\Direct3D" "/v" "StrictDrawOrdering" "/t" "REG_SZ" "/d" "enabled" /f
In addition the AlwaysOffscreen registry setting is enabled by default (since wine version: 1.5.10). It is important that this registry setting should be left enabled.
Mouse Escapes Window (Wine Virtual Desktop mode)
The symptom of this problem is that when Deus Ex: Human Revolution is run in a Wine Virtual Desktop the mouse can escape from the fullscreen game window.
The workaround is to enable the grab mouse in full screen mode setting (via a registry key):
wine reg.exe ADD "HKEY_CURRENT_USER\Software\Wine\X11 Driver" "/v" "GrabFullscreen" "/t" "REG_SZ" "/d" "Y" /f
This is a workaround introduced by Wine Bug 6971 - Mouse "escapes" window or is confined to an area in the full screen program.
Incorrect DPI Scaling of Elements
The symptom of this issue is that all UI popup elements, the in-game HUD, etc. are scaled to an inappropriately small size. This appears to manifest on a single-head X session with multiple monitors, combined into a single X display.
The only known workaround is to use a Wine Virtual Desktop. The issue is to be investigated further as no Wine bugs appear to be filed against it.
In-game stuttering and generally low FPS
Enabling StrictDrawOrdering leads to a high price in game performance. It is recommended, certainly for Nvidia GPU users (using the proprietary driver), to use the Wine Staging CMST patchset available in the Wine Staging package. AMD GPU users who are using Gallium Nine may not require or benefit from this patchset.
This unstable feature can be enabled in the Staging tab of the winecfg utility. Regressions (crashes, graphical artifacts, etc.) should be reported at the WineHQ Bugzilla - stating that the Wine Staging patchset was used.
The following comments are owned by whoever posted them. WineHQ is not responsible for what they say.
by FreakyCheeseMan on Saturday September 15th 2012, 14:24
So, I finally got the input working, by installing wine to a 32-bit chroot; however, whenever I try to run the program, it doesn't display right- I think it isn't drawing any textures, or at least not most of them.
I noticed one thing- the terminal output has a long list of bugs that look like
GL_INVALID_OPERATION (0x502) from glUseProgramObjectARB @ glsl_shader.c / 4707
Which occur whether or not I have UseGLSL disabled in regedit. In fact, nothing seems to change based on what I do in regedit- is there a good test for whether or not it's even looking at those settings to begin with?
by FreakyCheeseMan on Wednesday September 12th 2012, 10:17
1: No input (other than mouse movement) is recognized.
2: The graphical corruption remains. However, if I ctrl-alt-F1, then ctrl-alt-F7, the menu appears correctly - still no input, though.
I think my problem is the 32 vs. 64 bit thing; I have a 64 bit system, and when I followed the instructions, I got "configure: error: Cannot build a 32-bit program, you need to install 32-bit development libraries."
In order to get past that point, I did ./configure --enable-win64 , which let me continue the installation, but I think may have meant the patch did not apply correctly.
Any ideas where I'm going wrong? I mean, at this point it's mostly academic, as I've completely screwed up the system to the point where I can no longer even install wine normally, but...
by Maquis196 on Wednesday September 12th 2012, 10:33
wiki.winehq.org/WineOn64bit#head-b62ae8f996e97e1df7258bb8eaec2e83e54ca799
I'd see if a 32bit wine install works with the patch, if not it could be the patch isn't installed correctly. You'd need to run the program after the patch (./tools/makedep I think?) before running configure.
Let see how this goes and hopefully its working for you after this.
Cheers,
Chris
by FreakyCheeseMan on Wednesday September 12th 2012, 15:16
I tried following the instructions from that article, but when I tried to apply the patch, it said "Did not apply" - I figure because the patch was for the tarball. (Tried both rawinput2 and rawinput3).
I went back and tried modifying the instructions to use the 1.3.27 tarball, which worked up until the make, which failed with a few errors:
input.c:870:1: error: 'REQ_get_raw_input_device_info' undeclared (first use in this function)
input.c:872:12: error: dereferencing pointer to incomplete type
input.c:873:12: error: dereferencing pointer to incomplete type
input.c:874:12: error: dereferencing pointer to incomplete type
input.c:880:29: error: dereferencing pointer to incomplete type
input.c:884:27: error: dereferencing pointer to incomplete type
input.c: In function 'GetRegisteredRawInputDevices':
input.c:913:5: error: 'union generic_request' has no member named 'get_registered_raw_input_devices_request'
input.c:913:5: error: 'union generic_reply' has no member named 'get_registered_raw_input_devices_reply'
input.c:913:1: error: 'REQ_get_registered_raw_input_devices' undeclared (first use in this function)
input.c:915:12: error: dereferencing pointer to incomplete type
input.c:921:35: error: dereferencing pointer to incomplete type
input.c:925:27: error: dereferencing pointer to incomplete type
make[1]: *** [input.o] Error 1
make[1]: Leaving directory `/wine/wine-1.3.27/dlls/user32'
make: *** [dlls/user32] Error 2
Not sure what to try, next.
by Maquis196 on Wednesday September 12th 2012, 15:26
Apply the patch into the new 1.5 source, run the tools script and try again.
And hopefully that will work (try 1.5.9 or something for 1.5, in case 1.5.12 doesn't work, I haven't tried it myself)
by FreakyCheeseMan on Wednesday September 12th 2012, 16:57
wine: '/home/autumn/.wine' is a 64-bit installation, it cannot be used with a 32-bit wineserver.
I presume this means I need to set up the 32-bit wine with its own wineprefix/drive_c inside the chroot. However, whenever I try to do $WINEPREFIX=, it tells me the given directory does not exist, which is odd as I can see it with ls. Tried setting the wine prefix to hidden and visible directories inside both the home folder and chroot- no luck.
One thing that might be relevant- when I do echo $WINEPREFIX, it returns a blank line.
by Maquis196 on Wednesday September 12th 2012, 17:01
The way I use wineprefix is like thus;
mkdir ~/wine_games
WINEPREFIX=~/wine_games/deusex wine "c:\program files\steam\steam.exe"
basically use the WINEPREFIX= at the beginning of every line. You'll soon learn to love using it since so many games need their own custom winecfg's and what not.
by FreakyCheeseMan on Wednesday September 12th 2012, 18:10
So, the rawinput patch was successful; I can navigate the menus now (And thanks for that- I've been struggling with this for days). However, once I actually get into the gameplay, there's this tan fog over everything, almost all of the textures are screwed up, and it's extremely slow to do anything.
I tried re-installing Steam and then Deus Ex within the new WinePrefix, but when I try to run the steam installer, I get:
wine: Bad EXE format for Z:\home\autumn\Downloads\SteamInstall.msi.
I know the Wine can handle that MSI- it's how I installed it to begin with- but I'm not sure how to make it do so from the new 32-bit Wine. Similarly, I'm not sure how to access Winetricks for that, in order to fool around with directx and video settings.
by Maquis196 on Thursday September 13th 2012, 4:12
Just use the wineprefix for everything so winetricks is;
WINEPREFIX=~/wine_games/deusex winetricks
The steam install is a little different, it could be that youre trying to run the msi directly, for an msi you'd do;
WINEPREFIX=~/wine_games/deusex wine msiexec /i ~/Downloads/steaminstall.msi
by FreakyCheeseMan on Thursday September 13th 2012, 12:06
I have home/.wine-old, which is a 64-bit installation, but has steam and Deus Ex installed inside it. If I run that steam file with the 32-bit chroot steam, using the 32-bit home/.wine prefix (below), it works, except the game is slow and doesn't display any textures.
I have the new home/.wine, which is a 32-bit installation, but does not have Steam installed; when I try to run SteamInstall.msi with the normal, 64-bit wine, it refuses to display any fonts (I tried installing tahoma through winetricks), and I'm unable to make it through the setup process; when I try to run it with the 32-bit chroot installation, it says it's in a directory it can't write to (presumably because of the chroot).
Finally, I have /var/chroot/home/.wine, which is a 32-bit installation into which I was able to install both steam and Deus Ex- however, when I try to launch Deus Ex through steam, nothing happens- the launcher shows up for a moment and goes away. Also, I'm not sure why this is, but even when steam is running, it doesn't show up as a process in the system monitor.
Long story short... I am very confused.
by FreakyCheeseMan on Thursday September 13th 2012, 12:49
Also, a much more minor glitch- the menus have this strange, flickering distortion, where random polygons and ascii symbols flash across the screen; it doesn't make them unreadable or unusable, and it goes away if I use ctrl-alt-f1 to switch to a terminal-only UI, and then switch back.
by Thomas L on Wednesday September 21st 2011, 3:50
Sometime it work but the sound of the tiny video is realy bad.
I use wine 1.3.27 with the patch.
I use AlsaDriver (i can not choose OSS driver...)
And i try on "Emulation" and "Full" hardware acceleration
(Sorry for my bad english !)
fixme:alsa:AudioClient_GetMixFormat Don't know what to do with 8 channels, pretending there's only 2 channels
fixme:alsa:AudioClient_GetMixFormat Don't know what to do with 10000 channels, pretending there's only 2 channels
fixme:alsa:AudioClient_GetMixFormat Don't know what to do with 10000 channels, pretending there's only 2 channels
fixme:alsa:AudioClient_GetMixFormat Don't know what to do with 10000 channels, pretending there's only 2 channels
fixme:avrt:AvSetMmThreadCharacteristicsW (L"Audio",0x582ea44): stub
fixme:advapi:RegisterTraceGuidsW (0x62d24d0, 0x62dd6e8, {7c830ece-5fb3-417a-a1bd-508f45277356}, 1, 0x33e334, (null), (null), 0x62dd6f0,): stub
fixme:d3d_surface:surface_load_ds_location No up to date depth stencil location.
fixme:nls:GetGeoInfoA -1 5 (nil) 0 0
err:ole:CoGetClassObject class {d27cdb6e-ae6d-11cf-96b8-444553540000} not registered
err:ole:CoGetClassObject no class object {d27cdb6e-ae6d-11cf-96b8-444553540000} could be created for context 0x1
fixme:winsock:WSACancelAsyncRequest (0xdeae),stub
fixme:winsock:WSACancelAsyncRequest (0xdeaf),stub
fixme:file:MoveFileWithProgressW MOVEFILE_WRITE_THROUGH unimplemented
fixme:d3d:state_zfunc D3DCMP_NOTEQUAL and D3DCMP_EQUAL do not work correctly yet.
^Cfixme:console:CONSOLE_DefaultHandler Terminating process 8 on event 0
wine client error:9: write: Bad file descriptor
by Tiago Domingues on Sunday October 2nd 2011, 17:09
No solution regarding that...
by Galym Kerimbekov on Tuesday September 20th 2011, 6:56
depositfiles.com/files/rcknngusd
by David on Monday September 19th 2011, 14:06
And the biggest problem is that as long as steam is running, not just the mouse pointer is messed up, but im also limited to 180 degrees mouse rotation, which makes the game pretty much unplayable.
As soon as I kill steam (using "killall -9 steam") after starting Deus Ex Human Revolution, and AFTER loading a game OR starting a new game, the X11 mouse pointer disappears and I get the full 360 degrees mouse rotation.
BUT since steam is killed I'm no longer able to save any progress and sometimes dxhr even crashes.
I've tried all kind of options, like disabling window decoration and disabling grabbing the mouse pointer options and using a emulated desktop => same result (double mouse pointer + only 180degrees mouse rotation)
I've tried to put steam in offline mode and uncheck all 'cloud saving' options => still failes to save any progress as soon as I kill steam.exe
Does anyone have a solution to this problem?
Suggestions are welcome as well :)
Test Info:
Using Patched wine 1.3.27 to be able to click anything:
# cd ~/lib/
# wget prdownloads.sourceforge.net/wine/wine-1.3.27.tar.bz2
# cd wine-1.3.27
# wget dl.dropbox.com/u/6901628/raw2.patch -O /tmp/raw2.patch
# patch -p1 < raw2.patch
# ./tools/make_requests
# ./configure
# make
Using a seperate WINEPREFIX, launching via steam:
# WINEPREFIX="/opt/wineprefixes/dxhr"
# cd $WINEPREFIX/drive_c/Program Files/Steam
# ~/lib/wine-1.3.27/wine steam "rungameid/28050"
Extra info (used to prefent graphical glitches):
user.reg tweaks:
[Software\\Wine\\Direct3D]
"AlwaysOffscreen"="enabled"
"StrictDrawOrdering"="enabled"
"UseGLSL"="disabled"
"VideoMemorySize"="1536"
run 'winecfg' (using the correct WINEPREFIX):
1 - go to the 'Graphics' tab and check:
'Automatically capture the mouse in full-screen windows'
2 - go to the 'Audio' tab and select:
'Emulation' as 'Hardware Acceleration'
3 - go to the 'Applications' tab and select:
'Windows 7' as 'Windows Version'
Test system used:
Qosmio X500-15F gaming laptop:
video card: NVIDIA GTX 460M - 1536MB
memory: 8GB SO-DIMM DDR3-1333
cpu: Intel i7-2630QM Quad Core @2.00Ghz
by David on Monday September 19th 2011, 14:08
should just be
"# wget dl.dropbox.com/u/6901628/raw2.patch"
by Kevin Turner on Monday September 19th 2011, 15:42
The limited rotation is a thing that I see *sometimes*. There are a few things I try:
1) load a menu screen (like inventory), move the mouse around in there, and then resume the game and see if that changes it
2) wait around a bit, sometimes the game is unresponsive at first but then gets better (maybe it's loading maps or textures or something, who knows)
3) if all else fails, quit DX:HR (but _not_ wine) and re-launch it from Steam, sometimes it works better on the second time.
I think the patched wine 1.3.27 as you have worked okay for me, but you might also update to 1.3.28 (raw2.patch still required).
by David on Tuesday October 4th 2011, 13:38
Well no 180 degrees mouse rotation makes it pretty unplayable, for example when I walk arournd a corner to the left and an enemy is standing there even a bit further to the left, the odds are very high that I cant aim at that target because I can't turn any further... and there a lot of situations where its a serious problem not to able to move somewhere, because the mouse is stuck at that 180 degrees rotation max.
And about the desktop mouse pointer visible: its not just visible it also blinking a few times per second! (very irritating)
I tried all your suggestion and none work.
Yesterday I also tried wine 1.3.29 with the new mouse patch of 8-8-2011, but same result as before :(
I think that as long as steam is running, it captures the mouse at the window border or something, and halts the rotation there. Because as soon as I kill steam, I got 360 degrees mouse rotation and only the ingame mouse, but as I said before I lose the ability to save any progress :(
So if you have any other suggestion, please let me know!
I currently still have no solution to play the game a bit playable :(
by Rob on Sunday September 18th 2011, 12:04
I'm running a seperate version of wine for deus ex (Patched for raw input) and I've ensured that I'm running regedit under the correct prefix (different apps are installed).
Any suggestions are greatly appreciated!
System:
Mint 9 (Ubuntu Lucid)
NVidia GTX 460
2GB RAM
by Mateusz Stachowski on Sunday September 18th 2011, 13:51
by Rob on Sunday September 18th 2011, 16:16
by Mateusz Stachowski on Sunday September 18th 2011, 16:55
[Software\\Wine\\Direct3D] 1240428288
"AlwaysOffScreen"="enabled"
"StrictDrawOrdering"="enabled"
"UseGLSL"="disabled"
"VideoDescription"="NVIDIA GeForce 9600 GT"
"VideoDriver"="nv4_disp.dll"
"VideoMemorySize"="512"
"VideoPciDeviceID"=dword:00000622
"VideoPciVendorID"=dword:000010de
You can do that editing user.reg (it's in wineprefix) just add it after this:
[Software\\Wine\\Debug] 1311009160
What version of nVidia driver you have installed maybe it's to old. You are using Mint 9 which is based on Ubuntu Lucid that's old isn't it. I'm currently using nVidia driver 285.03 from xorg-edgers PPA.
by Rob on Sunday September 18th 2011, 22:02
Lucid (10.04) is the current LTS so it should be okay, it'll be kept up to date for awhile yet.
I'll try adding more details to the Direct3D key and see if I get anywhere and report back what happens.
by Rob on Friday September 23rd 2011, 1:01
by Mateusz Stachowski on Friday September 23rd 2011, 12:31
Another possibility is that you made some kind of error when adding the registry keys. Maybe you forgot some letter or typed it underscore. You could check it by opening the user.reg (in text editor Gedit, Geany or KWrite) file and searching for the Direct3D. You probably did that appropriate but it doesn't hurt to make sure.
by Rob on Friday November 11th 2011, 22:10
by dhasenan on Thursday September 15th 2011, 23:55
by dhasenan on Friday September 16th 2011, 9:59
I think it runs better if you don't use a compositing window manager. Not sure, though.
by Thomas L on Friday September 23rd 2011, 12:10
$ pwd
/home/albert/.wine/drive_c/Program Files/Square Enix/Deus Ex - Human Revolution
$/var/wine/wine-1.3.27/wine dxhr.exe
by Brian on Thursday September 15th 2011, 9:10
P4 x4 i7
16g RAM
nvidia 9600gt
dual monitors (2560x1024)
WD 750gb hdd
Newest stable nvidia drivers
11.04 Natty x64
32-bit WINE
ALSA sound on wine
That changed my game experience considerably.
I've been able to pinpoint my issues somewhat (hopefully others have similar issues), although I'll need a real wine connoisseur to make any progress.
First of all, loading levels/maps/etc (when the loading icon appears at the top) causes a minor slowdown, but it's barely noticeable. This used to be slow.
General gameplay is pretty good, although laggy with keyboard and mouse
In rooms with lots of sprites, input is seriously lagged
When I get into a gunfight, if I "Duck and Cover"+"Shoot" or "DnC"+"Left/Right", mouse movement is virtually nonexistant: I can wave the mouse around wildly with no movement onscreen. Keyboard input is delayed a couple of seconds.
Sound clicking is GONE. I still get the ALSA error, though.
My graphics settings don't seem to make any difference. For example, the resolution is perma-set at 2560x1024 (not sure why, and the game only runs full-screen in one screen atm), and none of the other "Advanced" settings really seem to make a difference at all. Changing everything from maxed out to bare minimum might have added 2-3FPS (perceptually).
I think my next steps will be to try a different sound backend.. Anybody have any results with Pulse or even OSS? Do you get errors in STDOUT when you play the game?
And to try to figure out what's up with the resolution. Wine is even set to emulate a 1280x1024 virtual desktop (since it won't autoscale) and it's still messed up. I imagine running at 1024x768 might help my graphics situation. Anybody have any ideas on this? I imagine if all the people running around with slow graphics are all running at max resolution and going "But on Wine, I can do this!" like I have been, there might be a simple solution to some of the issues.
by Zdenek Styblik on Monday September 26th 2011, 13:16
I have OSSv4 and sound doesn't work for me in DE:HR. I'm getting error:
---
FMOD error! (79) The sound created exceeds the allowable input channel count. This can be increased using the maxinputchannels parameter in System::setSoftwareFormat.
---
yet I haven't figured out yet where/how to fix it.
Any help is welcome!
by Maquis196 on Thursday September 8th 2011, 19:13
1. Appdb is for Vanilla wine, it's used as a metric for the devs to see what breaks and what works between wine versions.
2. Appdb lets us users know what works because we want to use these apps/games.
1 is more important because the devs need to know what to fix. Vanilla wine simply doesn't play this game at the moment until raw event input is added. At time of writing, game can be as good as Silver, and if sound works for you, then game would Gold rating. It is that playable.
Bottom line, until we no longer need to patch wine, this game will be rated as garbage. :) Hope this clears it up for anyone wondering since the alternative would be to delete test results for not being vanilla wine and for me, 2 is more important. I want to know what games work :)
by MacNean on Wednesday September 14th 2011, 15:28
I almost left the page when I saw garbage not realizing it will actually work with patches.
You should change your stance and allow bronze rating at least with patches.
Dev's know what to fix. There are many many bug reports of this issue that have been consolidated into the 1 bug. Just look at the bug # has been marked as a duplicate. They know about this issue.
I believe your reasoning 1 is flawed, as many games have gone from working to not working in the DB after wine is upgraded, and answer is usually to use the old wine that worked before.
by Brian on Tuesday September 6th 2011, 23:48
But if it were, I'd be playing this game right now :)
To the point:
I downloaded and patched Wine 1.3.27, ./configure'd and make'd
...But then there's a gap in the howto.
Where do these D3D registry entries come from? Hopefully they aren't supposed to be there by default.. I don't have a Direct3d "folder" in my HKCU after creating the wine prefix
Should I winetricks directx? directx9? d3d? Or just create the necessary hierarchy and regedit away?
Will I need any winetricks at all? Particular version of nvidia drivers? Can I use 173xx or do I need 280xx?
Where is the part of the howto that tells how to get from step 1 to step 2?
For those that are also stuck at step 1.5, I found this link: wiki.winehq.org/UsefulRegistryKeys to be somewhat helpful as it explains where to find the howto's "wine settings..."
by Viktor Jackson on Tuesday September 6th 2011, 23:58
by Brian on Wednesday September 7th 2011, 0:01
UseGLSL->disabled
-or-
UseGLSL->"disabled"
by Maquis196 on Wednesday September 7th 2011, 6:58
If you needed more info then what was there, then maybe it might be easier playing it on Windows! For everyone else, you should kinda know how to do all that if you use wine at a level required to play this game.
All in all, your howto was good work, when I get back on my computer with a proper mouse I shall see what to incorporate. There is such a thing as making a howto too in-depth. If you don't know how to set a direct3d reg entry for wine, you would google it and learn how, why, etc.
As for your questions, the only thing that we know for certain is that you need to create the Direct3D key in regedit and then set those options above. all the other things you mentioned aren't required afawk, so they werent included in the brief howto :)
by Brian on Wednesday September 7th 2011, 12:51
It sounds like I've stepped on your toes and I apologize for creating those feelings; my intention was only to help new wine users run this software. With a rich text editor, I might have been able to write a more well-formed howto.
For what it's worth, it sounds like I should keep running *nix as I am obviously struggling to figure out the finer points of Windows :)
Hopefully when you go to update your howto (feel free to delete my posts afterward - they will no longer be necessary) you might consider modeling after some of these well-written wine howto's:
appdb.winehq.org/objectManager.php?sClass=version&iId=3775 #this is the original Deus Ex
appdb.winehq.org/objectManager.php?sClass=version&iId=13139
appdb.winehq.org/objectManager.php?sClass=version&iId=1554 #this one is short and poignant, but covers all possible bases for errors
Or even utilizing some of these resources on how to write a good Howto:
www.google.com/?q=how%20to%20write%20a%20howto
tldp.org/LDP/LDP-Author-Guide/html/index.html
Also, if you'd like a shell script that will automatically prepare wine and would work on many different Linuxes, I would have written one before you made that jackassy windows comment. However I'd be glad to write one for anyone else that needs one.
by Maquis196 on Wednesday September 7th 2011, 13:10
I didn't want to make it the final authority simply because this game is classed as garbage rating. I'll add another note for what you wrote since it is good work (like I said earlier).
I'll stand by my comment that if the mini howto is beyond some people's scope, they should either google/ask in comments what its about (like what a couple have asked below and i've gladly helped) or stick to something they already know and don't need to "hack" to get working.
I apologise if it came across as jackassy, it certainly wasn't my attention I assure you! - Maq
by Alexander on Wednesday September 7th 2011, 17:01
I still prefer starting my games with a script for the appropriate prefix.
That way it is easier to separate your custom wine builds and config/dlls/patches.
by Brian on Wednesday September 7th 2011, 21:10
To be honest, I felt like I was getting a bit on the in-depth side when I put in the uname -i (Heaven help if you don't know what arch your OS is :) and a couple of other things. Did you see my blunder, though? alias w=... Since I'm the only one ever logged in to my box, I totally forgot about /usr/bin/w
Really what I wanted to /not/ do was fail to mention something like aliasing wine (or starting it with the abs path) or write a howto that writes over the user's wine prefix if they are running dual wine's like I am now.
Also, I've been wondering if some of my slowness is actually a sound issue.. Wine 1.3.27 had an issue with my OSS sound drivers so I'm using ALSA with "full hardware acceleration" (that's another one of those windoze terms I'm not familiar with) and I was wondering if that might be contributing to the slowness. Any ideas (and is that why my sound is clicking)?
by Maquis196 on Thursday September 8th 2011, 3:36
As for your sound issues, that could be an idea. Sound is the only thing that misbehaves from my testing. I've seen it several seconds behind gameplay before (with firing my gun as the test). I've tried alsa with full sound emulation, it's worked and not worked. I'll have to do more testing. As always I can play more games whenever I can put eve online down (that game is crack)
by Mateusz Stachowski on Sunday September 11th 2011, 16:26
I've played about 2 or 3 hours with leaked build of DXHR and so far only the tutorials are very problematic. When watching tutorials no matter in-game or from the menu I get discontinuous sound. Everything other in regards to sound is perfect. It never was a second behind the gunfight or anything else.
If you want to get sound when using OSSv4 you need to disable vmix (from the ossxmix GUI) before starting the game and make sure that any other application isn't using sound.
by Chris on Sunday September 4th 2011, 16:38
My System GTS450, Quad Core 6600 and 2 GB Ram.
Played about 6 Hours and had just one crash. Its true that the graphic this way is not so nice, but i love to have a good fps during aiming.
Really hope that the Wine-Dev could more time investigate to bust this game. Maybe i will buy a new card for this. I had no glitches with higher settings, but the game is nearly unplayable slow.
by Maquis196 on Monday September 5th 2011, 3:45
by Andrea on Monday September 5th 2011, 10:52
no crash but not really playable. the slowdowns makes the mouse move too slowly ... impossible to aim in sone shootout, for example the first one at start.
I vote Bronze considering my pc and game requisites. On windows is just fine with mid settings.
i think we need to resolve the #27656 in a clean way to make it Silver or more.
by Maquis196 on Monday September 5th 2011, 11:19
Game is certainly silver for some people like myself, but bronze for others! Shame we don't have an out of 10 system for different parts of the game.
All this don't really matter short term anyway, anything more then garbage will get rejected officially :P
by Chris on Monday September 5th 2011, 12:47
I "vote" it bronze cause the game runs a bit slow on new hardware with nearly low settings. But myself it works fine. Got some Situations where it seems that the fps is 15-20 but mostly it playable with 30 or more frames. Aming works too here, but its nearly unplayable when there are flames or much smoke...
For Wineusers that are not so familiar with Patching wine, a playonlinux Script would be nice.
One thing that made me crazy is that i see the mouse-cursor in game. I launch this game from fluxbox.
by Nicole on Friday September 2nd 2011, 11:16
Even if I symlink Program Files to the directory where I have Steam installed the error doesn't disappear.
For Steam the path I use is C:\Program Files\Steam\Steam.exe, in reality it's on an extra disk I have for wine games.
The filesystem the game and steam are on is ext4. I can't really think of anything to try to fix this. Any ideas?
by Maquis196 on Friday September 2nd 2011, 11:28
mount --bind /mnt/disk2/steam /home/user/.wine/drive_c/steam
or something like that (based on your paths).
symlinks aren't great for doing things like that. Ext4 wont be an issue, I use it here. See how the above works and let me know
by Nicole on Friday September 2nd 2011, 12:09
by Nicole on Friday September 2nd 2011, 12:41
Now it crashes though, probably when enumerating audio devices or trying to access them so i'll go play around with the audio settings to get it to play nice.
by Nicole on Saturday September 3rd 2011, 3:50
Woohoo!
by bdell on Thursday September 1st 2011, 14:19
by Maquis196 on Thursday September 1st 2011, 15:06
I'll briefly touch on this because it is what it says on the tin, basically in the wine source directory (say /usr/src/wine-1.3.27) you just run;
./configure (which is a script in the directory) Once that is done you then just type in;
make
This compiles the program, make install actually installs it. you can run ./configure -h to see what options you can set with configure. For wine and this game I use;
./configure --prefix=/usr/local/wine-1.3.27rawevents (the --prefix sets where you install the program to).
Bottom line, these options above are good for a vast majority of open source programs. In every program you get the source code to (to compile yourself) you should have a README file. Check that out as well.
Hope this helps! Don't forget, for anything you come up against, google it. It really is your best friend.
by bdell on Friday September 2nd 2011, 9:54
by Alexander on Wednesday August 31st 2011, 13:52
Thanks for the devs for getting the game in a playable state so quickly.
my system:
e6600
nvidia 460gtx / 275.09.07
by Alexander on Sunday September 4th 2011, 12:14
It is bearable in indoor areas but outdoors gets worse, resolution doesn't seem to make any difference.
Also tried placing the game files on a ssd, no difference.
by carver cassanova on Wednesday August 31st 2011, 11:22
Any advice on what to do would be appreciated.
(Nvidia GTX 550 Ti with driver version 280.13)
(Linux Mint 9)
by carver cassanova on Wednesday August 31st 2011, 12:31
(wine version 1.3.27+rawinput patch)
by Maquis196 on Thursday September 1st 2011, 15:07
by moroz on Thursday September 8th 2011, 13:54
by moroz on Thursday September 8th 2011, 14:40
by Maquis196 on Thursday September 8th 2011, 14:42
I'm not sure we can even raise any bugs with this game whilst the two we currently have are up there. Fingers crossed the raw event patch makes it into wine. Otherwise this game may never get the support it needs.
by moroz on Thursday September 8th 2011, 14:52
by Vincas Miliūnas on Tuesday August 30th 2011, 13:49
Please use the latest version:
wget dl.dropbox.com/u/6901628/raw2.patch -O /tmp/raw2.patch
git apply /tmp/raw2.patch
./tools/make_requests
The game is still unplayable, because WINE stalls when looking at certain spots. The keyboard works, but mouse also almost doesn't, GPU usage drops to 0 as well.
by Maquis196 on Tuesday August 30th 2011, 14:33
Yeah I agree game is still unplayable, but least it looks good. With a working mouse the game would playable. It stalls for me as well but only for a very short time (I'm sure that would get annoying, but it would be worth overlooking compared to say installing windows on a machine that's never run it :S)
by Berillions on Tuesday August 30th 2011, 15:32
This patch doesn't work if i compile Wine 64Bits (Building WoW64 setup) but works with Wine 32 Bits :(
by Maquis196 on Tuesday August 30th 2011, 15:36
by Berillions on Tuesday August 30th 2011, 15:40
The game works fine but not the patch.
by Vincas Miliūnas on Tuesday August 30th 2011, 16:34
by Maquis196 on Tuesday August 30th 2011, 16:56
by Berillions on Tuesday August 30th 2011, 17:02
Keep the actual patch in your note, the Wine 64Bits users are few.
by Vincas Miliūnas on Tuesday August 30th 2011, 23:49
by Berillions on Wednesday August 31st 2011, 2:51
So, i tried raw3.patch and it does not works. The click mouse still doesn't work.
by Vincas Miliūnas on Wednesday August 31st 2011, 5:33
by Berillions on Friday September 2nd 2011, 14:08
I follow these commands to compile Wine 64 and Wine 32 :
Building a shared WoW64 setup
cd $HOME
mkdir wine64
cd wine64
../wine-git/configure --enable-win64 CC=/usr/local/gcc/bin/gcc
make > make.log 2>&1
cd ..
mkdir wine32
cd wine32
../wine-git/configure --with-wine64=../wine64
by Andrea on Wednesday August 31st 2011, 17:51
by Vincas Miliūnas on Sunday September 4th 2011, 9:12
Deus Ex uses Raw Input both for mouse and keyboard, there are problems with mouse, because WINE completely stalls (GPU usage drops and it stops sending mouse input messages) when looking at many spots in a game level.
However keyboard works for everyone, thus it's not related to the Raw Input patch, because it's just a simple service on top of WINE's input messaging.
by Andrea on Sunday September 4th 2011, 9:18
by Vincas Miliūnas on Sunday September 4th 2011, 9:31
I'm using X.Org X Server 1.8.2
by Andrea on Sunday September 4th 2011, 9:56
Can be related to high precision mouse (1000Hz) filling up the rawevent queue?
by Vincas Miliūnas on Sunday September 4th 2011, 10:14
You can use raw input logger to see if the version of WINE you're using is compiled with raw input at all:
Source code: dl.dropbox.com/u/6901628/raw-logger.c
Binary: dl.dropbox.com/u/6901628/raw-logger.exe
Run it in a terminal, then move mouse over the window, you'll see raw input events received logged in the terminal.
by Andrea on Sunday September 4th 2011, 10:33
Mouse: usFlags=0000, usButtonFlags=0000, usButtonData=0000, ulRawButtons=55550000, lLastX=00000001, lLastY=00000000, ulExtraInformation=00000000
Mouse: usFlags=0000, usButtonFlags=0000, usButtonData=0000, ulRawButtons=55550000, lLastX=00000002, lLastY=00000000, ulExtraInformation=00000000
Mouse: usFlags=0000, usButtonFlags=0000, usButtonData=0000, ulRawButtons=55550000, lLastX=00000001, lLastY=00000000, ulExtraInformation=00000000
Mouse: usFlags=0000, usButtonFlags=0000, usButtonData=0000, ulRawButtons=55550000, lLastX=00000002, lLastY=00000000, ulExtraInformation=00000000
Mouse: usFlags=0000, usButtonFlags=0000, usButtonData=0000, ulRawButtons=55550000, lLastX=00000004, lLastY=00000000, ulExtraInformation=00000000
Mouse: usFlags=0000, usButtonFlags=0000, usButtonData=0000, ulRawButtons=55550000, lLastX=00000008, lLastY=00000000, ulExtraInformation=00000000
Mouse: usFlags=0000, usButtonFlags=0000, usButtonData=0000, ulRawButtons=55550000, lLastX=00000004, lLastY=00000000, ulExtraInformation=00000000
Mouse: usFlags=0000, usButtonFlags=0000, usButtonData=0000, ulRawButtons=55550000, lLastX=00000008, lLastY=00000000, ulExtraInformation=00000000
by Vincas Miliūnas on Sunday September 4th 2011, 10:41
I checked now and I see that I can reproduce it myself using the 32bit part of WINE WoW64 build. Will look into it.
by Andrea on Sunday September 4th 2011, 10:47
by Vincas Miliūnas on Monday September 5th 2011, 10:28
Try this patch - dl.dropbox.com/u/6901628/raw3.patch
by Andrea on Saturday September 10th 2011, 7:27
I tested and works! Cheers :)
by Maquis196 on Tuesday August 30th 2011, 17:35
Every now and then the mouse somehow gets free from the screen im playing one but an esc to the menu and back again seems to restore it properly.
by Vincas Miliūnas on Tuesday August 30th 2011, 23:49
> Shall I always keep the note updated to the latest raw# patch that you mention?
No, raw2.patch is working very well on Wine32, this was just a test to see if the issue I found was the problem.
by Maquis196 on Wednesday August 31st 2011, 2:59
I'll try and keep an eye on exactly what causes it to get free, I just wish that steam bug wasn't present. It's quite distracting being able to see a cursor where there shouldn't be one.
by Andrea on Sunday September 4th 2011, 9:35
another solution is virtualdesktop=sameasyourresolution,no decorate, no grab pointer.
by Maquis196 on Monday September 5th 2011, 11:18
Just hoping we don't a situation where your very effective patch is forever considered a hack. Serious high five for your efforts dude, very much appreciated for your patch.
by Vincas Miliūnas on Monday September 5th 2011, 11:48
It's a big patch, over 100KB in size and over 2000 lines of code, there were some edge cases before and we found this new one in WoW64 environment.
I have a backlog of code-style changes (removal of trinary operators, etc) and it the future I will publish an updated version to wine-devel mailing list.
I am eager to develop this patch, but it will not reach mainline unless AJ gives it an another chance.
by Kevin Turner on Monday September 5th 2011, 13:07
Let us know if there's someplace we should track patch development, whether it's a github branch or in #20395. Maybe we can link to it from wiki:InterestingPatches. Thanks again for your work!
by Maquis196 on Monday September 5th 2011, 18:11
I would like to think that a patch with no known bugs that would make a flagship game like this playable would be a dealclincher. Between your patch and some reg tweaks, we virtually have this game playable. Not bad for a brand new game AAA title that's working almost out the box.
by Night Nord on Monday August 29th 2011, 15:15
make install
custom wine, as you may use /path/to/wine/build/directory/wine directly.
And, if you are using Gentoo Linux, you may just put required patches into /etc/portage/patches/app-emulation/wine/ and reemerge wine.
Also, note for ATI cards owners: fglrx has problems with multithreaded rendering and therefore has "proken pixels" even in menu screen.
Crystal Engine is optimized to use multithreaded rendering, so, I presume, you can't just disable it like in Source games.
FOSS drivers (git mesa, libdrm and xf86-video-ati with libtxc_dxtn installed) has no such bug, but FPS are _extremely_ low (1 frame per few seconds). I haven't played with video settings, though.
To maintainers: please, add requirement for video card and drivers version mention within any test - people always forgot to do this.
by Bobmadil_rocks on Tuesday January 31st 2012, 17:12
by Berillions on Monday August 29th 2011, 10:33
This bug is the main cause for the graphical glitches :
bugs.winehq.org/show_bug.cgi?id=27534
Stefan Dösinger has already added the patch which resolv this problem.
Enable strict draw rendering in Wine Regedit resolv this f*cking bug.
BUT, there is always the mouse bug :( even if i patch wine with the patch.
by Berillions on Monday August 29th 2011, 10:38
by Maquis196 on Monday August 29th 2011, 10:42
I made sure it was enabled and nothing changed for me! Could you post a picture of being outside the starting office?
by Berillions on Monday August 29th 2011, 10:48
But in Regedit in Direct3D, if i add :
strictdrawordering=disabled, i have graphical problem
strictdrawordering=enabled, i haven't graphical problem
This is a screen with strictdrawordering=enabled in Regedit :
pix.isalo.org/upload/original/1314632784.png
by Maquis196 on Monday August 29th 2011, 10:50
Could you start a game and see how it's rendered, I think thats where all of us have our issues :)
by Berillions on Monday August 29th 2011, 10:53
Because without patch wine, my mouse and keyboard doesn't work... :s
I build wine 1.3.27 with patch actually.
by Maquis196 on Monday August 29th 2011, 10:56
If it's still not working for input, it could be a desktop integration thing in winecfg? I also tried install directx9 from winetricks and that might have installed something.
by Viktor Jackson on Saturday August 27th 2011, 10:13
by Maquis196 on Saturday August 27th 2011, 11:00
loaddll tells me the game using dinput9, so maybe the native version is required?
by Viktor Jackson on Saturday August 27th 2011, 11:20
I'm going to try building 1.3.20 again. The first time I tried to run Human Revolution (using 1.3.20) I had no graphical errors in the main menu. I'm curious whether it will render the game properly as well.
by Maquis196 on Saturday August 27th 2011, 11:22
by Viktor Jackson on Saturday August 27th 2011, 11:47
by Viktor Jackson on Saturday August 27th 2011, 13:04
by Maquis196 on Saturday August 27th 2011, 13:11
How did you get it working without the patches though? for me it always crashes out when it cant create a raw event socket or whatever it's called
by Viktor Jackson on Saturday August 27th 2011, 13:33
by Maquis196 on Saturday August 27th 2011, 14:31
by Andrea on Sunday August 28th 2011, 10:06
I used instead bugs.winehq.org/attachment.cgi?id=35873 and compiles fine, i see the mouse moving but clicks on menù are not working.
Any ideas?
by Berillions on Monday August 29th 2011, 16:25
In wine 1.3.27 source, i did "patch -p1 < 35873.patch && ./tools/make_requests"
I installed the game in clean wineprefix. (Sorry but i use an illegal copy, shame on me)
I add StrictDrawOrdering=enabled in Wine Regedit (because i have graphical glitches in the menu)
Result =
The mouse click works for me but i have always the graphical glitches in game, like Maquis196.
by fbt on Thursday September 1st 2011, 13:19
For me it nearly feezes half of the time, can't aim :(
by Maquis196 on Thursday September 1st 2011, 15:10
There aren't any dll overrides that are in use. so hopefully it's just that. Let us know either way :)
by fbt on Thursday September 1st 2011, 23:41
UseGLSL = disabled, AlwaysOffScreen = enabled, StrictDrawOrdering = enabled
winver=win7, raw2.patch, Wine 1.3.27, ArchLinux
by fbt on Thursday September 1st 2011, 23:51
by Maquis196 on Friday September 2nd 2011, 4:18
For me the GLSL disabled seemed to fix that. What graphics card and drivers are you using?
Maybe it's something to do with that
by fbt on Saturday September 3rd 2011, 6:59
And it's not just SLOW, it's stuck. The enemies keep moving, I can move via the keyboard, but the mouse moves PAINFULLY slow and glitchy. One moment you could'nt move it at all and the second you are staring at the wall behind you.
Weird.
The specs are fairly old but the games itself seems to run pretty nice:
Nvidia 8800GTX, 4G RAM, Core 2 Duo E6600 (2.4GHz)
by fbt on Saturday September 3rd 2011, 7:12
If I use StrictDrawOrdering=disabled, I have sever graphical problems with the Menu/HUD, but no mouse problems!
Will investigate this further.
by fbt on Saturday September 3rd 2011, 7:04
by Andrea on Saturday August 27th 2011, 8:41
by Maquis196 on Saturday August 27th 2011, 8:47
by Maquis196 on Friday August 26th 2011, 12:48
In fact, if you talk to the woman, you are walked through the facility, and only parts of things are always visible like eye lashes but the gfx are fairly smooth. Weird.
Anyways, please vote for this app people! I'm hoping it will be popular enough to get some attention