Jump to content

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

Unofficial Wineskin Project


  • Please log in to reply
269 replies to this topic

#211 vskllee

vskllee

    Novice Member

  • Members
  • 5 posts
  • Graphics Card:Radeon HD 4850
  • Operating System:macOS 10.12 (Sierra)

Posted 25 March 2019 - 04:01 PM

hi!I want to ask how to modify the wine menu bar?

#212 Gcenx

Gcenx

    Veteran Member

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

Posted 25 March 2019 - 05:40 PM

 vskllee, on 25 March 2019 - 04:01 PM, said:

hi�I want to ask how to modify the wine menu bar?

As explained before that requires patching and compiling wine from source as such does not fall under Wineskin development.

That's a question for Custom wine build section.

#213 yangm97

yangm97

    Lurker

  • Members
  • 1 posts
  • Graphics Card:HD 3000
  • Operating System:OS X 10.9 (Mavericks)

Posted 14 April 2019 - 09:46 PM

Will directx 10 and above work through MoltenVK when using this wrapper?

#214 RastaFabi

RastaFabi

    Advanced Member

  • Members
  • PipPipPip
  • 59 posts
  • Graphics Card:Intel HD 4000, 1536MB dynamic, shared
    NVIDIA GTX 750Ti, 2048MB, eGPU (Thunderbolt)
  • Operating System:macOS 10.12 (Sierra)

Posted 14 April 2019 - 10:52 PM

 yangm97, on 14 April 2019 - 09:46 PM, said:

Will directx 10 and above work through MoltenVK when using this wrapper?
Please do read the information provided, before asking questions.
This thread‘s opening post clearly states that it's not supported.


Once support is available, which needs to be implemented by the developers of MoltenVK, wine can be compiled to leverage this.
Before that happens no macOS wine implementation whatsoever will be available providing this functionality.
For further information and MoltenVKs implementation status please refer to this bug tracker.

#215 ovvldc

ovvldc

    Master Member

  • Members
  • 1,275 posts
  • LocationEurope
  • Graphics Card:Intel Iris Plus
  • Operating System:Other OS/Not specified
  • I like to play:stories

Posted 16 April 2019 - 07:47 AM

The latest MoltenVK release supports many more functions than the original, so we are probably much closer to DXVK or something like it. But once it works, it will probably use a lot of memory and not be as fast as a native Vulkan driver (much less native Windows).

#216 Gcenx

Gcenx

    Veteran Member

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

Posted 18 April 2019 - 04:18 AM

I pushed a new wrapper update;
  • Working Gnutls
  • Current FAudio built from current head (no wma decoding)
  • MoltenVK taken from latest SDK (1.1.106.0)
  • wine64 used by default on 64bit wrappers
  • font smoothing enabled on wrapper creation


#217 eierfrucht

eierfrucht

    Regular Member

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

Posted 21 May 2019 - 11:34 PM

 ovvldc, on 16 April 2019 - 07:47 AM, said:

The latest MoltenVK release supports many more functions than the original, so we are probably much closer to DXVK or something like it. But once it works, it will probably use a lot of memory and not be as fast as a native Vulkan driver (much less native Windows).
What is the estimated performance hit as compared to native DX? 50%? 25%? 15%? Any rough estimate?

#218 Gcenx

Gcenx

    Veteran Member

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

Posted 22 May 2019 - 03:23 AM

 eierfrucht, on 21 May 2019 - 11:34 PM, said:


What is the estimated performance hit as compared to native DX? 50%? 25%? 15%? Any rough estimate?

There can’t be an estimate until DXVK/VKD3D is functional using MoltenVK.
cdavis5e is the one doing all the work on MoltenVK to support DXVK/VKD3D.

#219 ovvldc

ovvldc

    Master Member

  • Members
  • 1,275 posts
  • LocationEurope
  • Graphics Card:Intel Iris Plus
  • Operating System:Other OS/Not specified
  • I like to play:stories

Posted 22 May 2019 - 07:44 AM

You can follow feature progress here: https://github.com/K...enVK/issues/203

#220 eierfrucht

