It seems that you're using an outdated browser. Some things may not work as they should (or don't work at all).
We suggest you upgrade newer and better browser like: Chrome, Firefox, Internet Explorer or Opera

×
avatar
JudasIscariot: Well it would mean having to move from my compiled Wine to git and all that.

Personally speaking, I am going to either wait until Mint 18 comes out or just switch to an Ubuntu flavor so I can have updated Wine development libraries.
Why not use PlayOnLinux?
avatar
JudasIscariot: Well it would mean having to move from my compiled Wine to git and all that.
Well, no. It would just dirty your source tree with the staging patches. Assuming you are using tarballs then you would just delete the source tree, and re-extract from the tarball to revert to a vanilla build. Don't you regularly do this when updating anyway? Plus, what they ^ said.
Post edited February 16, 2016 by Gydion
avatar
JudasIscariot: Well it would mean having to move from my compiled Wine to git and all that.

Personally speaking, I am going to either wait until Mint 18 comes out or just switch to an Ubuntu flavor so I can have updated Wine development libraries.
avatar
adamhm: Why not use PlayOnLinux?
I never have success with it, maybe I am just not smart enough for PoL. Found it easier to just compile my Wine and I almost never have the need to use different Wine versions because a) I either get the game working to my satisfaction or b) the games I want to play end up having Linux versions anyways :)

I also don't use PoL because winehq.org will NOT take bug reports if you use Play on Linux and since I want to file bug reports or confirm that a given bug continues to exist in the latest version of WIne, I just compile it.
avatar
JudasIscariot: Well it would mean having to move from my compiled Wine to git and all that.
avatar
Gydion: Well, no. It would just dirty your source tree with the staging patches. Assuming you are using tarballs then you would just delete the source tree, and re-extract from the tarball to revert to a vanilla build. Don't you regularly do this when updating anyway? Plus, what they ^ said.
Whenever a new version comes out I make sure to remove the old source version before compiling :) I may not be smart but I know enough to do that much :)
Post edited February 16, 2016 by JudasIscariot
avatar
JudasIscariot: Whenever a new version comes out I make sure to remove the old source version before compiling :) I may not be smart but I know enough to do that much :)
Right, so it's effectively that one extra step. You don't even need git to download the wine-staging source: But if you don't need a staging build then you don't need one. :p I'm with you with POL. I've had better luck with builds I've done myself.
avatar
JudasIscariot: Whenever a new version comes out I make sure to remove the old source version before compiling :) I may not be smart but I know enough to do that much :)
avatar
Gydion: Right, so it's effectively that one extra step. You don't even need git to download the wine-staging source:
avatar
Gydion: But if you don't need a staging build then you don't need one. :p I'm with you with POL. I've had better luck with builds I've done myself.
Like I said, I've had a pretty good run with source versions so far. I mean I can play Darkest Dungeon (the occasional sound stutter can be annoying but I hope it goes away once I get proper pulse support in WIne :P) and I am happy with that :)

Never been a perfectionist when it comes to WINE so I try to advocate that people tweak things how they wish and kind of use what little bit I know as a mere guideline and not a be-all-end-all kind of thing :)
avatar
JudasIscariot: Never been a perfectionist when it comes to WINE so I try to advocate that people tweak things how they wish and kind of use what little bit I know as a mere guideline and not a be-all-end-all kind of thing :)
I've read this a few times and I admit I'm a bit lost. Regardless, I agree with the conclusion, but then again I'm not sure who wouldn't? Tweak as you want/desire.
Game: Risen
Installer MD5: eb818eae98564ceb0dcfbb3fba5ad272 setup_risen_2.0.0.6.exe
WineHQ AppDB link: https://appdb.winehq.org/objectManager.php?sClass=application&iId=10408
CodeWeavers link: https://www.codeweavers.com/compatibility/crossover/risen

Distro: Linux Mint 17.3 Cinnamon 64bit
Kernel version: 3.19.0-47
Graphics card: Nvidia GeForce GTX 750Ti
Graphics driver & version: Proprietary 361.28
Wine version(s) tested: Wine Staging 1.9.3 via PlayOnLinux, CrossOver 15.0.1

Install notes: Requires d3dx9 (install DirectX 9 Modern in CrossOver)
If using PlayOnLinux, run the game from/create a shortcut for "Risen.exe"
How well does it run: Very well
Details: Have not played much yet but it appears to work perfectly fine from what I've played so far, aside from the logos when you start the game not being displayed. Tested at 1920x1200 with virtual desktop and CSMT enabled. If running the game with virtual desktop enabled, you must also set "Automatically capture the mouse in full-screen windows".
So.

I am testing out Ubuntu 15.10 and trying to compile Wine 1.9.4 with Pulse Audio support. I have the 32-bit version of libpulse-dev installed and yet ./configure continues to claim that the 32-bit libpulse development libraries are not installed.

