20 replies to this topic

[ovvldc]

Crossover 18 was released on 16.10.2018, and Proton 3.16 beta seems to be finalised, if not released quite yet.

I hope the fixes will be useful, even if we can not yet use Vulkan on Mac for D3D10-D3D11-D3D12. Some progress was made, as far as I can tell, but geometry/tesselation shaders and stream output AKA transform feedback are still missing from MoltenVK. I don't even know if Metal has features to cover those (As far as I can tell: yes on tesselation, no on geometry but that can be circumvented with compute shaders, and no for stream output)

[Incredible Hulk]

It's early stages but it seems Codeweavers and Valve are resilient this time to make it working.

https://github.com/K...sues/302#bottom

To see Mac and Wolfenstein II in the same sentence is really exciting.

[Zakk]

Just FYI, they removed all mac build support from Proton about a week or so ago. Obviously it is still just wine so you can get it to build, but all references to macOS were removed from the README, they removed any external submodules that were mac specific (MoltenVK, and a few others) from the repo and changed the build system entirely. No word on if this is temporary or permanent. I suspect they consider dxvk to be a big part of Proton and see no point in even worrying about the platform until that is somehow functional.

[Gcenx]

 ovvldc, on 17 October 2018 - 01:09 PM, said:

Crossover 18 was released on 16.10.2018, and Proton 3.16 beta seems to be finalised, if not released quite yet.

I hope the fixes will be useful, even if we can not yet use Vulkan on Mac for D3D10-D3D11-D3D12. Some progress was made, as far as I can tell, but geometry/tesselation shaders and stream output AKA transform feedback are still missing from MoltenVK. I don't even know if Metal has features to cover those (As far as I can tell: yes on tesselation, no on geometry but that can be circumvented with compute shaders, and no for stream output)

I don't know I was not too impressed with the Beta1/2/3 and RC2 I tested...
But yeah I forgot I need to add WineCX64Bit18.0.0/WineCX18.0.0 for download, guess I need to push the winery update first for the newer engine ordering.

I had seen Proton3.16 but didn't get around to building it yet since I would need to patch it again before building and this time I plan to also ensure CEF is working so Steam Client would be usable. It's mostly just the Proton patches rebased to wine 3.16 with a few new additions added.

 Zakk, on 17 October 2018 - 07:34 PM, said:

Just FYI, they removed all mac build support from Proton about a week or so ago. Obviously it is still just wine so you can get it to build, but all references to macOS were removed from the README, they removed any external submodules that were mac specific (MoltenVK, and a few others) from the repo and changed the build system entirely. No word on if this is temporary or permanent. I suspect they consider dxvk to be a big part of Proton and see no point in even worrying about the platform until that is somehow functional.

Yeah I noticed that too, not like we can't build it without the provided script.
I agree without DXVK & VKD3D working via MoltenVK having a macOS version would be a waste of time since we all know about the removal of 32Bit or at least crippling it in the next macOS version, my guess is Value want to hold out making official support until Codeweavers have a decent solution in place and working DXVK support.

[ovvldc]

 Gcenx, on 18 October 2018 - 03:15 AM, said:

I don't know I was not too impressed with the Beta1/2/3 and RC2 I tested...
But yeah I forgot I need to add WineCX64Bit18.0.0/WineCX18.0.0 for download, guess I need to push the winery update first for the newer engine ordering.

I didn't mean to push you. No rush . We're all grateful for your efforts!

[Gcenx]

 ovvldc, on 18 October 2018 - 07:46 AM, said:

I didn't mean to push you. No rush . We're all grateful for your efforts!

And I still forgot to push the commit for WineCX18.0.0 until I seen the thread from NGR.......
I did some of the work for Proton3.16-3 last night. I just need to add some staging patches so cef sandboxing works.


Im not sure I’m going to be posting links to my compiles anymore since they won’t fully work with stock Wineskin even if using Slices Update5 due to the difference in compile options that were used. Instead I will just keep adding them to my MEGA that Winery links to and I guess speed up moving everything over to the other host so I can just offer them from Winery directly.

[ovvldc]

Then how do we distinguish yours from NRG's much more stock Wine compilations (and others)?

[Gcenx]

 ovvldc, on 30 October 2018 - 11:48 AM, said:

Then how do we distinguish yours from NRG's much more stock Wine compilations (and others)?

The one from NGR would be WS9 mine is WS10 and availability for direct download in my Winery.app

By stock I’m guessing you mean things that work on Stock Wineskin-2.6.2 without any editing? If so then yes NGR’s compile will work out of box on Wineskin-2.6.2. But Xinput support will of course be missing along with openal/ffmpeg/gnutls (gnutls means Steam needs no workaround & working steam store)

Mine basically does require the use of my version of Winery/Wineskin to get full functionality, just adding in libpng16.16 or installing XQuartz 2.7.11 would get it functional along with Xinput support, but anything else would require my master wrapper.


I guess I really should take the time to move the project to the other host so I’m able to just offer my engines for direct download should help solve these issues.

[ovvldc]

I understand, I am just worried that new people might get a tad confused at all this . I personally am very grateful for the gnuTLS and Xinput support, because I typically put Steam apps in the wrappers.

[Gcenx]

 ovvldc, on 03 December 2018 - 09:22 AM, said:

I understand, I am just worried that new people might get a tad confused at all this . I personally am very grateful for the gnuTLS and Xinput support, because I typically put Steam apps in the wrappers.

I mostly stick to a single Steam wrapper with all my games installed into it unless they can’t work from with it. Then if needed I make other wrappers that need complicated work-arounds.