eierfrucht

    Regular Member

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

Posted 22 May 2019 - 08:36 AM

I follow that, I've even run QuakeVK on Sherry. I wondered if at least a very rough estimate existed, like above 50% or below 50% perf hit...

#221 ovvldc

ovvldc

    Master Member

  • Members
  • 1,275 posts
  • LocationEurope
  • Graphics Card:Intel Iris Plus
  • Operating System:Other OS/Not specified
  • I like to play:stories

Posted 22 May 2019 - 08:43 AM

The fews thing that is that Dota2 was faster on MoltenVK than on OpenGL, and that Dolphin is not. For the latter, I can quote from their progress report: "it's important to note that macOS still has the worst driver situation for Dolphin and it is an inferior platform for emulation in general. Once Apple removes OpenGL support completely, the situation will be even more dire. As nice as MoltenVK support is as an option, it's still slower than OpenGL in many cases and is significantly slower than native Vulkan support. Running Dolphin on Windows via Bootcamp is still our recommended way to get the best possible Dolphin experience from a macOS machine."

No idea how Wine/DXVK over MoltenVK is performing but I am not holding my breath right now...

We shall see if anything becomes easier at WWDC.

#222 Gcenx

Gcenx

    Veteran Member

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

Posted 22 May 2019 - 11:39 PM

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

I follow that, I've even run QuakeVK on Sherry. I wondered if at least a very rough estimate existed, like above 50% or below 50% perf hit...

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:

The fews thing that is that Dota2 was faster on MoltenVK than on OpenGL, and that Dolphin is not. For the latter, I can quote from their progress report: "it's important to note that macOS still has the worst driver situation for Dolphin and it is an inferior platform for emulation in general. Once Apple removes OpenGL support completely, the situation will be even more dire. As nice as MoltenVK support is as an option, it's still slower than OpenGL in many cases and is significantly slower than native Vulkan support. Running Dolphin on Windows via Bootcamp is still our recommended way to get the best possible Dolphin experience from a macOS machine."

No idea how Wine/DXVK over MoltenVK is performing but I am not holding my breath right now...

We shall see if anything becomes easier at WWDC.

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.

#223 vanhouten

vanhouten

    Experienced Member

  • Members
  • PipPip
  • 23 posts
  • Graphics Card:AMD Radeon RX 580
  • Operating System:Other OS/Not specified

Posted 23 May 2019 - 02:14 PM

Hello,

I was wondering if there was a way to make Wineskin wrappers work with BetterTouchTool ? I mean at an application level (not global). Mouse gestures work at a global level but it's not very handy. I can make ControllerMate work by switching from "running in foreground" to "running" but BTT doesn't have this option (probably not the best way though).

#224 ovvldc

ovvldc

    Master Member

  • Members
  • 1,275 posts
  • LocationEurope
  • Graphics Card:Intel Iris Plus
  • Operating System:Other OS/Not specified
  • I like to play:stories

Posted 23 May 2019 - 06:22 PM

Also a separate topic? (I have no answer to the original question)

#225 RastaFabi

RastaFabi

    Advanced Member

  • Members
  • PipPipPip
  • 59 posts
  • Graphics Card:Intel HD 4000, 1536MB dynamic, shared
    NVIDIA GTX 750Ti, 2048MB, eGPU (Thunderbolt)
  • Operating System:macOS 10.12 (Sierra)

Posted 29 May 2019 - 11:57 PM

Now that the first development release of macOS 10.15 is close, and the public beta should follow within two weeks, what is your plan regarding your unofficial Wineskin fork?
CodeWeavers pledged to incorporate a wine32 on wine64 wrapper while also promising DX11 support via DXVK (DX9 via D9VK), via Vulkan, via MoltenVK (GL via Vulkan, via MoltenVK?). This somewhat indicates, that the wine/engine site of things should be covered midterm.
Supposedly Apple does not incorporate further fundamental api changes, do you think your current builds of Wineskin will just work? Might it be necessary to stripe down all the 32bit library and executable parts in order to work altogether, implying the need to maintain a pre 10.15 and a 10.15 fork separately? Or might this required a major code rewrite altogether? (NSTask?)
Do you even plan continuing support with apple ramping up those new hurdles?
Would be great to get some developer-perspective on this.

