ovvldc

dankoB, on 07 December 2020 - 12:28 PM, said:

It's something thats known and has an open issue on GitHub, think I have that one resolved but currently busy working on Apple Silicon support.
Next version thinking of including DXVK 64Bit support for newer versions of macOS.

Also upstreamed some patches and trying to track down additional wine regressions before Wine-6.0

Added two new Engines for download;
- WS10WineStaging5.1
- WS10WineStaging64Bit5.1



March 8th 2020;
- WS10WineStaging5.3
- WS10wineStaging64Bit5.3
These do function due to applying an upstream fix.

April 2nd 2020;
- WS10WineStaging5.4
- WS10WineStaging64Bit5.4
- WA10WineStaging5.5
- WS10WineStaging64Bit5.5

Please note;
The Runtime package on GitHub was also updated

WS11WineCX19.0.1 contains wine & wine32on64
WS11WineCX64Bit19.0.1 is a wow64 build (wine/wine32on64 & wine64)

The usage is just like standard Wineskin Engines, the size isn’t much larger then a standard WS9/10 Engine due to my relinking the PE executables from /lib into /lib32on64.


For sample I have “Total Annihilation” “Diablo 2 LOD” “Red Alert 2 + YR” and some other games all using WS11WineCX19.0.1 on my Catalina boot drive.

Edit;
Wine32on64 doesn’t support 16Bit executables at this time.

ovvldc, on 18 November 2019 - 06:45 PM, said:

I’ll just say it’s impressive, I’m hoping Beta2 lands soon

Edit;
Since this comment CrossOver19 & 19.0.1 have been released, I’m now providing WineCX19.0.1 Engines that work on macOS Catalina

ovvldc, on 18 December 2019 - 09:54 AM, said:

I wasn’t expecting a response until after the holidays but I got a response.

From the response it’s lightly I need to install an additional dependency to compile wine32on64 (that’s not checked for so no error if it’s missing)

Edit;
Nope that’s not the problem and had to add back my struct patch, time to go play whack-a-mole with wine32on64....

@ovvldc I wonder if you notice the writing pattern matches with someone

CrossOver19, after the release the source hit the same time unlike with the sever hiccup with CrossOver18.5.0 source not being downloadable but was on the server.
Done a wow64 compile without any issue.

wine32on64, now I have the custom llvm/clang-8 compiled as an Xcode toolchain, running another wine32on64 compile as I’d left for work with X11 disabled hopefully that compile completes but who knows how many features I’ll need to disable to get a compile to complete.

Uploaded WS10WineStaging64Bit4.17 I'd forgotten to add the Vulkan tag but it makes little difference anyway.
The new runtime was newly built from macports and updated today. Stipped most unneeded items but left in the XQuartz libs due to being lazy.

If anyone wants instructions on building an updated runtime via macports I can provide instructions even for macOS Mojave users
I have a repository on GitHub with updated versions of wine, wine-crossover, wine-devel a patched libpvx (needed for macOS Mojave universal), a patched cmake (needed for macOS Mojave universal) and custom MoltenVK port (extracts the current Vulkan SDK from LunarG).

I'll get around to building and uploading WS10WineStagingVulkan64Bit4.17 when I get change, it will require an updated Runtime.

Got a little side tracked with some interesting changes within macports.

WS10WineStagingVulkan64Bit4.16 uploaded.

ovvldc, on 16 September 2019 - 02:28 PM, said:

No problem, it’s not had updates in months mind.

We’re already making use of it within https://github.com/P...nicis-winebuild qparis rebased the patches into clang-7 that’s been used to compile wine for macOS for a while now.
It has ms_hook_proludge support so it’s been handy.
We've attempted to use the new -mwine32 but upstream wine is lightly missing some fixes still.

The other day I had to change my scripts for compiling wine directly on macOS again......, something in the current version of Mojave/XCode10 had broke the setup.
Got it working again & even added workarounds for getting the includes/libs detected as I’m not patching all the pc files each time I update them.

doepfer, on 02 September 2019 - 12:30 PM, said:

You won't be playing any newer games using Vulkan builds on macOS for the moment, use Parallels 15 or Bootcamp if you need to play anything above DirectX9.
Unofficial Wineskin thread is posted on this form, the instructions are clear you must use my version of Wineskin.
The ReadMe I provided at request includes includes where to install Engines and how to correctly use the provided Runtimes, it even includes instructions for using the provided Engines outside of Wineskin.

