WineHQ

Deus Ex: Human Revolution








Deus Ex: Human Revolution - update.

Version 1.1.622.0 released by Eidos Montreal, on 25 Aug, 2011.

Changelog for this patch:

General Fixes:

  • A frequent issue for AMD/ATI hardware users that can cause the game to crash on startup.
  • Improvements to loading speed. The speed increase depends on machine spec and settings, but loading time improvements of over 50% have been measured on some machines.

Control Fixes:

  • Diagonal movement is no longer faster as intended.
  • Adjustments have been made to mouse sensitivity in response to user feedback.
    • Mouse sensitivity for X and Y axis can still be configured separately, but is now consistent when set to default settings.
    • The range of settings for mouse sensitivity has been adjusted to provide for more accurate adjusting.
    • The default mouse sensitivity has been altered to be somewhat less sensitive.


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:

  • Resolves an issue that caused some users to be unable to start the game on specific machines. Specifically, the presence of older ATI/AMD drivers, also on machines with Nvidia hardware, would cause the game to crash on startup.
  • Increase the number of save-slots from 20, like on the PS3 and Xbox 360 versions, to 99.


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

Test Results

Old test results
The test results you have selected are very old and may not represent the current state of Wine.
Selected Test Results

What works

Everything in the game works. In some cases, lighting changes from light to darkish when moving the mouse, but this is a fairly rare occurrence. Shadows need to be disabled, because my experience is that they are glitchy at the moment in certain situations. Ie, the attack on Sarif HQ at the start of the game. In addition, the AlwaysOffScreen registry entry is required for graphics to work. Once enabled, the game is very playable. Also, setting the mousegrab option to enabled in winecfg is needed. I played this game on a fresh wineprefix, I don't think any prerequisite shenanigans with winetricks are required. The game is a bit demanding re: performance, but I have moderate anti aliasing (fxaa medium) ssao and 4x af.

What does not

Shadows must be disabled, and input from mouse/keyboard requires the raw input patch.

Workarounds

What was not tested

nothing in the game.

Hardware tested

Graphics:

  • GPU:
  • Driver:

Additional Comments

I used wine-git to get the latest stuff. Also, I don't understand why all the tests thus far are garbage or bronze. I'm having very little trouble at all. I will rate it as silver becuase of the source code patch requirement. Surprised that the game works this well despite all the appdb entries so far. I have noted some people posting comments, such as videos in the game not working. I have not had that problem at all. EDIT: Game is rated as garbage simply because it needs an unofficial patch before it will work properly. Appdb is for vanilla wine.

selected in Test Results table below
Operating systemTest dateWine versionInstalls?Runs?Used
Workaround?
RatingSubmitter
ShowSlackware64 -currentOct 01 20111.3.29Yes Yes GarbageZdenek Styblik 
ShowArch LinuxNov 18 20111.3.28No, but has workaround Yes Garbagean anonymous user 
ShowArch Linux x86_64Oct 02 20111.3.28Yes Yes GarbageTT 
ShowUbuntu 11.04 "Natty" amd64 (+ variants like Kubuntu)Sep 11 20111.3.28Yes Yes GarbageSamuel 
CurrentUbuntu 11.04 "Natty" amd64 (+ variants like Kubuntu)Sep 08 20111.3.27Yes Yes GarbageCaptainRedShirt 

Known Bugs

Bug # Description Status Resolution Other apps affected
6971 Mouse "escapes" window or is confined to an area in the full screen program CLOSED FIXED View
20395 Mouse / keyboard input not handled (RawInput) CLOSED FIXED View
27656 Deus Ex: Human Revolution - Severe graphical glitches CLOSED FIXED View
43363 Unable rotate mouse more than 180 degrees using Wayland (Deus Ex: HR, Max Payne 2) NEW View

Show open bugs

HowTo / Notes

Test Submissions ... how to avoid a rejection notice!!

These notes were last updated: 28 November 2017

