Jump to content

  • Log in with Facebook Log in with Twitter Log In with Google      Sign In   
  • Create Account

Wine STAGING & CSMT Builds - Engines Available


  • Please log in to reply
664 replies to this topic

#631 eierfrucht

eierfrucht

    Regular Member

  • Members
  • Pip
  • 11 posts
  • Graphics Card:GeForce GTX 1050Ti
  • Operating System:macOS 10.12 (Sierra)

Posted 18 April 2018 - 03:47 PM

Any chance one of the repos in the first post will ever be updated with x64 3.X engines and their CSMT-Unofficial counterparts?

Sims 4 heavily relies on RAM usage so 32 bit engines won't do. It runs on 2.21 but I was looking forward to some performance improvements with 3.X

#632 dankoB

dankoB

    Legendary Member

  • Super Moderators
  • 3011 posts
  • LocationNew Brunswick, Canada
  • Graphics Card:MacBook Pro 11,3
    Core i7 16GB
    NVIDIA GeForce GT 750M
    2GB GDDR5 vRAM
  • Operating System:macOS 10.12 (Sierra)
  • I like to play:la rockitar
Author

Posted 18 April 2018 - 05:29 PM

Are you still running a staging 2.21 wrapper? If so, you can take advantage of the newest staging quite easily. Right click on the wrapper and choose Show Package Contents. Then download the link provided here ---> http://www.mediafire...6x64.bundle.zip

Extract the contents...you'll get a wswine.bundle. Drag and drop that file to the Contents > Frameworks folder and click Replace File when asked. When you launch Sims next time the wrapper will update the reg files and then launch as usual...as long as the new staging hasn't broken anything in Sims but I doubt it has.

#633 Gcenx

Gcenx

    Veteran Member

  • Members
  • PipPipPipPipPip
  • 373 posts
  • Graphics Card:Intel Iris
  • Operating System:macOS 10.12 (Sierra)

Posted 18 April 2018 - 05:34 PM

View Posteierfrucht, on 18 April 2018 - 03:47 PM, said:

Any chance one of the repos in the first post will ever be updated with x64 3.X engines and their CSMT-Unofficial counterparts?

Sims 4 heavily relies on RAM usage so 32 bit engines won't do. It runs on 2.21 but I was looking forward to some performance improvements with 3.X

You could just download the tar.gz from https://dl.winehq.or...x/download.html and pack them into an engine yourself.


Or use the provided file from dankoB

View PostdankoB, on 18 April 2018 - 05:29 PM, said:

Are you still running a staging 2.21 wrapper? If so, you can take advantage of the newest staging quite easily. Right click on the wrapper and choose Show Package Contents. Then download the link provided here ---> http://www.mediafire...6x64.bundle.zip

Extract the contents...you'll get a wswine.bundle. Drag and drop that file to the Contents > Frameworks folder and click Replace File when asked. When you launch Sims next time the wrapper will update the reg files and then launch as usual...as long as the new staging hasn't broken anything in Sims but I doubt it has.

You can now at least directly download the wine-staging directly winehq now.

#634 eierfrucht

eierfrucht

    Regular Member

  • Members
  • Pip
  • 11 posts
  • Graphics Card:GeForce GTX 1050Ti
  • Operating System:macOS 10.12 (Sierra)

Posted 18 April 2018 - 06:36 PM

Quote

You can now at least directly download the wine-staging directly winehq now.
How do I do that? I used to build Wine manually but mostly adhered to Wineskin pre-built engines. WineHQ offers some sort of "portable wine" I can hardly make head or tail of. I suppose wswine.bundle is just a folder with a special name, but which exact parts of WineHQ's "portable wine" should I put inside wswine.bundle and which should avoid?

I also recall that WrapperUpdate6 (by Slice) is required for 3.X to operate properly since it offers some x64 libraries that WrapperUpdate5 doesn't.

I'm looking for a way to create Wine 3.X wrappers with Wineskin the way I used to with 2.X. So that all folders are properly populated upon creation, etc.

#635 Gcenx

Gcenx

    Veteran Member

  • Members
  • PipPipPipPipPip
  • 373 posts
  • Graphics Card:Intel Iris
  • Operating System:macOS 10.12 (Sierra)