Anyone know why WIne won't see libpulse-dev:i386? How do I force it to acknowledge that I have the proper development files installed?
avatar
JudasIscariot: Anyone know why WIne won't see libpulse-dev:i386? How do I force it to acknowledge that I have the proper development files installed?
Actually ./configure claims "development files not found or too old,". I'm guessing you have "yes" for all three pulse checks? I now have the impression that you don't need a terribly new version of pulse to compile this. You likely are failing the other check (Fix the libpulse check for when the library exists but doesn't work.) No real idea why it "doesn't work". Possibly an arch related issue? Might be worthwhile to see if it compiles correctly in a 32-bit container. The way we are compiling it now isn't technically an officially supported method.
Post edited February 22, 2016 by Gydion
Divine Divinity
Debian Sid amd64
Kernel: 4.5.0-rc4-powerplay x86_64 (custom build)
Card: AMD Radeon R9 380X
OpenGL Renderer: Gallium 0.4 on AMD TONGA (DRM 3.1.0, LLVM 3.7.1)
OpenGL Version: 4.1 (Core Profile) Mesa 11.1.2
installers:
setup_divine_divinity_2.0.0.21.exe (MD5: 3798d48f04a7a8444fd9f4c32b75b41d)
setup_divine_divinity_french_2.1.0.32.exe (MD5: f755d69ad7d319fb70298844dcb3861a)

WINE version: 1.8.1
WINEHQ AppDB entry: https://appdb.winehq.org/objectManager.php?sClass=version&iId=18392
avatar
JudasIscariot: Anyone know why WIne won't see libpulse-dev:i386? How do I force it to acknowledge that I have the proper development files installed?
avatar
Gydion: Actually ./configure claims "development files not found or too old,". I'm guessing you have "yes" for all three pulse checks? I now have the impression that you don't need a terribly new version of pulse to compile this. You likely are failing the other check (Fix the libpulse check for when the library exists but doesn't work.) No real idea why it "doesn't work". Possibly an arch related issue? Might be worthwhile to see if it compiles correctly in a 32-bit container. The way we are compiling it now isn't technically an officially supported method.
Well, configure sees pulse.h (I'll post a configure.log later), I have libpulse0 and libpulse-dev 32-bit libs installed and Wine 1.9.4's ./configure says "No, you do not have anything!" hence my confusion.

Will that patch that you posted conflict with Wine 1.9.4?
avatar
JudasIscariot: Will that patch that you posted conflict with Wine 1.9.4?
Not at all as it was applied the day after the initial pulse patch. It's already in Wine 1.9.4. It's failing as the PULSE_LIBS variable is empty. If I knew how to read a configure file I might know why. As I don't I'm guessing it's a 32-bit on 64-bit issue (not to mention that's the usual culprit). PULSE_LIBS is the linker flags; random searching later and configure completes. Let me see if it compiles...

It did! Failed on install though. This however seems to work:
./configure --with-pulse --disable-tests "PULSE_CFLAGS=-lpulse" "PULSE_LIBS=-lpulse" --prefix="$HOME/sommelier/pulse-wine-1.9.4"
Left out the -lpulse first time around and skip the -m32.
Post edited February 24, 2016 by Gydion
Game: Banished
Install media: 694d75da86bf146eb2f766215129e9f30138cae7 setup_banished_2.3.0.7.exe

Distro: Linux Mint 17.3 Rosa Desktop: Cinnamon 2.8.6
Kernel: 3.19.0-32-generic i686 (32 bit)

GLX Renderer: GeForce GT 240/PCIe/SSE2
GLX Version: 3.3.0 NVIDIA 340.96
Wine: 1.9.4
AppDB entry: https://appdb.winehq.org/objectManager.php?sClass=version&iId=29911

Extra Info: as stated in the appdb, it needs the DirectX Enduser Runtime to be installed, else there is no sound




Game: Spelunky
Install media: 9772a702e0f053c42a429dfe7d5c6483f687d628 setup_spelunky_2.1.0.9.exe

Distro: Linux Mint 17.3 Rosa Desktop: Cinnamon 2.8.6
Kernel: 3.19.0-32-generic i686 (32 bit)

GLX Renderer: GeForce GT 240/PCIe/SSE2
GLX Version: 3.3.0 NVIDIA 340.96
Wine: 1.9.4
AppDB entry: https://appdb.winehq.org/objectManager.php?sClass=version&iId=31255

Extra Info: Needs dx9 installed via winetricks
Post edited February 24, 2016 by te_lanus
Dungeon Keeper 2
Debian Sid amd64
Kernel: 4.5.0-rc4-powerplay x86_64 (custom build)
Card: AMD Radeon R9 380X
OpenGL Renderer: Gallium 0.4 on AMD TONGA (DRM 3.1.0, LLVM 3.7.1)
OpenGL Version: 4.1 (Core Profile) Mesa 11.1.2
installer: setup_dungeon_keeper2_2.0.0.32.exe (MD5: 92d04f84dd870d9624cd18449d3622a5)

WINE version: 1.8.1
WINEHQ AppDB entry: https://appdb.winehq.org/objectManager.php?sClass=version&iId=26254

Black screen or stuck display after a movie:
After a movie, be it the introduction or one of the short movies that are shown in-between the missions during the campaign, the game display may be stuck on a black screen or the last frame of the movie, while the sound ambience gives you a confirmation that the game menu is loaded in the background.
If you encounter this bug, switch to another virtual desktop (Ctrl + Alt + ↓ on GNOME 3) then go back to the desktop the game is running on. It might be iconized in your taskbar at this point, but when you give it the focus back its display should not be stuck anymore.
Any word on Stardew Valley working in WINE?