Follow these guidelines to avoid embarrassment when your Test Submission is immediately rejected!!

  • Put your PC specifications in the Extra Comments section e.g. like your CPU and system memory.1
  • When adding test results please specify video card and driver version you are using.2
  • It's also useful to mention what Desktop Environment you are using (e.g. KDE/Plasma, Gnome, Xfce, Budgie, Mate, Cinnamon, ...)
  • Specify if you installed the Deus Ex: Human Revolution into a fresh Wineprefix (or not).
  • Specify what version of the Windows compatibility you use for your Wineprefix (e.g. Windows XP, Windows 7). Specify if you override this for the Deus Ex: Human Revolution executable.
  • Specify whether you installed into a 32-bit or a 64-bit Wineprefix.
  • Add detailed comments about what is not working for you.
  • Please indicate if your using Wine Staging and/or any additional patches applied - to the version of Wine you are using.
  • Please, don't submit test results like "Everything is working" or "Everything isn't working".

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:]]'

Known Issues

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.

Comments

The following comments are owned by whoever posted them. WineHQ is not responsible for what they say.

Corrupted Graphics
by FreakyCheeseMan on Saturday September 15th 2012, 14:24
Posting anew for this, as I got the earlier problem fixed.

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?
Moust Input/Graphical Corruption
by FreakyCheeseMan on Wednesday September 12th 2012, 10:17
So, I tried these instructions several times, with several variants- using wine 1.4 and rawinput3, uninstalling my original installation, etc. I pretty much always get the same results:

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...
RE: Moust Input/Graphical Corruption
by Maquis196 on Wednesday September 12th 2012, 10:33
From sounds of it you need the 32bit libraries on your box. Check out this document...

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
RE: Moust Input/Graphical Corruption
by FreakyCheeseMan on Wednesday September 12th 2012, 15:16
So, I may have done something dumb, but I'm not sure where.

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.
RE: Moust Input/Graphical Corruption
by Maquis196 on Wednesday September 12th 2012, 15:26
You went backwards into the 1.3 branch, id go forwards to the 1.5 (I believe rawinput works there as well).

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)
RE: Moust Input/Graphical Corruption
by FreakyCheeseMan on Wednesday September 12th 2012, 16:57
Okay, that allowed me to patch and install wine in /var/chroot/wine ; however, whenever I try to run anything with it, I get

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.
RE: Moust Input/Graphical Corruption
by Maquis196 on Wednesday September 12th 2012, 17:01
could always just delete the ~/.wine directory, next time you run wine after that it will create a new .wine directory.

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.
RE: Moust Input/Graphical Corruption
by FreakyCheeseMan on Wednesday September 12th 2012, 18:10
Alright- I was nervous about deleting the old file (since it took so many hours for Steam to download Deus Ex in the first place), but I got by with renaming it, and still referencing the old location when I ran Steam.

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.
RE: Moust Input/Graphical Corruption
by Maquis196 on Thursday September 13th 2012, 4:12
Well the good trick with steam games is to back them up through the steam interface, it can take a while with big games (but much quicker then downloading again in many cases).

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
RE: Moust Input/Graphical Corruption
by FreakyCheeseMan on Thursday September 13th 2012, 12:06
So, right now I have three different wine prefixes floating around, and two different versions of wine.


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.
RE: Moust Input/Graphical Corruption
by FreakyCheeseMan on Thursday September 13th 2012, 12:49
Update- I can launch the cope of Deus Ex installed to the chroot if I call its executable directly from the terminal, rather than trying to launch it through wine. However, it's still slow and refuses to load textures.

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.
Freez on tuto video
by Thomas L on Wednesday September 21st 2011, 3:50
The game work correctly but the game freez when it ask me to load tutorial video. (after maintaining tab)
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
RE: Freez on tuto video
by Tiago Domingues on Sunday October 2nd 2011, 17:09
Yes to me it happens to, the tutorial video works, but the sound is laggy.