Posted 18 April 2018 - 07:22 PM

View Posteierfrucht, on 18 April 2018 - 06:36 PM, said:

How do I do that? I used to build Wine manually but mostly adhered to Wineskin pre-built engines. WineHQ offers some sort of "portable wine" I can hardly make head or tail of. I suppose wswine.bundle is just a folder with a special name, but which exact parts of WineHQ's "portable wine" should I put inside wswine.bundle and which should avoid?

I also recall that WrapperUpdate6 (by Slice) is required for 3.X to operate properly since it offers some x64 libraries that WrapperUpdate5 doesn't.

I'm looking for a way to create Wine 3.X wrappers with Wineskin the way I used to with 2.X. So that all folders are properly populated upon creation, etc.

To make your own engine, unpack the .tar.gz the folder will be called usr, add a text file called Version, inside give it the name you want shown inside WineSkin.app

Rename the folder wswine.bundle, then use keka to pack that as a 7z then rename the .7z to the engine name like WS9Wine3.6.tar.7z you can now use the engine when creating a new wrapper.

That will give you a repacked Engine, I remember some members saying compiled ones are slightly faster?, also they will only work on 10.8+ compiled engines can be used on 10.6.


You can get my unofficial wineskin wrapper update it includes Slices wrapperupdate6 libs along with some other updates and fixes.
But it still will not make Staging64 engines correctly, I could fix Wineskin Launcher to make them but I won't considering it since code needs to be completely restructured. So that won't be added to the posted update.

#636 dankoB

dankoB

    Legendary Member

  • Super Moderators
  • 3011 posts
  • LocationNew Brunswick, Canada
  • Graphics Card:MacBook Pro 11,3
    Core i7 16GB
    NVIDIA GeForce GT 750M
    2GB GDDR5 vRAM
  • Operating System:macOS 10.12 (Sierra)
  • I like to play:la rockitar
Author

Posted 18 April 2018 - 08:32 PM

The problem with using Wineskin Winery now is (for me anyway), for some reason the new staging engines won't populate the syswow64 folder and sometimes not even build the old syswow64 engines like they used to with previous versions of Wineskin Winery. I'm not sure what the issue is really and I'm not even sure on how to check the issue through Terminal so I can't provide any output logs so to speak...but I have had very good success with the drag and drop method of wine within my wrappers with the newest 3.6 staging.

The biggest reason why I suggest that you download the file I provided is that I included the VERSION unix system file that Wineskin recognizes and displays as the Wine version within the app.

#637 eierfrucht

eierfrucht

    Regular Member

  • Members
  • Pip
  • 11 posts
  • Graphics Card:GeForce GTX 1050Ti
  • Operating System:macOS 10.12 (Sierra)

Posted 18 April 2018 - 11:51 PM

dankoB, if I were to create a new Staging x64 wrapper from scratch, should I start with creating an 2.21 x64 Staging Wineskin the usual way then replacing wswine.bundle with your build of 3.6 as instructed? If so, the original post should definitely be updated with this as a brief guide... and from now on the repos could be updated just with wswine.bundles, with a big fat README.TXT in each folder. Pretty please. I nearly set off building 3.6 myself the old way because I found no guides on how to repackage the WineHQ stuff into a palatable Wineskin engine (I know it sounds ridiculous)

Gcenx, I if place your WrapperUpdate right inside my Application Support / Wine folder -- so that every newly built wrapper uses it -- will it affect my success in building pre-3.X engines? Or I can safely update and forget about it?

Quote

for some reason the new staging engines won't populate the syswow64 folder
Do Vanilla 3.X x64 & x86 suffer from this? Is it Wineskin's or just the engine's fault? If it's not just Staging, we could expect Doh123 to fix it in the near future.

P.S. A very stupid question, may be totally off topic. A bunch of releases ago, a pre-loader was added to Wine. It should have adressed this bug that prevented Alice: Madness Returns from running on Mac OS (the problematic memory range is unused by the Linux kernel, so the game has been running fine on Linux for ages) Some discussions concerning Alice: Madness Returns mention Origin being involved... Origin is the same copy protection system that Sims 4 uses, and I must admit that at least since 2.18 I had no problems with Origin and its online services with Sims 4 (never knew Alice used it) Does anyone happen to know if I can run Alice: Madness Returns now?