Thank you for all your work (and Vitor’s) done so far, as it’s safe to say you guys are one of the main drivers of current Mac gaming.

—————
https://www.phoronix...-Alpha-Released
https://github.com/K...enVK/issues/203
https://www.codeweav...t=27;msg=212891

#226 Gcenx

Gcenx

    Veteran Member

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

Posted 30 May 2019 - 01:06 AM

 RastaFabi, on 29 May 2019 - 11:57 PM, said:

Now that the first development release of macOS 10.15 is close, and the public beta should follow within two weeks, what is your plan regarding your unofficial Wineskin fork?
CodeWeavers pledged to incorporate a wine32 on wine64 wrapper while also promising DX11 support via DXVK (DX9 via D9VK), via Vulkan, via MoltenVK (GL via Vulkan, via MoltenVK?). This somewhat indicates, that the wine/engine site of things should be covered midterm.
Supposedly Apple does not incorporate further fundamental api changes, do you think your current builds of Wineskin will just work? Might it be necessary to stripe down all the 32bit library and executable parts in order to work altogether, implying the need to maintain a pre 10.15 and a 10.15 fork separately? Or might this required a major code rewrite altogether? (NSTask?)
Do you even plan continuing support with apple ramping up those new hurdles?
Would be great to get some developer-perspective on this.

Thank you for all your work (and Vitor’s) done so far, as it’s safe to say you guys are one of the main drivers of current Mac gaming.


Unofficial Wineskin, is already 64Bit (except wsgamma due to no source code) so the application is ready.

CodeWeavers are working on at least two solutions that I'm aware of, one being Hangover, a patched pure wine64 with included custom qemu to handle 32bit applications/games.
Option 2, (patch?) and compile using a custom version of clang that had built in trunking support so 32Bit process will be ran on 64Bit threads. The resulting wine would be like now wine/wine64 but running as 64Bit. < The version I would prefer.

I've been building wine with MoltenVK support since it was possible so once DXVK runs we can use it with a WS10 Engine, so if later they want to us MoltenGL or some other weirdness if it works it can be built into an Engine.

The NSTask thing is more for passing permissions on correctly from Wineskin > wine processes.
I don't think I will need to fork the project for macOS 10.15, the problem is wine more than anything else (maybe some extra checks to disable all but WS11 Engines to be safe lol)

I don't want to use Hangover but I'm willing to build Hangover Engines if needed, Unofficial Wineskin already launches wine64 if it found over wine already.


I plan to keep supporting the project as long as possible, I don't want to fork into different versions unless it's unavoidable for now I would just need to disabled using WS10 and lower Engines on macOS 10.15 once it's launched.

#227 ovvldc

ovvldc

    Master Member

  • Members
  • 1,275 posts
  • LocationEurope
  • Graphics Card:Intel Iris Plus
  • Operating System:Other OS/Not specified
  • I like to play:stories

Posted 30 May 2019 - 07:29 AM

I understand that having to maintain their own compiler is a big reason why Codeweavers is hesitant on option 2. I wonder if that options would be helpful for other use cases. Ideally, it would be upstreamed in LLVM/Clang with unit tests so that they keep it in mind when advancing their codebase.

#228 Gcenx

Gcenx

    Veteran Member

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

Posted 30 May 2019 - 12:19 PM

 ovvldc, on 30 May 2019 - 07:29 AM, said:

I understand that having to maintain their own compiler is a big reason why Codeweavers is hesitant on option 2. I wonder if that options would be helpful for other use cases. Ideally, it would be upstreamed in LLVM/Clang with unit tests so that they keep it in mind when advancing their codebase.

Hangover is more aimed at arm64 devices, that it could work for macOS is another matter, calling outside of the included emulator gives major slowdowns (mentioned at the last wine conference)

Maintaining a custom compiler, well they already maintain winegcc, a patched clang for macOS cross-compiling, now mingw-w64 and Winehq both already share a lot of code already.