No solution regarding that...
Wine-1.3.27 ebuild with raw2.patch for Gentoo
by Galym Kerimbekov on Tuesday September 20th 2011, 6:56
Wine-1.3.27 ebuild with raw2.patch for Gentoo
depositfiles.com/files/rcknngusd
double mouse pointer + 180degrees rotation OR no save games :(
by David on Monday September 19th 2011, 14:06
I am still having the problem that I see the double mouse pointer (ingame + X11 pointer) when steam.exe is still running
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
RE: double mouse pointer + 180degrees rotation OR no save games :(
by David on Monday September 19th 2011, 14:08
Harrr "# wget dl.dropbox.com/u/6901628/raw2.patch -O /tmp/raw2.patch"

should just be

"# wget dl.dropbox.com/u/6901628/raw2.patch"
RE: double mouse pointer + 180degrees rotation OR no save games :(
by Kevin Turner on Monday September 19th 2011, 15:42
double-mouse-pointer under steam is something that I've just been putting up with; by itself it's a little annoying but doesn't make the game unplayable for me. (See also bugs.winehq.org/show_bug.cgi?id=27779 )

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).
RE: double mouse pointer + 180degrees rotation OR no save games :(
by David on Tuesday October 4th 2011, 13:38
First of all, thanks a lot for your reply and thoughts :D

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 :(
Graphic Corruption with Above Fixes
by Rob on Sunday September 18th 2011, 12:04
I'm still experiencing the graphics corruption even after implementing the fixes listed above, whether I set them or not there seems to be no difference in the display. Anyone have any insights as to what I might be doing wrong or anything else I could try?

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
RE: Graphic Corruption with Above Fixes
by Mateusz Stachowski on Sunday September 18th 2011, 13:51
Could you please add information regarding which version of Wine is in use here. I'm asking this because as far as I know the "AlwaysOffScreen" option was introduced with the release of 1.3.27 so if you running it on something older than that it will not work.
RE: Graphic Corruption with Above Fixes
by Rob on Sunday September 18th 2011, 16:16
Sorry, I should have included that! I'm running 1.3.27 with the patch, no other changes.
RE: Graphic Corruption with Above Fixes
by Mateusz Stachowski on Sunday September 18th 2011, 16:55
Maybe you should also add information about your graphics card to Wine Registry like that:

[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.
RE: Graphic Corruption with Above Fixes
by Rob on Sunday September 18th 2011, 22:02
I'm running 280.13 which shows as the latest stable on Nvidia's website.

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.
RE: Graphic Corruption with Above Fixes
by Rob on Friday September 23rd 2011, 1:01
Adding the PCI IDs had no obvious effect. Infact, none of the keys seem to make any difference at all, good or bad.
RE: Graphic Corruption with Above Fixes
by Mateusz Stachowski on Friday September 23rd 2011, 12:31
I'm sorry but I don't know what else you could do to get rid of graphical errors in DXHR. The only thing that comes to mine mind is disabling of the post-processing effects. You will find that option in advanced graphical settings of the game. It worked for me even before the "AlwaysOffScreen="enabled" making the rendering almost glitch free.

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.
RE: Graphic Corruption with Above Fixes
by Rob on Friday November 11th 2011, 22:10
My Graphics corruption was solved when I upgraded to Nvidia 285.05.09!
Can't find language data
by dhasenan on Thursday September 15th 2011, 23:55
I'm getting an error that says "Can't find language data" when I try running Deus Ex. Not sure what that's about. I'm able to run other steam games, though.
RE: Can't find language data
by dhasenan on Friday September 16th 2011, 9:59
I was able to load up a copy scp'd from my window machine. Runs okay (low framerate and lag, but what do you expect?).

I think it runs better if you don't use a compositing window manager. Not sure, though.
RE: Can't find language data
by Thomas L on Friday September 23rd 2011, 12:10
try to lauch your app from the original Deus Ex folder :
$ pwd
/home/albert/.wine/drive_c/Program Files/Square Enix/Deus Ex - Human Revolution
$/var/wine/wine-1.3.27/wine dxhr.exe
New test data
by Brian on Thursday September 15th 2011, 9:10
So... Newegg had some good deals on RAM so I picked up 16 gigs.

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.
RE: New test data
by Zdenek Styblik on Monday September 26th 2011, 13:16
Hello,

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!
Test result ratings
by Maquis196 on Thursday September 8th 2011, 19:13
Just wanted to publicly tell everyone what's up with the ratings, basically as super I'm between a rock and a hard place on this one;

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 :)
RE: Test result ratings
by MacNean on Wednesday September 14th 2011, 15:28
I think this is the wrong way to look at this. Look at the many games in the Wine DB, tons are rated bronze/silver even when needed patches/extra things.

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.
Howto for Slow Kids
by Brian on Tuesday September 6th 2011, 23:48
Sorry, this isn't actually a howto for slow people.

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..."
RE: Howto for Slow Kids
by Viktor Jackson on Tuesday September 6th 2011, 23:58
You can quite safely create the keys and values with regedit. If you don't, default values (which don't work) will be used. I did winetricks d3dx9_??, but I believe it works just as well with the builtin libraries.
RE: Howto for Slow Kids
by Brian on Wednesday September 7th 2011, 0:01
Also, should the values be like:

UseGLSL->disabled
-or-
UseGLSL->"disabled"
RE: Howto for Slow Kids
by Maquis196 on Wednesday September 7th 2011, 6:58
It was just a brief howto to enable people just getting the game to know what settings/patches do the job to enable you to play it.

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 :)
RE: Howto for Slow Kids
by Brian on Wednesday September 7th 2011, 12:51
Marquis196,

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.
RE: Howto for Slow Kids
by Maquis196 on Wednesday September 7th 2011, 13:10
No toes were stepped on I assure you, I'm only here to help, it's not like any of my work is being criticised. My very short n sweet howto was just a "one stop shop" if you will for people to get the game running back when everything we tried was something new, etc.

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
RE: Howto for Slow Kids
by Alexander on Wednesday September 7th 2011, 17:01
To be honest I find the how to in depth too, still appreciate your effort.

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.
RE: Howto for Slow Kids
by Brian on Wednesday September 7th 2011, 21:10
I was just kidding about the jackassy part!!!! Sarcasm doesn't come across the internet well - should have added a ":)" - my bad. I'd love to do anything I can to help out because the Deus Ex series are some of my favorite games.

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)?
RE: Howto for Slow Kids
by Maquis196 on Thursday September 8th 2011, 3:36
Ha, emotion in general is hard through txt, sarcasm defo worse so :). I swear most of most txt msgs include a smiley to convey extra information!

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)
RE: Howto for Slow Kids
by Mateusz Stachowski on Sunday September 11th 2011, 16:26
I wonder if the OSS that you refer to is only setting in your wine or the sound system in use by the whole system. I mean are you using Open Sound System (currently OSS-v4.2-build2005) because I do. No PulseAudio or ALSA in my Ubuntu 11.04 Natty Narwhal.

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.
Got Slowdowns too but..
by Chris on Sunday September 4th 2011, 16:38
..with disabled shadow and blur the game is playable. Would give it the Rating bronze.

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.
RE: Got Slowdowns too but..
by Maquis196 on Monday September 5th 2011, 3:45
Ah, this bronze with the raw-input patch? It's a shame we can't use vanilla wine for this. Almost pointless putting on test results, someone actually posted some but it was rejected by the appdb team for not being vanilla wine.
RE: Got Slowdowns too but..
by Andrea on Monday September 5th 2011, 10:52
i5 520M, GT330M, 4GRam, 1920x1080

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.
RE: Got Slowdowns too but..
by Maquis196 on Monday September 5th 2011, 11:19
It does seem everyone is in either 2 camps, myself and the other submitter seemed to only have issues with in game tutorials. Yourself and others have complained about slow downs to make it bronze.

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
RE: Got Slowdowns too but..
by Chris on Monday September 5th 2011, 12:47
Its ok that this game got bronze cause oft some extra Patching is needed. But myself don't care much about this rating.

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.
Incomplete installation (2)
by Nicole on Friday September 2nd 2011, 11:16
I have an issue with this game (and others) where I get the incomplete installation (2) error.

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?
RE: Incomplete installation (2)
by Maquis196 on Friday September 2nd 2011, 11:28
Instead of symlinks can you try a bind mount?

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
RE: Incomplete installation (2)
by Nicole on Friday September 2nd 2011, 12:09
I'll give it a go later on. Thanks for the idea!
RE: Incomplete installation (2)
by Nicole on Friday September 2nd 2011, 12:41
I tried your suggestion. It seems to work. Thanks for that.

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.
RE: Incomplete installation (2)
by Nicole on Saturday September 3rd 2011, 3:50
The crash was due to the patch not being applied properly. Re-applying it and recompiling fixed it.
Woohoo!
Elaboration in the current how to?
by bdell on Thursday September 1st 2011, 14:19
I am new to linux and wine, and as such I was wondering if you could elaborate on the "usual configure, make, make" portion of the current (9/1/2011) how to section.
RE: Elaboration in the current how to?
by Maquis196 on Thursday September 1st 2011, 15:06
Welcome to Linux :).

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.
RE: Elaboration in the current how to?
by bdell on Friday September 2nd 2011, 9:54
Thanks for the clarification. I guess this is why everyone loves linux. Its easy to troubleshoot and if you really need help, you can just google it, lol.
slowdown
by Alexander on Wednesday August 31st 2011, 13:52
After patching wine and applying the fixes I got the game working alright. I experience some slowdowns after loading the game, but these go by very quickly and the game runs fine.