I agree it might be confusing for the moment I was going to add them all for download but with the recent Steam update lead me to the discovery of the following Clang issue
So won’t be offering them for direct download until I get a replacement build system up and running to cross-compile or patch Clang to support the missing function ms_hook_prologue

[ovvldc]

Very understandable, Genx .

In the mean time, Codeweavers have released CX 18.1, with the following changelog:

18.1.0 CrossOver - December 4, 2018

• macOS:
  
  • Fixed a bug that prevented Quicken from launching for some users.
    
  • Fixed a bug that caused the latest Quicken 2016 Mondo Patch to fail during installation.
    
  • Fixed a bug that prevented game downloads and the Steam Store page from working on the latest Steam release.
    
  • Restored controller support for Steam.

I presume that the third and fourth represent the gnuTLS and Xinput fixes that you have also integrated.

[Gcenx]

 ovvldc, on 04 December 2018 - 09:58 PM, said:

Very understandable, Genx .

 ovvldc, on 04 December 2018 - 09:58 PM, said:

In the mean time, Codeweavers have released CX 18.1, with the following changelog:

18.1.0 CrossOver - December 4, 2018

• macOS:
  
  • Fixed a bug that prevented Quicken from launching for some users.
    
  • Fixed a bug that caused the latest Quicken 2016 Mondo Patch to fail during installation.
    
  • Fixed a bug that prevented game downloads and the Steam Store page from working on the latest Steam release.
    
  • Restored controller support for Steam.

I presume that the third and fourth represent the gnuTLS and Xinput fixes that you have also integrated.

Not exactly,
CrossOver 17.5.1 and CrossOver 18 already came with gnutls support with embedded gnutls/gmp dylib's. (Contents/SharedSupport/CrossOver/lib &lib64)
But after the latest Steam update it needed another key that was not added into CrossOver 18, but the Steam Store stopped working after the new update even on Wine 3.21, so maybe they had to add something else to get it working or just used the old patch again from CrossOver 17.5.1

Controller support I'm not sure I never did test that during the Beta I was more focused on getting them to fix some other macOS bugs, since I know I was going to compile with SDL2 anyway once the source code was uploaded.

Seems when I'm able to have working builds again I will be extracting those the Steam Store fix if its still needed.

[Gcenx]

 ovvldc, on 04 December 2018 - 09:58 PM, said:

18.1.0 CrossOver - December 4, 2018

• macOS:
  
  • Fixed a bug that prevented Quicken from launching for some users.
    
  • Fixed a bug that caused the latest Quicken 2016 Mondo Patch to fail during installation.
    
  • Fixed a bug that prevented game downloads and the Steam Store page from working on the latest Steam release.
    
  • Restored controller support for Steam.

I compiled and added WS10WineCX18.1.0 and WS10WineCX64Bit18.1.0 for download now.

Any possible issues due to my compiling with Apple Clang (XCode Command Line Tools) may still happen, but new wrappers now have "gameoverlayrenderer" set to disabled so at least the Steam issues for Skyrim/Fallout etc won't happen now since that's disabled.

[ovvldc]

I used it for a wrapper for Dishonored, and it worked pretty much out of the box. Thanks!

[Gcenx]

 ovvldc, on 10 December 2018 - 08:44 AM, said:

I used it for a wrapper for Dishonored, and it worked pretty much out of the box. Thanks!

I'm happy to hear that.
After I have released the next wrapper update I will try to extract the new Steam patches so I can upload a more useful copy of Proton3.16 as a working Steam store is useful.

[ovvldc]

Hi Genx,

I am using the WS10CX18.10 engine and wrapper 2.8.8Beta5 with Fallout: New Vegas on Mac OS Mojave, and the wrapper wants to use Accessibility settings and 'control my computer'. Is there any reason for this? It doesn't seem to mention this in your list of modifications at  http://portingteam.com/topic/11037-wineskin-unofficial-update/

Thanks for any insights!

[dankoB]

I think it's a new security feature for older apps that weren't built specifically with Mojave in mind. It has nothing to do with Unofficial Wineskin but rather how Unofficial Wineskin interacts with Mojave. More information on the feature can be found here  ---->   https://www.macworld...isk-access.html

[ovvldc]

Thanks! That UI is uncharacteristically un-Apple unclear...

[Gcenx]

 dankoB, on 21 December 2018 - 12:41 PM, said:

I think it's a new security feature for older apps that weren't built specifically with Mojave in mind. It has nothing to do with Unofficial Wineskin but rather how Unofficial Wineskin interacts with Mojave. More information on the feature can be found here  ---->   https://www.macworld...isk-access.html

 ovvldc, on 21 December 2018 - 12:54 PM, said:

Thanks! That UI is uncharacteristically un-Apple unclear...

Honesty even when I get around to changing how Wineskin handles launching wine it won’t stop that permission promt, the reason for this happening only in some games/Applications and not others is what system calls are being used.
For example in Mojave if an application wants to have control over say your mouse it would need permission to do that.

You will get the same promt if you use the official winehq builds but instead Terminal will be asking for these permissions not wine.
Yes it seems very unApple like but that’s how it has been working in iOS for a good while now.


In later versions Wineskin will end up asking for MORE permissions for things like microphone (if wine asks to use the microphone) as right now Wineskin does not get access to your mic even if wine tries to use that system call.

[ovvldc]

Fair point, I just didn't expect it. My point is that 'accessibility' doesn't really connect to microphone or a menu-bar icon to me.

[Gcenx]

 ovvldc, on 21 December 2018 - 10:00 PM, said:

Fair point, I just didn't expect it. My point is that 'accessibility' doesn't really connect to microphone or a menu-bar icon to me.

No you miss understood, microphone is it’s own option.
But yes the current implementation by Apple is terrible