Closed autumnjolitz closed 2 years ago
I will note that I can only find cef-*
related options in the windows xp CEF binaries
Which I've extracted from steam.exe
and the windows xp cef options here:
https://gist.github.com/autumnjolitz/0fc28db9ffcc29b6ba2b7aff358f96f9
The CEF win7 and CEF win7.x64 binaries only have the following strings matching probable options as:
-gamepadui
-disablejslogging
-verbosejslogging
-delaypageload
-IPCWrapper
-inf
-RESERVELOWMEM
-noassert
-steamdeck
-debugbreak
-nocrashdialog
The default windows OS for the Wineskin appears to be windows 7. I doubt Windows XP would ever be Vulkan friendly. If we try to make Steam think it's only on windows xp, I don't know if it would ever download Win 7 and above binaries for games.
I can confirm that -allosarches
makes no difference in conjunction with the cef options in the wiki (also cited on codeweavers).
I've updated the gist with probable options for cef.win7x64 by extracting common string patterns from chromium on it.
What remains as a question is if any Steam.exe options actually pass them to steamwebhelper.exe
- In my testing, I've checked via ps ax | grep 'steamwebhelper.exe'
the options passed and it has not made a difference.
I've tried the following three options in hopes that steam.exe would pass it to the webhelper.exe:
-disable-gpu-sandbox --disable-gpu-sandbox -cef-disable-gpu-sandbox
A ps ax | grep 'steamwebhelper.exe'
proves that no, cef options are not passed willynilly to the sandbox.
I no longer believe that -cef-force-32bit
does anything for the Steam.exe
launch at all.
Freshly made Steam wrapper Latest wrapper with WS11WineCX64Bit21.2.0 with the following winetricks verbs installed
mfc100
dxvk1103_macOS
w_workaround_wine_bug-22053
w_workaround_wine_bug-44985
andale
arial
comicsans
courier
georgia
impact
times
trebuchet
verdana
webdings
corefonts
steam
w_workaround_wine_bug-50894
ucrtbase2019
vcrun2019
I am attempting to match this — will update soon.
Can you screenshot where your putting the launch options as I don't see them in the provided gist
The direct verbs to call would be
steam
vcrun2019
dxvk1103_macOS
The other should have been vcrun2010
but looks like I clicked the wrong one while quickly throwing this together
It's okay. I obliterated my prior installs so I am creating a wrapper via your route and via my route. Will post the screenshot you asked for when the creates are complete.
Screenshot as asked for:
No wonder your having issues the cli options are in the wrong section see my screenshot
Impressive. "Windows EXE" seemed to semantically mean "Only an executable", not "I am command line path"
I'm going to guess that "Custom commands" is "Run these before (semicolon punctuated to denote multiple) the wine command"?
The Windows EXE
field works just like a windows shortcut can function so the cli options can go directly after the exe.
The Custom Commands:
is for unix env options, in my screenshot I'm enabling my prefered DXVK_HUD options
Verified that your method works provided the arguments are appended after the executable path.
With my install, despite the options added (the options you used) and dxvk installed, it flickers and is still non functional.
This may indicate that letting any steam game install its runtime directx related dependencies may result in a non-functional installation.
On the upside - it appears that verbs "steam vcrun2019 dxvk1103_macOS" does function. I will do additional testing to see if I can isolate which directx or vcrun library causes breakage now that I've a working install.
When I'm done, I hope to make the Wiki more explicit so that others do not confuse "Custom commands" to be like Steam's "Launch options".
Oh, and while winetricks was installing verbs, OSX changed the theme from light to dark, which caused winetricks/wineskin to crash.
Thankfully I made a copy of the install before messing with it to handle consistency issues 😄
Verified verbs faudio vcrun2019 vcrun2013 vcrun2008 vcrun2005 vcrun2012 allfonts
do not destabilize the installation.
This hints that d3dcompiler_47 d3dx11_43 d3dx10_43 d3dx9_43
will probably break the install
Verified verbs
faudio vcrun2019 vcrun2013 vcrun2008 vcrun2005 vcrun2012 allfonts
do not destabilize the installation.This hints that
d3dcompiler_47 d3dx11_43 d3dx10_43 d3dx9_43
will probably break the install
Hum if that’s the case I could account for this in the eventual CX22 Engine.
I got lost in playing Space Marine (x86) now that I’ve a working prototype (turns out verifying the gam cache was critical to repairing the install).
Verbs installed are vcrun2019 vcrun2013 vcrun2008 vcrun2005 vcrun2012 allfonts steam vcrun2019 dxvk1103_macOS
I keep a pristine copy of the working SteamGcenX.app as well to serve as a backup in case of corrupt install.
I did let steam install it’s silly redistributables and didn’t seem to find an issue upon restarting Steam routinely to serve as a sanity check.
Still, I need additional testing to make sure that pollution of the install cannot occur in a normal flow.
I keep the actual games stored in another directory on the system to be added via the “Add Library” option — this allows me to avoid needing to redownload games while making it possible to nuke and adjust the Steam+Wine install.
So far:
I had to disable the steam game overlay. If it is checked, the game binaries will immediately exit without even a splash screen
After disabling that:
Space Marine (x86) works after reverifying app Dishonored (x86) works after reverifying app Black Mesa still doesn’t work (x86-64). Exits immediately after splash screen.
Of note, I had to add -singleapp
to the CLI options as “Test Run” was prematurely returning (after about 10 or so runs — it could’ve been some desync or false positive with the Wineskin) while steam clearly had not exited (and was still bootstrapping) — rather weird but the issue of premature false exiting was solved with that additional option. Perhaps simply adding the option caused Wineskin to behave correctly? I’m not confident that -singleapp
is magic at all. Problem with these things is too many changes made in quick succession can leave you wondering what really works or not.
Have not tried Crysis (x86) or Dishonored 2 (x86-64) yet.
Tomorrow I’ll take the prior pre-game runs working copy, copy it again and try the directX verbs to see if it mangles the install.
Since this issue was resolved and really about Wineskin I’m closing it.
Installed via
brew install --cask --no-quarantine gcenx/wine/unofficial-wineskin
Wineskin: 2.9.1.1 Engine: WS11WineCX64Bit21.2.0 O/S: Big Sur 11.6.8
I've rebuild the wrapper dozens of times and tried the following path:
SteamSetup.exe
Steam.exe
-cef-disable-d3d11 -cef-disable-sandbox -cef-force-32bit -no-cef-sandbox -udpforce -nointro -cef-disable-breakpad -cef-single-process
drive_c/Program\ Files\ \(x86\)/Steam/Steam.cfg
(to disable the auto-updater) -After the above, I've tried to make the steam webviews work without success.
Steam does use
C:\Program Files (x86)\Steam\bin\cef\cef.win7x64\steamwebhelper.exe
(notice the x64 part -- despite asking for a 32bit cef via the option, Steam still uses 64bit CEF)If I install
dxvk1103_macOS
, exiting Steam will hang unless one sends akill
to allsteamwebhelper.exe
's viaps ax | grep steamwebhelper | awk '{print $1}' | xargs kill
.I've noted in the launch log that there's an issue in vulkan initialization: https://gist.github.com/autumnjolitz/d1f448b93078fb7b0ade0f11c8d73f0f#file-steam-log-L1450-L1458
If I do not install
dxvk1103_macOS
(I've also trieddxvk1102_macOS
), thesteamwebhelper.exe
will instead thrash my CPU as it starts a webview, the webview terminates, the webview starts, the webview terminates, etc,. (it loops)Is there a minimum OSX/Hardware version for this to work? I see your reports of the M1 working.
I've tried setting the renderer=opengl via winetricks -- it still keeps trying vulkan.
I'm at a loss for what to do next.