During the last wine conference they only shown Hangover running on the Nvidia sheild but did explain the other the custom compiler version.
Hangover slows down if calling outside of the emulator and on some applications/games that’s constantly if they use 32bit & 64Bit library’s.

Wine compiled to run 32Bit on 64Bit threads using trunking ran at almost native speeds as a 32bit compile, also none of the slowdown from emulation.
The trunking is mostly already baked into LLVM the customizations to clang are to add the ability to use it for x86 code (some other things but I’m sure but I only quickly looked over the commits)

From my perspective Hangover if used would be crippling wine on macOS even more the it currently is, also considering CodeWeavers makes a large cunk of revenue from Porting services (Currently one that got mentioned publicly was a FF game that will be using DXVK in the macOS port!)

#229 ovvldc

ovvldc

    Master Member

  • Members
  • 1,275 posts
  • LocationEurope
  • Graphics Card:Intel Iris Plus
  • Operating System:Other OS/Not specified
  • I like to play:stories

Posted 01 June 2019 - 06:33 PM

Fully emulating would be crippling. I can imagine a scenario where JIT recompiling makes sense and doesn't slow down too much when going from 32bit to 64bit as they are roughly the same instruction set, but it will still cost memory and CPU cores.

But if they have a patched clang anyway, they can add this as well. As long as Intel and AMD still support the 32bit instructions anyway ;)

#230 Gcenx

Gcenx

    Veteran Member

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

Posted 01 June 2019 - 11:25 PM

 ovvldc, on 01 June 2019 - 06:33 PM, said:

Fully emulating would be crippling. I can imagine a scenario where JIT recompiling makes sense and doesn't slow down too much when going from 32bit to 64bit as they are roughly the same instruction set, but it will still cost memory and CPU cores.

But if they have a patched clang anyway, they can add this as well. As long as Intel and AMD still support the 32bit instructions anyway ;)

I will properly build hangover tomorrow and give it a try myself lets see if it's usable or not before I go making changes to WineskinLauncher to accommodate it.

But yeah I'm sure clang will be used over hangover for macOS, since hangover was more aimed at ppc arm devices

Edit;
Well looks like I can skip building it myself for the moment, qparis build it and uploaded a build, I did some tests and it’s honestly not very useful in its precent build configuration.

#231 RastaFabi

RastaFabi

    Advanced Member

  • Members
  • PipPipPip
  • 59 posts
  • Graphics Card:Intel HD 4000, 1536MB dynamic, shared
    NVIDIA GTX 750Ti, 2048MB, eGPU (Thunderbolt)
  • Operating System:macOS 10.12 (Sierra)

Posted 05 June 2019 - 08:16 PM

Hi @Gcenx, I just wanted to report, that your wineskin fork apparently is working fine on macOS Catalina.
While I did not test existing wrappers I created a new one with a 64bit engine (4.7). Wineskin proceeded to create the wrapper and I did launch wineconfig.exe, regedit.exe and some more tools. Checking the wine environment I found the expected: syswow64 (the 32bit directory :huh:) is empty, as the 32bit wine process setting it up just did not run.

#232 Gcenx

Gcenx

    Veteran Member

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

Posted 06 June 2019 - 01:08 AM

 RastaFabi, on 05 June 2019 - 08:16 PM, said:

Hi @Gcenx, I just wanted to report, that your wineskin fork apparently is working fine on macOS Catalina.
While I did not test existing wrappers I created a new one with a 64bit engine (4.7). Wineskin proceeded to create the wrapper and I did launch wineconfig.exe, regedit.exe and some more tools. Checking the wine environment I found the expected: syswow64 (the 32bit directory :huh:) is empty, as the 32bit wine process setting it up just did not run.

Yeah since on prefix creation wine couldn't function so
wine wineboot
would have failed but
wine64 wineboot
would have functioned.

I recently make sure to have Wineskin default to using wine64 over wine when available, I had the same results when testing on Mojave with 32bit mode disabled.
Still I'm a little surprised it even worked at all considering all the engines other then then the CX ones are from winehq.