#638 Gcenx

Gcenx

    Veteran Member

  • Members
  • PipPipPipPipPip
  • 373 posts
  • Graphics Card:Intel Iris
  • Operating System:macOS 10.12 (Sierra)

Posted 19 April 2018 - 01:16 AM

View Posteierfrucht, on 18 April 2018 - 11:51 PM, said:

Gcenx, I if place your WrapperUpdate right inside my Application Support / Wine folder -- so that every newly built wrapper uses it -- will it affect my success in building pre-3.X engines? Or I can safely update and forget about it?


Do Vanilla 3.X x64 & x86 suffer from this? Is it Wineskin's or just the engine's fault? If it's not just Staging, we could expect Doh123 to fix it in the near future.

That is correct using the wrapper update will work with older engines and new engines, I personally tested down to Wine 2.0 I didn't go lower as I have no need. but I don't think anything lower would cause an issues.

Ok so my update will allow you to build vanilla 32bit/vanilla 64bit engines and staging 32bit engines. 2.x > 3.x
Staging 64bit engines will not build correctly same with standard Wineskin 2.6.2 wrapper.

Doh123 is currently very busy with IRL from the last message I could find publicly from her, so having an official update could take a while but don't worry an update is being worked on by VitorMM and a little help from me. This update already fixes staging 64bit engine creation issue.

#639 dankoB

dankoB

    Legendary Member

  • Super Moderators
  • 3011 posts
  • LocationNew Brunswick, Canada
  • Graphics Card:MacBook Pro 11,3
    Core i7 16GB
    NVIDIA GeForce GT 750M
    2GB GDDR5 vRAM
  • Operating System:macOS 10.12 (Sierra)
  • I like to play:la rockitar
Author

Posted 19 April 2018 - 07:37 AM

basically, yes...that's what I had been doing since staging 2.21. But for some reason now, I can't create any functional 64bit wrappers on my system at all. Staging or otherwise.

Check out my post here...this might be a bit more convenient...

http://portingteam.c...eskin-wrappers/

#640 Gcenx

Gcenx

    Veteran Member

  • Members
  • PipPipPipPipPip
  • 373 posts
  • Graphics Card:Intel Iris
  • Operating System:macOS 10.12 (Sierra)

Posted 19 April 2018 - 12:01 PM

View PostdankoB, on 19 April 2018 - 07:37 AM, said:

basically, yes...that's what I had been doing since staging 2.21. But for some reason now, I can't create any functional 64bit wrappers on my system at all. Staging or otherwise.

Check out my post here...this might be a bit more convenient...

http://portingteam.c...eskin-wrappers/

I have not needed to worry about that issue for a while now.

#641 dankoB

dankoB

    Legendary Member

  • Super Moderators
  • 3011 posts
  • LocationNew Brunswick, Canada
  • Graphics Card:MacBook Pro 11,3
    Core i7 16GB
    NVIDIA GeForce GT 750M
    2GB GDDR5 vRAM
  • Operating System:macOS 10.12 (Sierra)
  • I like to play:la rockitar
Author

Posted 19 April 2018 - 02:45 PM

I'm not sure why but everything broke on my system after I tried your second update to Wineskin...The first one worked well then after I tried the second one you created it stopped producing proper wrappers altogether...even after rolling my system to a previous backup.

#642 eierfrucht

eierfrucht

    Regular Member

  • Members
  • Pip
  • 11 posts
  • Graphics Card:GeForce GTX 1050Ti
  • Operating System:macOS 10.12 (Sierra)

Posted 19 April 2018 - 03:14 PM

View PostdankoB, on 19 April 2018 - 02:45 PM, said:

I'm not sure why but everything broke on my system after I tried your second update to Wineskin...The first one worked well then after I tried the second one you created it stopped producing proper wrappers altogether...even after rolling my system to a previous backup.
I recall that using Finder (and possibly other file managers) to overwrite WrapperUpdate files resulted in total screwage for me -- like wrapper creation took forever or never progressed past the "updating the wrapper contents" splash screen.

The only remedy was to eliminate the entire Frameworks folder inside Application Support / Wine then reinstall Wineskin then reinstall WrapperUpdate using the cp -r terminal command.

