Regarding Updates, Since Wine-Staging Post 2.21 is Basically Done....

enorbet · 02-20-2018, 10:29 AM

Apparently there will be no Official Wine-Staging releases after the current 2.21. The devs haven't the time. There is, however, a fork which is a set of patches that are to be applied to the main development package but I have yet to build a script to deal with the new format.

I have tried the new Wine v3.2 development package and it does not perform as well as 2.21 Staging most notably in 3D rendering affecting diverse apps including CAD but perhaps mostly Gaming. Even if you don't consider yourself "a Gamer" hopefully you realize it is a very important issue that affects the Windows Stronghold, whether that holds any importance to you or not. Personally I see increased migration from Windows both a bane and a benefit and it's difficult to yet see the net effect.

My interest is almost totally subjective since I definitely prefer never having to boot Windows even in a VM. So, has anybody tried building their own wine-staging post 2.21?

dugan · 02-20-2018, 12:48 PM

Quote:

Originally Posted by enorbet

There is, however, a fork which is a set of patches that are to be applied to the main development package but I have yet to build a script to deal with the new format.

I thought the Lutris people took over maintaining it. Are you talking about the same thing?

https://twitter.com/LutrisGaming/sta...29572873949184

enorbet · 02-20-2018, 02:34 PM

A couple days ago I read this --- Future of Wine-Staging --- which links to a fork and started messing w/ Wine-v3x. That's what prompted this thread. Thanks for the link it seems a new release may actually occur. Hope so as it does make the job of building a package a bit easier and faster. I've been using your wine-staging Slackbuild script, dugan, for many months now (over a year?) and have been hoping I could just edit the url to use it still. Maybe that will come to pass. I hope so.

1337_powerslacker · 02-21-2018, 08:33 PM

I successfully used Alien BOB's SlackBuild to build wine-3.2. The only thing I had to do (other than downloading wine-3.2 and wine-staging) was to untar the wine-d3d9 package, change the version number to 3.2, and recreate the tarball. It built without issues, and I am now using it. Just thought I'd throw that out there..

cwizardone · 03-04-2018, 06:19 AM

Here you go, version 3.3:

https://github.com/wine-staging/wine-staging

dugan · 03-04-2018, 03:26 PM

I've updated my WINE SlackBuild to apply -staging patches to 3.3.

https://github.com/duganchen/my_slac...ine.SlackBuild

Heads up that I'm not planning to do a lot of WINE gaming myself this month, so testing is appreciated.

enorbet · 03-04-2018, 06:50 PM

Quote:

Originally Posted by dugan

I've updated my WINE SlackBuild to apply -staging patches to 3.3.

https://github.com/duganchen/my_slac...ine.SlackBuild

Heads up that I'm not planning to do a lot of WINE gaming myself this month, so testing is appreciated.

Dugan I've been using your package builder for many months and have been very pleased. I am only too happy to give back by installing this tonight and reporting back on hours of gaming application. Kudos and thank you yet again.

orbea · 03-05-2018, 09:35 AM

@dugan

I noticed this in your build script.

Code:

# I believe the rule is one more than the number of cores?
((JOBS = $( nproc ) + 1))

There are two problems with this. First the $cores + 1 is just wrong. You can test this yourself by finding a small test program and testing it with -j1, -j2,-j3 and etc. I have found that the gains are reduced as the number of make jobs approaches the number of cores and then becomes slower when you exceed that number. Be sure to turn off ccache if its enabled as it will break the test.

Second, its not good practice to set the make jobs in a build script. Users should configure their preferred number of make jobs with the $MAKEFLAGS environment variable. For example with my 6-core amd cpu I can do this in /etc/profile or any equivalent location. I can then reset it if needed in my interactive environment by exporting a new value.

Code:

export MAKEFLAGS='-j6'

The only time the make jobs should be set in the SlackBuild is if the additional jobs breaks the build or if its an especially heavy compile and more jobs might overheat a system . Examples of these are the pinball game at SBo and libreoffice respectively.

dugan · 03-05-2018, 10:14 AM

I thought about it, and I decided to keep that because it does actually work well.

If you'd prefer a SlackBuild that respects "-j" in MAKEFLAGS, use this revision:

https://raw.githubusercontent.com/du...ine.SlackBuild

orbea · 03-05-2018, 11:09 AM

That just makes $JOBS an unset variable which can lead to all sorts of problems... Anyways, if you don't want to fix your script I won't stop you...

enorbet · 03-05-2018, 06:29 PM

Dugan's build script works just fine and results in a solid wine-staging install of v3x. I spent many hours running various apps and games after installing last night and my results are quite positive.

Fortunately or unfortunately, depending on your POV, I don't have any wet-behind-the-ears apps/games to test with. The latest windows-only game I have is Deus Ex: Human Revolution which is approaching 7 years of age which I run with Steam. Although it does have some quirky behavior if "Use DX11" is enabled that didn't used to work for me at all and now it does. I prefer forcing openGL for both Gamma and stability of graphics but in both cases framerates are very good even with everything maxed out. Additionally when the game first came out is was required to run it "windowed' to avoid some bug that disallowed 360 degree turning/spinning and that is no longer needed. It just works.