Thanks for the devs for getting the game in a playable state so quickly.

my system:
e6600
nvidia 460gtx / 275.09.07
RE: slowdown
by Alexander on Sunday September 4th 2011, 12:14
I played some more, seems these slowdowns occur not only after loading, but evertime a new area is needed.
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.
Black screen after opening credits
by carver cassanova on Wednesday August 31st 2011, 11:22
Following the tips here I was able to get the game running, BUT I can only play the game up to the opening credits. Once the video ends I just get a black screen, some music and noway to continue.

Any advice on what to do would be appreciated.

(Nvidia GTX 550 Ti with driver version 280.13)
(Linux Mint 9)
RE: Black screen after opening credits
by carver cassanova on Wednesday August 31st 2011, 12:31
I just got past this error by setting wine to Windows 7, but doing so made some bad lag spikes, this was countered by changing wine back to XP once I was past.

(wine version 1.3.27+rawinput patch)
RE: Black screen after opening credits
by Maquis196 on Thursday September 1st 2011, 15:07
I run mine permanently in Windows 7 mode. No slow downs that I've seen so far, although I know of which you speak though, used to get them before turning off GLSL.
RE: Black screen after opening credits
by moroz on Thursday September 8th 2011, 13:54
Have same problem(black screen) after first ingame action(walk with a girl). Don`t know what to do. I tried both XP and 7 mode and different driver versions(275,280,285).
RE: Black screen after opening credits
by moroz on Thursday September 8th 2011, 14:40
Ok, it`s random hang up on cinematics :(
RE: Black screen after opening credits
by Maquis196 on Thursday September 8th 2011, 14:42
Well keep in mind this game has a garbage rating wink wink ;-).

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.
RE: Black screen after opening credits
by moroz on Thursday September 8th 2011, 14:52
Oooh. It`s 100% black screen on first watch any cinematics :E

by Vincas Miliūnas on Tuesday August 30th 2011, 13:49
Why does "HOWTO - Patch wine for raw input" contain ancient links form wine-devel mailing list?
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.
RE:
by Maquis196 on Tuesday August 30th 2011, 14:33
The ancient details were the ones I had that actually worked, I've updated the note with the new details. So cheers for that!

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)
RE:
by Berillions on Tuesday August 30th 2011, 15:32
Damn !!!
This patch doesn't work if i compile Wine 64Bits (Building WoW64 setup) but works with Wine 32 Bits :(
RE:
by Maquis196 on Tuesday August 30th 2011, 15:36
I'd expect that, why are you using wow64? thought that was more for testing then anything useful at this point?
RE:
by Berillions on Tuesday August 30th 2011, 15:40
All my games works with wine 64Bits so i tried with Deus Ex HR.
The game works fine but not the patch.
RE:
by Vincas Miliūnas on Tuesday August 30th 2011, 16:34
Very weird issue, the patch is working correctly, but the source of the crash seems to be a (LRESULT)-1 conversion, replaced it with a(UINT)-1 one, now it should work - dl.dropbox.com/u/6901628/raw3.patch
RE:
by Maquis196 on Tuesday August 30th 2011, 16:56
Shall I always keep the note updated to the latest raw# patch that you mention?
RE:
by Berillions on Tuesday August 30th 2011, 17:02
This patch is for Wine 64Bits.
Keep the actual patch in your note, the Wine 64Bits users are few.
RE:
by Vincas Miliūnas on Tuesday August 30th 2011, 23:49
So does raw3.patch for you on Wine64, or not?
RE:
by Berillions on Wednesday August 31st 2011, 2:51
Hi Vincas,

So, i tried raw3.patch and it does not works. The click mouse still doesn't work.
RE:
by Vincas Miliūnas on Wednesday August 31st 2011, 5:33
First of all Wine64 will not run 32bit executables (including this game), for that you need a separately compiled Wine32. Therefore, if you are eager to use wine64, you must maintain two wine compilations and rebuild them after each change, as is described in the Wine64 wiki page - wiki.winehq.org/Wine64 . Is that correct from you experience?
RE:
by Berillions on Friday September 2nd 2011, 14:08
I compile correctly my Wine64.
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
RE:
by Andrea on Wednesday August 31st 2011, 17:51
i've the same problem in a win32 prefix.
RE:
by Vincas Miliūnas on Sunday September 4th 2011, 9:12
A guy in a post below wrote about it - appdb.winehq.org/commentview.php?iAppId=13150&iVersionId=24271&iThreadId=71597

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.
RE:
by Andrea on Sunday September 4th 2011, 9:18
can be related to XInput/Xorg/Xserver version?
RE:
by Vincas Miliūnas on Sunday September 4th 2011, 9:31
I do not know, but the fact is that the XInput2 extension should be installed and used by WINE.

I'm using X.Org X Server 1.8.2
RE:
by Andrea on Sunday September 4th 2011, 9:56
i don't know if keyboard is supposed to work in menù but mine doesn't. neither the StrictOrder=disabled.

Can be related to high precision mouse (1000Hz) filling up the rawevent queue?
RE:
by Vincas Miliūnas on Sunday September 4th 2011, 10:14
It doesn't matter, raw input messages are sent only when mouse cursor changes it's position on the screen.

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.
RE:
by Andrea on Sunday September 4th 2011, 10:33
this are the log for 2 left clicks and 2 right clicks. Do they seems ok?

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
RE:
by Vincas Miliūnas on Sunday September 4th 2011, 10:41
No, they are incorrect, there is some alignment issue with data structures.

I checked now and I see that I can reproduce it myself using the 32bit part of WINE WoW64 build. Will look into it.
RE:
by Andrea on Sunday September 4th 2011, 10:47
Thanks man, much appreciated.
RE:
by Vincas Miliūnas on Monday September 5th 2011, 10:28
When I developed the patch I was not aware that client and wineserver can have asymmetric architectures (32bit client using 64bit server). That makes some of the data structures hard to exchange properly. I've added support for the server part of the patch to recognize a 32bit client and modify the event data structures to be compatible with what a client program expects.

Try this patch - dl.dropbox.com/u/6901628/raw3.patch
RE:
by Andrea on Saturday September 10th 2011, 7:27
Sorry for the long wait...

I tested and works! Cheers :)
RE:
by Maquis196 on Tuesday August 30th 2011, 17:35
It seems in full screen with full screen mouse capture enabled the game works perfectly (see additional notes on my last test data). The only issue mouse wise is the bug with steam where the system cursor is visible.

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.
RE:
by Vincas Miliūnas on Tuesday August 30th 2011, 23:49
Open winecfg, then the Graphics tab and select the "Automatically capture the mouse in full-screen windows" checkbox.

> 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.
RE:
by Maquis196 on Wednesday August 31st 2011, 2:59
I have that option set, it's rare that it happens but the mouse gets lose lol.

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.
RE:
by Andrea on Sunday September 4th 2011, 9:35
afaik you can kill steam.exe after launching the game to remove the problem.

another solution is virtualdesktop=sameasyourresolution,no decorate, no grab pointer.
RE:
by Maquis196 on Monday September 5th 2011, 11:18
Not being a dev I don't know what the process is, but do you know of your chances of getting your patch into next release of wine (or one after?).

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.
RE:
by Vincas Miliūnas on Monday September 5th 2011, 11:48
Well, Alexandre Julliard is the sole committer for WINE, he gave feedback on a single patch (the full set is ~20 patches), I submitted changes based on his feedback. However 10 days later I asked him will he review it, he replied that he will not, because it looks hopeless for him due to the amount of updates I have submitted. Of course my too frequent submissions (I was incorporating feedback from WINE developers and adding new features) were quite backwards, so I need to be punished for that.

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.
RE:rawinput patch development
by Kevin Turner on Monday September 5th 2011, 13:07
Yow, that's rough. You never want to "punish" contributors but a 100 kB patch is very difficult to review and integrate all at once.

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!
RE:
by Maquis196 on Monday September 5th 2011, 18:11
Yeah, I imagine he's fairly reasonable, just doesn't like to go over old work like most maintainers on an open-source project (if you're not being paid for it, your time is uber precious!)

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
Just a note here: you don't need to
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.
RE:
by Bobmadil_rocks on Tuesday January 31st 2012, 17:12
Thanks for the trick about /etc/portage/patches/ap-emulation/wine. THat will help immensly.
[Graphic problem]
by Berillions on Monday August 29th 2011, 10:33
I found where come from the graphic problem.
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.
RE: [Graphic problem]
by Berillions on Monday August 29th 2011, 10:38
I add that i use this option with a clean wine 1.3.27 without patch.
RE: [Graphic problem]
by Maquis196 on Monday August 29th 2011, 10:42
Isn't strictdrawordering enabled by default?

I made sure it was enabled and nothing changed for me! Could you post a picture of being outside the starting office?
RE: [Graphic problem]
by Berillions on Monday August 29th 2011, 10:48
I know but it's very strange. In winetricks, strictdrawordering is enabled bu default.

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
RE: [Graphic problem]
by Maquis196 on Monday August 29th 2011, 10:50
Ah that explains it... The menu has always rendered perfectly for me (see the pic I posted in images), it's the game itself that has the errors.

Could you start a game and see how it's rendered, I think thats where all of us have our issues :)
RE: [Graphic problem]
by Berillions on Monday August 29th 2011, 10:53
Ok but you use the keyboard to enter in game ?
Because without patch wine, my mouse and keyboard doesn't work... :s

I build wine 1.3.27 with patch actually.
RE: [Graphic problem]
by Maquis196 on Monday August 29th 2011, 10:56
Ah, the game works for me input wise (although no chance you could play it with how the mouse works), I used 1.3.27 and the patches I posted above.

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.
Can't get raw input working
by Viktor Jackson on Saturday August 27th 2011, 10:13
Tried to get raw input working with 1.3.20, 1.3.23 and 1.3.26. They all compile fine with the patches, but I still can't click on the menu items when the game loads up. Could it be that I'm using git rather than downloading tarballs? Am I missing something? (Applied patches, run tools/make_request, compiled, run DXHR... no dice).
RE: Can't get raw input working
by Maquis196 on Saturday August 27th 2011, 11:00
I did use winetricks directx9. See if that fixes your issue (if it does then I'll add it to the notes section)

loaddll tells me the game using dinput9, so maybe the native version is required?
RE: Can't get raw input working
by Viktor Jackson on Saturday August 27th 2011, 11:20
I answered my own question it seems. Compiling 1.3.26 from tarball made input work. The game runs on builtin dx9, with the same graphical errors as seen in the screenshots.

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.
RE: Can't get raw input working
by Maquis196 on Saturday August 27th 2011, 11:22
Didn't I read in that raw event bug report that only 1.3.23 had an interface to talk to a raw event. So earlier then that it won't work? If the game still starts that would be win I guess. Least we'd know which commit changed it!
RE: Can't get raw input working
by Viktor Jackson on Saturday August 27th 2011, 11:47
It seems you might be right there. Building 1.3.20 with the raw event patches failed with a load of undeclared variables pertaining to mouse functions... Trying 1.3.23 now.
RE: Can't get raw input working
by Viktor Jackson on Saturday August 27th 2011, 13:04
Confirmed, 1.3.20 renders the menu flawlessly, but the raw event patches don't work.
RE: Can't get raw input working
by Maquis196 on Saturday August 27th 2011, 13:11
The menu? Menu is rendered perfectly for me as well, it's the game itself I'm more concerned about :P.

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
RE: Can't get raw input working
by Viktor Jackson on Saturday August 27th 2011, 13:33
For me, it loads without the patches with all versions prior to 1.3.26 (I think). Versions after 1.3.20 have graphical errors in the main menu, I thought these might be related to those in-game. (GPU: nVidia GeForce GTS450 with official drivers)
RE: Can't get raw input working
by Maquis196 on Saturday August 27th 2011, 14:31
Ah, it never loaded for me, but then my menu works fine :P. Still, we're getting some votes though and hopefully a dev or two has this game and wants to fix it. Keep in mind as well though that the Monday's after a release are bug fixing days, heres hoping for a silver rating soon :)
RE: Can't get raw input working
by Andrea on Sunday August 28th 2011, 10:06
neither i can. i tried using the suggested patches but it end up not compiling in .27
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?
RE: Can't get raw input working
by Berillions on Monday August 29th 2011, 16:25
I compile wine 1.3.27 with this patch : bugs.winehq.org/attachment.cgi?id=35873

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.
RE: Can't get raw input working
by fbt on Thursday September 1st 2011, 13:19
Do you have mouse 'stuttering' sometimes?
For me it nearly feezes half of the time, can't aim :(
RE: Can't get raw input working
by Maquis196 on Thursday September 1st 2011, 15:10
Can you make sure that Automatically capture the mouse in full-screen windows is on in the graphics tab in winecfg?

There aren't any dll overrides that are in use. so hopefully it's just that. Let us know either way :)
RE: Can't get raw input working
by fbt on Thursday September 1st 2011, 23:41
Yep, the option is on and no dll overrides.

UseGLSL = disabled, AlwaysOffScreen = enabled, StrictDrawOrdering = enabled
winver=win7, raw2.patch, Wine 1.3.27, ArchLinux
RE: Can't get raw input working
by fbt on Thursday September 1st 2011, 23:51
Just tried a separate X session for the game. Same problem.
RE: Can't get raw input working
by Maquis196 on Friday September 2nd 2011, 4:18
When you say the mouse freezes? what about the game itself? I used to experience dramatic game slow downs every few seconds in some areas.

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
RE: Can't get raw input working
by fbt on Saturday September 3rd 2011, 6:59
The gane is slow, but not as slow as the mouse input.
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)
RE: Can't get raw input working
by fbt on Saturday September 3rd 2011, 7:12
Ha! Found something.

If I use StrictDrawOrdering=disabled, I have sever graphical problems with the Menu/HUD, but no mouse problems!
Will investigate this further.
RE: Can't get raw input working
by fbt on Saturday September 3rd 2011, 7:04
Ah, the drivers: nvidia 280.13-1
howto correction
by Andrea on Saturday August 27th 2011, 8:41
please correct wget commands to use -O (capital o).
RE: howto correction
by Maquis196 on Saturday August 27th 2011, 8:47
Good catch, cheers!
New Game Pic
by Maquis196 on Friday August 26th 2011, 12:48
Is what you will see when you first start a game, you walk anywhere and instantly the image becomes the gfx error pic.

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
Back