The source of the problem was that Finder (and possibly other file managers) produce so-called Finder-symlinks every time you try to copy "normal" symlinks. Wineskin hates Finder-symlinks.

Sorry for assuming the role of Captain Obvious.

#643 Gcenx

Gcenx

    Veteran Member

  • Members
  • PipPipPipPipPip
  • 373 posts
  • Graphics Card:Intel Iris
  • Operating System:macOS 10.12 (Sierra)

Posted 19 April 2018 - 04:00 PM

View PostdankoB, on 19 April 2018 - 02:45 PM, said:

I'm not sure why but everything broke on my system after I tried your second update to Wineskin...The first one worked well then after I tried the second one you created it stopped producing proper wrappers altogether...even after rolling my system to a previous backup.

I'm assuming you tried to merge the original with the new one not replaced it, was that the case?
Did you empty your tmp folder? I remember mine did get crazy at one point and that caused the same issue on my end.

As I have tested the current wrapper I have posted and it works fine but won't make Staging64bit engines


Edit:
Check your messages.

Edited by Gcenx, 19 April 2018 - 04:41 PM.


#644 eierfrucht

eierfrucht

    Regular Member

  • Members
  • Pip
  • 11 posts
  • Graphics Card:GeForce GTX 1050Ti
  • Operating System:macOS 10.12 (Sierra)

Posted 29 April 2018 - 02:56 PM

Is this WS9WineStaging3.6.dmg good enough to create new wrappers with? It was uploaded just a few hours ago.

#645 Gcenx

Gcenx

    Veteran Member

  • Members
  • PipPipPipPipPip
  • 373 posts
  • Graphics Card:Intel Iris
  • Operating System:macOS 10.12 (Sierra)

Posted 29 April 2018 - 03:12 PM

View Posteierfrucht, on 29 April 2018 - 02:56 PM, said:

Is this WS9WineStaging3.6.dmg good enough to create new wrappers with? It was uploaded just a few hours ago.

That's just a wrapper so no you cant make new wrappers using it, unless you go the complicated route of changing to the engine you want then using Rebuild wrapper

But that's a round about way.

#646 NRG

NRG

    Champion Member

  • Members
  • 679 posts
  • Graphics Card:Nvidia 9800m GTS
  • Operating System:OS X 10.10 (Yosemite)

Posted 01 May 2018 - 08:02 AM

Wineskin's STAGING ENGINES V.3.7:



STG 3.7.tar.7z...
standard 32bit release




#647 NRG

NRG

    Champion Member

  • Members
  • 679 posts
  • Graphics Card:Nvidia 9800m GTS
  • Operating System:OS X 10.10 (Yosemite)

Posted 01 May 2018 - 11:50 AM

I don't know why but both Staging engines (3.6 and 3.7) crash my PES2017 game during his loading...

It's seems the same regression I had here...

regression that was solved  since staging 2.13 release

View PostNRG, on 01 May 2018 - 08:02 AM, said:

Wineskin's STAGING ENGINES V.3.7:



STG 3.7.tar.7z...
standard 32bit release




#648 Gcenx

Gcenx

    Veteran Member

  • Members
  • PipPipPipPipPip
  • 373 posts
  • Graphics Card:Intel Iris
  • Operating System:macOS 10.12 (Sierra)

Posted 01 May 2018 - 03:55 PM

View PostNRG, on 01 May 2018 - 11:50 AM, said:

I don't know why but both Staging engines (3.6 and 3.7) crash my PES2017 game during his loading...

It's seems the same regression I had here...

regression that was solved  since staging 2.13 release

Same kinda thing for me everything past 3.4 has big regressions in DirectDraw so games like "Red Alert 2" will run way too slow.

I wouldn't blame Staging on that breakage since they are using Wine-Devel then applying the Staging patches since those things (in my case) are broken in Wine-Devel I don't worry about it too much

I still don't get how they still manage to keep breaking things that were working even years later even with how hard it is to even get a patch through to upstream part of the reason Staging even become a thing.....

#649 NRG

NRG

    Champion Member

  • Members
  • 679 posts
  • Graphics Card:Nvidia 9800m GTS
  • Operating System:OS X 10.10 (Yosemite)

Posted 01 May 2018 - 04:22 PM