If you replace the wswine.bundle contents with a pure 64Bit compile and rebuild the wrapper (ignoring the error about wine) it will function.
When I have some time I might do a proper set of updates more aimed at Catalina

If you would like a pure64 compile to play with let me know I can thrown one together.

Edit;
I should explain a little more, even if you compile wine as only 64Bit you will get the exact same results as you experienced here, the syswow64 directory and other 32bit folder will still get created by using “wine64 wineboot”

#233 Shiningalex

Shiningalex

    Novice Member

  • Members
  • 6 posts
  • Graphics Card:HD4000
  • Operating System:macOS 10.12 (Sierra)

Posted 12 June 2019 - 10:10 AM

Thanks for this. I can't wait to try it out.

#234 vskllee

vskllee

    Novice Member

  • Members
  • 5 posts
  • Graphics Card:Radeon HD 4850
  • Operating System:macOS 10.12 (Sierra)

Posted 19 July 2019 - 03:18 AM

Does it support macos10.15?

#235 Gcenx

Gcenx

    Veteran Member

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

Posted 13 August 2019 - 02:24 AM

 vskllee, on 19 July 2019 - 03:18 AM, said:

Does it support macos10.15?

No.

#236 vicmarto

vicmarto

    Lurker

  • Members
  • 1 posts

Posted 24 December 2019 - 05:28 AM

Hello.

Can't get it to work with Clrmamepro 64 bits 4.036a (Wineskin Winery-1.8.3, Wineskin-2.9.0.4 and WS9Wine64Bit4.21 under Catalina). Even creating a cmpro.ini file like the download page suggest.

Clrmamepro shows the welcome screen and after click [Accept] nothing happens.

This is the log:

0009:fixme:msg:ChangeWindowMessageFilter 233 00000001
0009:fixme:msg:ChangeWindowMessageFilter 4a 00000001
0009:fixme:msg:ChangeWindowMessageFilter 49 00000001
0009:fixme:nls:GetThreadPreferredUILanguages 00000038, 0x21f914, 0x21f930 0x21f910
0009:fixme:nls:get_dummy_preferred_ui_language (0x38 0x21f914 0x21f930 0x21f910) returning a dummy value (current locale)
wine: Unhandled page fault on read access to 0000000000000020 at address 0000000140439656 (thread 002a), starting debugger...
002a:err:seh:start_debugger Couldn't start debugger L"false" (2)
Read the Wine Developers Guide on how to set up winedbg or another debugger
/Users/XXXXXX/Applications/Wineskin/cmp64.app/Contents/Frameworks/wswine.bundle/lib64/../bin/wine64-preloader: line 2: 12826 Terminated: 15		  DYLD_FALLBACK_LIBRARY_PATH="${WINESKIN_LIB_PATH_FOR_FALLBACK}" "$(dirname "$0")/cmp642272872Wine64-preloader" "$@"

Any suggestions please?

#237 Gcenx

Gcenx

    Veteran Member

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

Posted 27 December 2019 - 03:26 AM

View Postvicmarto, on 24 December 2019 - 05:28 AM, said:

Hello.

Can't get it to work with Clrmamepro 64 bits 4.036a (Wineskin Winery-1.8.3, Wineskin-2.9.0.4 and WS9Wine64Bit4.21 under Catalina). Even creating a cmpro.ini file like the download page suggest.

Clrmamepro shows the welcome screen and after click [Accept] nothing happens.

This is the log:

0009:fixme:msg:ChangeWindowMessageFilter 233 00000001
0009:fixme:msg:ChangeWindowMessageFilter 4a 00000001
0009:fixme:msg:ChangeWindowMessageFilter 49 00000001
0009:fixme:nls:GetThreadPreferredUILanguages 00000038, 0x21f914, 0x21f930 0x21f910
0009:fixme:nls:get_dummy_preferred_ui_language (0x38 0x21f914 0x21f930 0x21f910) returning a dummy value (current locale)
wine: Unhandled page fault on read access to 0000000000000020 at address 0000000140439656 (thread 002a), starting debugger...
002a:err:seh:start_debugger Couldn't start debugger L"false" (2)
Read the Wine Developers Guide on how to set up winedbg or another debugger
/Users/XXXXXX/Applications/Wineskin/cmp64.app/Contents/Frameworks/wswine.bundle/lib64/../bin/wine64-preloader: line 2: 12826 Terminated: 15		  DYLD_FALLBACK_LIBRARY_PATH="${WINESKIN_LIB_PATH_FOR_FALLBACK}" "$(dirname "$0")/cmp642272872Wine64-preloader" "$@"

Any suggestions please?

This thread isn’t the place to ask for help in regards to getting software working with wine, this is for Wineskin issues.

I’d tried the software in question on CrossOver19 and it also doesn’t work this isn’t a Wineskin issue, you should try to reach out to the softwares developer for help.

#238 SomeRandomDude

SomeRandomDude

    Lurker

  • Members
  • 2 posts
  • Graphics Card:Intel UHD630 & AMD 560X
  • Operating System:Other OS/Not specified

Posted 18 January 2020 - 10:49 PM

Thanks for all the efforts to keep Wineskin going.

I'm trying to make Sid Meier's Alpha Centauri work on Mojave. (It's rated platinum at WineHQ, so I didn't expect much trouble.) I downloaded your unofficial 1.8.3 Winery, used wrapper 2.9.0.5, then tried a number of engines.

Some recent engines (at least 4.20staging) wouldn't work at all - there was some 64/32 issue which I didn't delve into. WS10WineCX18.5.0 seemed to be OK. WS9Wine3.21 behaved identically to the CX version.

But now I have a problem... The app starts fine, intro cinematics play fine (and at some length!). But when the game's start screen opens, offering to start/load/multiplayer/quit, it works fine for about 3-4 seconds. And then the video stops updating. But it's still running. If i click something with the mouse, it registers and the game does what it should, it just doesn't update the display. I know this because if I cmd-tab to MacOS Finder, then back into the game, the screen shows the new state. And the screen works again, for another 3-4 seconds, and then it stops updating again. It's as if it's double-buffering, and the task copying the 2nd buffer to the video buffer is just stopping.

A small possibly related issue is that the mouse always looks like the standard MacOS pointer. I'm pretty sure the game has its own idea of what the mouse cursor should look loke but I'm not seeing it.

Changing the windows version in winecfg to XP or 98 from 7 made no difference.

My first attempt at debugging this is the one part of this that I'm certain belongs in this forum: I tried to switch to rootless/windowed mode. But hey, guess what, that setting no longer exists where it did in official Wineskin. Argh. I looked in winecfg's Graphics tab, and it does seem to offer similar functionality. But... it doesn't actually work. That is, when I turn on "Emulate a Virtual Desktop", hit apply and then OK, when I go back into winecfg that setting has not been preserved. And if I change the desktop size that setting isn't preserved either.