Since I have experienced wine "upgrades" that actually reduced performance on older games i still like to play, like World of Warcraft, I was pleased that dugan's v3 install has no such problem. If anything it there is no major change and any changes there might be seem to be toward slightly smoother as compared to 2.21 wine-staging. Even in heavy resource taxing situations like 25-man Raids with a plethora of "adds" I experienced no slowdowns or any kind of sync problems or artifacts and that was with running Discord in a Browser at the same time.

FWIW I'm still having an occasional issue with sound crapping out requiring a relog to recover but that seems to be a pulseaudio/WOW compatibility problem and has nothing to do with Wine. Man! I despise pulseaudio! For years my sound system worked exactly as I told it to. Now this intruder comes along and gets underfoot. Grrrr! Here's hoping apulse only gets better at satisfying whatever the hell apps think it is they need and just let the server do it's freakin job.

dugan · 03-05-2018, 06:35 PM

Did you say World of Warcraft?

Have you heard of this project?

https://github.com/acomminos/wine-pba

bassmadrigal · 03-05-2018, 06:40 PM

Quote:

Originally Posted by orbea

That just makes $JOBS an unset variable which can lead to all sorts of problems... Anyways, if you don't want to fix your script I won't stop you...

On my machine, if I run make -j with no argument (without MAKEFLAGS set), I ended up with 20 cc1 programs running concurrently. So, I agree, it can be problematic.

@dugan, if you want to support parallel compilation if users don't have makeflags already set, but still allow them to specify their own, you could put something like the following in place of the ((JOBS=XXXX)) portion. Then you can just have the make command and it will use whatever the user has set or the number of cores + 1.

Code:

MAKEFLAGS=${MAKEFLAGS:--j$(expr $(nproc) + 1)}

Just a suggestion if it's something you're interested in

enorbet · 03-05-2018, 07:46 PM

Quote:

Originally Posted by dugan

Did you say World of Warcraft?

Have you heard of this project?

https://github.com/acomminos/wine-pba

Hello dugan and thanks for the script update as well as this intriguing reference. I don't like any of the newer expansions of WOW since WOTLK as it seems to me they are substantially dumbed down to entice more and younger players, but old as it is since it must be played on private servers it is important that it be tweaked to be as efficient as possible since so much is server-side and dependent on net speed. The more one can do client-side efficiently the less is required additionally from the server maximizing framerates while minimizing lag while maintaining top-notch graphics for immersion as well as detail.

Currently I have to jump through a few hoops to get that client-side efficiency. One that I dislike having to do for security reasons is

Code:

 sysctl vm.mmap_min_addr=4096

but if I don't wine complains when launching WOW. It is apparently a WOW-only issue since that's the only instance in which it complains. So far no problems result but Patrick does warn it is not an ideal situation.

Additionally my command line for WOW is huge LOL, like this

Code:

 __GL_THREADED_OPTIMIZATIONS=1 wine ~/WoW-Shared/wow.exe renice -20

and actually I'd love to figure out how to incorporate 'apulse' into that command but haven't yet been successful.

So regarding these patches which warn that

Quote:

Originally Posted by Readme.md

If ARB_buffer_storage is not present, you're not going to have a good time.

I am reticent to try this until I discover how I make sure that IS present and hopefully without having to add yet an additional long string to the command. It seems I have a long research session in my future.

Thanks again.

orbea · 03-05-2018, 08:05 PM

Quote:

Originally Posted by enorbet

Additionally my command line for WOW is huge LOL, like this

Code:

 __GL_THREADED_OPTIMIZATIONS=1 wine ~/WoW-Shared/wow.exe renice -20

and actually I'd love to figure out how to incorporate 'apulse' into that command but haven't yet been successful.

That is not bad at all.

I have to launch Tales of Zestiria with this ugly script.

Code:

#!/bin/sh

set -eu

{ compiz || true; } &

GAMEPATH='/home/orbea/games/wine_toz/drive_c/Program Files/Tales of Zestiria'

TMP="${TMP:-/tmp}"
USER="$(whoami)"

mkdir -p -- "$TMP"
cat > "$TMP/TOZ.launcher.sh" <<EOF
#!/bin/sh
sudo -u "$USER" \\
  WINEARCH=win32 \\
  WINEPREFIX='/media/data/home/games/wine_toz' \\
  WINEDEBUG=-all \\
  wine Tales\ of\ Zestiria.exe
EOF

chmod 0700 -- "$TMP/TOZ.launcher.sh"

cd -- "$GAMEPATH"

xset s off; xset -dpms
trap 'rm -f -- "$TMP/TOZ.launcher.sh"; xset s on; xset +dpms; trap - EXIT; exit 0' EXIT INT

sudo xboxdrv --detach-kernel-driver --silent \
  --buttonmap tl=start,tr=guide,lb=tl,rb=tr,start=back,back=l1,guide=r1 \
  --ui-axismap X2=ABS_Z,Y2=ABS_RX,white=ABS_RY,LT=ABS_RZ,black=ABS_THROTTLE,RT=ABS_RUDDER \
  -- "$TMP/TOZ.launcher.sh"

Which I then launch from a tty with a command like this.

Code:

xinit /path/to/script.sh -- :1