View PostGcenx, on 01 May 2018 - 03:55 PM, said:

Same kinda thing for me everything past 3.4 has big regressions in DirectDraw so games like "Red Alert 2" will run way too slow.



Did you disable the CSMT flag in wine config?

since wine 3.3 was released it seems they flagged CSMT by default... if you haven't a very good hardware you can have slow downs in many games with CSMT enabled

#650 Gcenx

Gcenx

    Veteran Member

  • Members
  • PipPipPipPipPip
  • 373 posts
  • Graphics Card:Intel Iris
  • Operating System:macOS 10.12 (Sierra)

Posted 01 May 2018 - 04:37 PM

View PostNRG, on 01 May 2018 - 04:22 PM, said:

Did you disable the CSMT flag in wine config?

since wine 3.3 was released it seems they flagged CSMT by default... if you haven't a very good hardware you can have slow downs in many games with CSMT enabled

I did forget about that, even with it disabled it still lags 3.4 runs it like native in Windows 7 after 3.4 its a nope.
Red Alert 2 even has issues on Windows. I have the flag enabled on most of my other wrappers no slow downs in those so its a regression within wines DirectDraw component.

#651 Incredible Hulk

Incredible Hulk

    Professional Member

  • Members
  • PipPipPipPip
  • 185 posts
  • Graphics Card:6750M, OSX 10.12.2
  • Operating System:Other OS/Not specified
  • I like to play:PES, COD, Grid, FNV, RO

Posted 01 May 2018 - 05:59 PM

View PostNRG, on 01 May 2018 - 11:50 AM, said:

I don't know why but both Staging engines (3.6 and 3.7) crash my PES2017 game during his loading...

It's seems the same regression I had here...


Can confirm that I can no longer start UE3 engine games in Wine Staging 3.7.
Same behaviour with 3.7 devel version.

Seems like this bug again
https://bugs.winehq....ug.cgi?id=31967

#652 Incredible Hulk

Incredible Hulk

    Professional Member

  • Members
  • PipPipPipPip
  • 185 posts
  • Graphics Card:6750M, OSX 10.12.2
  • Operating System:Other OS/Not specified
  • I like to play:PES, COD, Grid, FNV, RO

Posted 06 May 2018 - 11:05 AM

S. Lackner was a long time user here and Mac specific bugs (latest preloader case) were cleared directly on this forum without even reporting bugs to WineHQ, which btw don't accept Wineskin bugs even when they are obviously Wine bugs.

I don't think this will got fixed without directly contacting Alistar Leslie-Hughes, new Staging maintainers or reporting to WineHQ?

#653 dankoB

dankoB

    Legendary Member

  • Super Moderators
  • 3011 posts
  • LocationNew Brunswick, Canada
  • Graphics Card:MacBook Pro 11,3
    Core i7 16GB
    NVIDIA GeForce GT 750M
    2GB GDDR5 vRAM
  • Operating System:macOS 10.12 (Sierra)
  • I like to play:la rockitar
Author

Posted 06 May 2018 - 12:20 PM

Yeah, I've always been disappointed that they don't recognize the issues found using Wineskin as a frontend, I probably would have been more involved in that community if it were the case. I understand that they do not want to hear about any bugs concerning the front end and they would likely require a set of guidelines concerning the dependencies installed and and things that might affect the outcome of the logs...but with using the built in function to direct Terminal to the Wine installed within the wrapper will provide the exact same results that normal Wine would provide.

#654 Incredible Hulk

Incredible Hulk

    Professional Member

  • Members
  • PipPipPipPip
  • 185 posts
  • Graphics Card:6750M, OSX 10.12.2
  • Operating System:Other OS/Not specified
  • I like to play:PES, COD, Grid, FNV, RO

Posted 17 May 2018 - 07:55 PM

Does anyone still have flickering bug?

https://github.com/H...mment-379534814

And does this patch make any difference
https://gist.github....13f684d43bb254b



#655 eierfrucht

eierfrucht

    Regular Member

  • Members
  • Pip
  • 11 posts
  • Graphics Card:GeForce GTX 1050Ti
  • Operating System:macOS 10.12 (Sierra)

Posted 28 May 2018 - 06:10 PM