So then I went into the "Applications" tab and made an entry for "terran.exe" (the exe I'm running). If I select that and then turn on "Emulate a Virtual Desktop" in Graphics, that setting does stick (though the screen size still does NOT). But... this setting seems to have no effect. If I launch terran.exe, it still goes full-screen.

FWIW, "terranx.exe" (the expansion game) behaves the exact same way.

I really have no clue where to go from here. Help please?

#239 SomeRandomDude

SomeRandomDude

    Lurker

  • Members
  • 2 posts
  • Graphics Card:Intel UHD630 & AMD 560X
  • Operating System:Other OS/Not specified

Posted 18 January 2020 - 11:32 PM

View PostSomeRandomDude, on 18 January 2020 - 10:49 PM, said:

I'm trying to make Sid Meier's Alpha Centauri work on Mojave.
So as an experiment, I installed MOO2 into the same wineskin. It launches and works fine, without the display freezing. Though if I switch away and switch back, I get no display at all. Turns out that's a DosBox game though, so I'm not sure I proved anything. :-/

Oh, I did prove one thing: Despite configuring it for windowed mode, it still launched full-screen. Unless DosBox can somehow get around that too, in which case it was really a waste of time.

#240 Gcenx

Gcenx

    Veteran Member

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

Posted 19 January 2020 - 03:49 AM

View PostSomeRandomDude, on 18 January 2020 - 10:49 PM, said:

Thanks for all the efforts to keep Wineskin going.

I'm trying to make Sid Meier's Alpha Centauri work on Mojave. (It's rated platinum at WineHQ, so I didn't expect much trouble.) I downloaded your unofficial 1.8.3 Winery, used wrapper 2.9.0.5, then tried a number of engines.

Some recent engines (at least 4.20staging) wouldn't work at all - there was some 64/32 issue which I didn't delve into. WS10WineCX18.5.0 seemed to be OK. WS9Wine3.21 behaved identically to the CX version.

But now I have a problem... The app starts fine, intro cinematics play fine (and at some length!). But when the game's start screen opens, offering to start/load/multiplayer/quit, it works fine for about 3-4 seconds. And then the video stops updating. But it's still running. If i click something with the mouse, it registers and the game does what it should, it just doesn't update the display. I know this because if I cmd-tab to MacOS Finder, then back into the game, the screen shows the new state. And the screen works again, for another 3-4 seconds, and then it stops updating again. It's as if it's double-buffering, and the task copying the 2nd buffer to the video buffer is just stopping.

A small possibly related issue is that the mouse always looks like the standard MacOS pointer. I'm pretty sure the game has its own idea of what the mouse cursor should look loke but I'm not seeing it.

Changing the windows version in winecfg to XP or 98 from 7 made no difference.

My first attempt at debugging this is the one part of this that I'm certain belongs in this forum: I tried to switch to rootless/windowed mode. But hey, guess what, that setting no longer exists where it did in official Wineskin. Argh. I looked in winecfg's Graphics tab, and it does seem to offer similar functionality. But... it doesn't actually work. That is, when I turn on "Emulate a Virtual Desktop", hit apply and then OK, when I go back into winecfg that setting has not been preserved. And if I change the desktop size that setting isn't preserved either.

So then I went into the "Applications" tab and made an entry for "terran.exe" (the exe I'm running). If I select that and then turn on "Emulate a Virtual Desktop" in Graphics, that setting does stick (though the screen size still does NOT). But... this setting seems to have no effect. If I launch terran.exe, it still goes full-screen.

FWIW, "terranx.exe" (the expansion game) behaves the exact same way.

I really have no clue where to go from here. Help please?

The game according to Winehq is platinum for 4.15 on Linux anyway, but as I provide winehq releases bar my WineCX builds who know but I don’t give support for an individual games/applications this thread is really for development of Wineskin/WineskinLauncher/Winery.

The reason Virtual Desktop doesn’t work is due to the removal of WineskinX11, this is mentioned on the first post. If you require Virtual Desktop you need to install XQuartz onto your system and set X11 as your display driver.

View PostSomeRandomDude, on 18 January 2020 - 11:32 PM, said:

So as an experiment, I installed MOO2 into the same wineskin. It launches and works fine, without the display freezing. Though if I switch away and switch back, I get no display at all. Turns out that's a DosBox game though, so I'm not sure I proved anything. :-/

Oh, I did prove one thing: Despite configuring it for windowed mode, it still launched full-screen. Unless DosBox can somehow get around that too, in which case it was really a waste of time.

As I’ve said above and is posted on the first post, you need XQuartz installed to use X11 display driver and things like Virtual Desktop.

Also DosBox has the ability to run in windowed mode on its own. I’ve ran Duke Nukem 3D from GOG and used it’s included Window mode without issue, I believe it included a Windows Mode launch option.


If you find an issue running games/software ensure it’s not a wine problem, your able to use “Command Line Wine Test” to launch terminal with the included Engine set and will function like a winehq release.
Then test the game/software again to ensure it’s really a Wineskin configuration error or just incompatible wine/Engine version.

Also if Winehq lists software as platinum use the same wine/Engine version, however if no mac results are listed saying platinum I be wary of the listed status.




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users