Incredible Hulk, on 02 September 2019 - 12:54 PM, said:

Only tweak I would say is linking to my thread for Unofficial watch the linked video to see why.

doepfer, on 02 September 2019 - 01:13 PM, said:

You didn't use Unofficial Wineskin you tried to use the official release along with Wineskin-2.6.2 that's not compatible with WS10 Engines even if you attempted to replace the Runtime with my provided one (you also didn't install the runtime correctly I gave instructions within the ReadMe on its usage)

Second your wanting to run WoW Classic, use the official client don't attempt to use Wineskin + Vulkan + DXVK as it's not going to work.
Vulkan support that's rather basic is only Vulkan 1.0 compliant (current DXVK needs Vulkan-1.1 or higher) but still missing some extensions needed by older DXVK releases.
MoltenVK AKA Vulkan over Metal requires a minimum of macOS 10.11 to get super basic support, the preferred requirement for wine would be macOS 10.13 or even 10.14. Even better would be 10.15 once wine can run on a pure 64Bit environment due to Metal 3.0 now providing many more extensions natively within Metal so less work for MoltenVK

Incredible Hulk, on 02 September 2019 - 01:56 PM, said:

Don't expect anything from CodeWeavers for Catalina anytime soon.
While we know publicly they are working on a solution to run wine fully on a 64Bit system that work still hasn't made its way into upstream wine, whenever it does I don't expect many people to be able to provide working wine versions for macOS.

Currently the best way to compile wine for macOS isn't on macOS but cross-compiling on Linux.

Incredible Hulk, on 02 September 2019 - 02:47 PM, said:

I'm the reason that patch was added, I provided my log file on compiling wine-4.15 when using 10.11 SDK, the information was passed on that resulted in that patch, however it's not recommended to compile wine using the 10.11 SDK as the Metal support is much lower than would be needed for proper Metal Multi Monitor Support, so instead I updated my Cross-Compiler to using the 10.13SDK and resolved the issues that arose from that SDK change.

Later another patch should be added in relation to unwind giving false positives when installed or using "--without-unwind", that issue was discovered due to the above issue but also in combination when I was having the issue verified with who I usually check in with regarding wine building issues.

I’ve been ill yet again recently.

I did build 4.8 already, then refactored my cross-compiler to make use of a patched version of clang-7 that introduces ms_hook_proludge the item that was missing to build truly Winehq compliment Engines.

Also had to make a change to stop Staging patcher reverting FAudio

Updated FAudio to 19.0.5 *
Added mpg123 (mp3 decoding)
* I lightly won’t ever be making FAudio with wma decoding due to it’s licensing.

Edit;
Need to rebuild 4.8/4.9 again due to an upstream wine change that breaks wine64 if mingw isn’t used.

eierfrucht, on 22 May 2019 - 08:36 AM, said:

We can’t give even a rough estimate as the feature is not even available publicly!
Who knows how many api features need to be emulated still. (If someone did have an idea they wouldn’t be able to post any information until it’s public like after the FF macOS port is released.)

There is a reason Slice shows VKQuake/Cube demo running;
https://github.com/v...mment-421704200

ovvldc, on 22 May 2019 - 08:43 AM, said:

https://github.com/gfx-rs/portability seems to be faster with Dolphin, but Dolphin being an emulator anyway already does strange things with the graphics API, then Vulkan > MoltenVK > Metal.
I would say emulaters are a bad usage case for MoltenVK.



Can we move the discussion to another thread everyone as it’s not directly related to the thread.

I’ve never personally encountered this issue so I needed to do some googling for this one and turned up with a potention reason/answer https://www.codeweav...egas?msg=173973

The GPU detection within Unofficial Wineskin is way more accurate compared to the official release. That’s thanks to Vitor (the PortingKit developer)

The reason I explain about was if you wanted to stick to the official Wineskin release you should set your VRam to 1GB not 2GB as your card has 1.5GB, but your issue isn’t VRam related anyway.



EDIT;
Actually I'm told the game functions on WS10WineCX64Bit18.5.0

ovvldc, on 30 April 2019 - 09:19 AM, said:

I made another folder within MEGA
“W3.0.0v-EngineBase - Compile Test”
- WS10WineStagingGnutls4.7
- WS10WineStagingVulkan64Bit4.7

Unlike the official Winehq release these do have FAudio support plus the usual cmd+q patch.