Has anyone checked if the X360CE xinput wrapper worked with the recent Wine builds and the unofficial wrapper update?

Wine seems to come with a rudimentary xinput support these days, so trying to run games on the built-in xinput_*.dll(s) results in an avalanche of bogus input registered with my Dualshock 4 V2 & the official Sony bluetooth dongle. That is, the game detects a gamepad of sorts but it's basically just random button taps and stick sways coming out of nowhere while the actual gamepad is resting untouched. Once I put the gamepad to sleep (without unplugging the dongle from the computer) the ghost input ceases.

When I enforce a "native, then built-in" override for the exact xinput*_*.dll that a particular game uses and drop the X360CE library next to the game's executive, no joystick is detected at all. With much older engines and wrapper updates, X360CE worked fine in such a setup.

I created a separate wrapper with WS9Wine3.9 and installed the X360CE config editor tool (x360ce.exe) in it. I installed the numerous dependencies required by the GUI (dotnet4.5, dotnet3, vcrun2010, etc) and, like I expected, was able to successfully run the software.

When I set xinput1_3.dll to "native, then built-in" (so that x360ce.exe loads its own tampered version of xinput1_3.dll) no joystick is detected.

What is even more puzzling, when I reverse the override to "built-in, then native" x360ce.exe starts up just fine but registers loads of ghost input, it actually shows all those random button hits and stick movements that plague my wine games.

I would be very much obliged to anyone who suggested a reliable way of gagging up the very immature and disfunctional built-in xinput support of recent Wine builds and overriding it with native xinput calls so that the (fake) xinput dll implemented in x360ce works the way it used to back in the day.

I clearly remember that back when Wine 1.6 was the cutting edge, all I needed was to see which exact xinput dll a game used; then rename the x360ce xinput.dll to match that name; then put this renamed dll (along with a properly configured x360ce.ini) into the same folder with the game executive; then set a "native, then built-in" override. This seems no longer be the case.

The games that I use for testing are Brothers: A Tale of Two Sons and Fable III, both of which support x360ce in Windows and used to support it in Wine a few years ago. I'm fully aware that both games need special values for the HookMask parameter in x360ce.ini and I do use the proper values.

The x360ce GUI Editor (x360ce.exe) itself doesn't need any configuration files at all (its main purpose is to create and edit them), so a good starting point would be to see if x360ce.exe could be cranked into a more or less of a working state with its custom native xinput dll. Once it's OK, this wrapper library will very probably work in standalone mode with all supported games like it used to in older Wine.

P.S. I'm also wondering how to fire up the joy.cpl control panel item in this wrapper version: http://portingteam.c...fficial-update/ It's called upon by the x360ce GUI and even as a standalone offering, offers some solutions for filtering xinput/dinput issues in Wine. Currently x360ce GUI crashes when I press the List Controllers button.

#656 Gcenx

Gcenx

    Veteran Member

  • Members
  • PipPipPipPipPip
  • 373 posts
  • Graphics Card:Intel Iris
  • Operating System:macOS 10.12 (Sierra)

Posted 29 May 2018 - 05:19 PM

View Posteierfrucht, on 28 May 2018 - 06:10 PM, said:

Has anyone checked if the X360CE xinput wrapper worked with the recent Wine builds and the unofficial wrapper update?

I was using x360ce when playing Skyrim before I released the "unofficial wrapper update" and it was working fine.
Does it work on new wine versions? I don't know since I only use an XboxOneS controller I have not needed x360ce since.


View Posteierfrucht, on 28 May 2018 - 06:10 PM, said:

P.S. I'm also wondering how to fire up the joy.cpl control panel item in this wrapper version: http://portingteam.c...fficial-update/ It's called upon by the x360ce GUI and even as a standalone offering, offers some solutions for filtering xinput/dinput issues in Wine. Currently x360ce GUI crashes when I press the List Controllers button.

Same as stock wine, used CMD option and type "control" that will launch the Wine control panel implementation and you can access joystick controls from there. Don't ask me why you can't launch it directly as that's been a wine bug since before wine2.0


Please Note:
I did look at the requirements you posted I will assume you are using an old version, since the requirements are now dotnet46 and vcrun2013 for the current version.

#657 eierfrucht

eierfrucht

    Regular Member

  • Members
  • Pip
  • 11 posts
  • Graphics Card:GeForce GTX 1050Ti
  • Operating System:macOS 10.12 (Sierra)

Posted 31 May 2018 - 12:10 AM

The project's github offers a '2015 build and so does x360ce.com

The Releases page at github offers a totally revamped 4.X version that asks to download & install X360 controller drivers and doesn't offer the .dll/.ini option so it's useless in Wine.

Is there a 3.X build newer than this? https://github.com/x...ce.zip?raw=true

Another question. This may be the wrong place to ask it, but...

Some games like Brothers or Contrast -- both use the UE3 engine and XAct sound libraries -- don't play certain sounds (or suddenly lose audio) with wine's built-in libraries.

After installing native XAct via Winetricks, the sound is restored yet troubles persist, just with a different pattern:

1. If I masquerade as Windows XP, the sound is clear but there's a short nasty buzz at the very beginning and... a really good chance, like 1 in 3 or so, that the game will run silent; a much smaller chance persists that the sound is totally lost across the whole operating system until I reboot.

2. If I select Windows Vista, sound is largely OK but becomes choppy when CPU usage approaches 100%; I'd guess this happens when one of the CPU cores hits 100%.

3. If I select Windows 7 or above, sound becomes really choppy for short periods of time, it's both very random and frequent.

Setting a higher audio sample rate at the OS level (say 48k->96k) seems to nearly exterminate his choppiness -- unless the CPU becomes totally hogged. To get 96k with my audio hardware, I had to go down from 24-bit sound to 16-bit sound, but setting 48k@16bit did nothing so bit depth is seemingly uninvolved per se.

Back in the 1.8.X era, this issue plagued Xact on wine-staging but not vanilla. It was much worse with wine-staging though.

In the Linux world, this issue is easily resolved by tuning down the sample length (in milliseconds) and the sample buffer size.

I wonder if CoreAudio allows possibilities for similar tuning on OS X.

I haven't even been able to find that exact bug at the bugtracker; since it was very pronounced in older wine-staging and affected multiple people, it couldn't just have slipped past the bugtracker unnoticed.

#658 Gcenx

Gcenx

    Veteran Member

  • Members
  • PipPipPipPipPip
  • 373 posts
  • Graphics Card:Intel Iris
  • Operating System:macOS 10.12 (Sierra)

Posted 31 May 2018 - 11:42 PM

View Posteierfrucht, on 31 May 2018 - 12:10 AM, said:

The project's github offers a '2015 build and so does x360ce.com

The Releases page at github offers a totally revamped 4.X version that asks to download & install X360 controller drivers and doesn't offer the .dll/.ini option so it's useless in Wine.

Is there a 3.X build newer than this? https://github.com/x...ce.zip?raw=true
I can't see anything older on the site, but that could be useful since I know 4.x always complains it can't write to the ini file.

View Posteierfrucht, on 31 May 2018 - 12:10 AM, said:

I wonder if CoreAudio allows possibilities for similar tuning on OS X.
Yeah Winehq is terrible for macOS information/help, I also took looked but nothing is mentioned oh how to fix the audio crack on Wine/Wine-Staging. You could try a CX engine I don't notice the audio crackling in Skyrim when using Crossover.
But I also don't remember hearing it when forcing it to always launch as XP in Staging 3.4+

#659 eierfrucht

eierfrucht

    Regular Member

  • Members
  • Pip
  • 11 posts
  • Graphics Card:GeForce GTX 1050Ti
  • Operating System:macOS 10.12 (Sierra)

Posted 13 June 2018 - 12:16 PM

So it turned out that audio crackling with native Xact libraries is minimized by setting OS version to Vista and making sure that CPU load never hits 100%. It can be 99% but not 100%, otherwise you'll get distorted audio.

Masquerading as WIndows 7 gives a lot of noise, WinXP results in no noise but at times no audio at all.

#660 NRG

NRG

    Champion Member

  • Members
  • 679 posts
  • Graphics Card:Nvidia 9800m GTS
  • Operating System:OS X 10.10 (Yosemite)

Posted 13 June 2018 - 07:18 PM

Wineskin's engines Staging 3.10 are ready:

standard 32 bit version only




both 32+64bit engines are included





0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users