I added a new version of FSR 4.1.2 Lite and achieved maximum performance (at least for int8 calculations)(m5-m6)

I also made sure that FSR 4 could be easily downloaded, because last time I got criticized for having a “complicated installation”

I’ll also explain why this is necessary - FSR 3 is just an algorithmю it tries to hide the fact that the resolution is poor. FSR 4 is AI that adds details, and it looks much more like the original resolution. You can watch a video comparing FSR 3 and FSR 4. many people say it’s better to set FSR 4 to performance rather than FSR 3 to quality

In terms of FPS, FSR 4 at balance provides roughly the same FPS as FSR 3 at quality (on m5)

https://github.com/UzenUPoZiTiV4ik/fsr4-native-macos

First download the fh2 port from github who did the forza horizon 2 port and get it configured to run...*NOT MY PROJECT so support the original creator for this amazing translation layer*

https://github.com/fladnaG86/FH2-Port-AppleSilicon/releases/tag/v0.1.7

then go to the fh2 port application and click show packet contents and place file as shown in last picture and paste the d3d12.dll to new one downloaded from link below

https://drive.google.com/file/d/1512kECKDzswmY0T3sR0QNZWU4FoJsRsQ/view?usp=drivesdk

NOTE-

may crash if no controller detected

may crash if graphics changed except antialiasing

Performance is great otherwise...similar to fh2

BRING YOUR OWN GAMES...NO GAME FILES

[Now currently trying to run fm5 and fh3 too similarly]

Metro 2033 Redux (next-gen build): CrossOver / D3DMetal launch crash fix

A tiny dinput8.dll proxy that fixes the next-gen build of Metro 2033 Redux crashing a couple of seconds after launch in CrossOver with D3DMetal:

Unhandled page fault on read access to 0000000000000000 at address 0000000140831E55

Cause

The next-gen build renders in DirectX 11 but runs DLSS/FSR on a separate DirectX 12 device, joined by a DX11→DX12 bridge. That bridge needs D3D11 extended resource sharing, and D3DMetal doesn't support it, so the bridge fails. The game correctly marks DLSS as unavailable, but then runs FSR setup anyway, calls into a DX12 device that was never created, and crashes on a null pointer.

The FSR setup function only checks its own run-once flag. The game's bridge-failed flag sits two bytes after it in memory. Changing the compare's opcode from 0x80 to 0x83 widens it from one byte to four (cmp byte → cmp dword), so it also sees the bridge-failed flag and skips FSR setup. Both versions of the instruction are 7 bytes long, so nothing else moves.

This is the same bug and the same fix as the one found for Metro Last Light Redux. In 2033 Redux the instruction is at RVA 0x831E1F:

80 3D F5 31 7A 00 00 48 8B D9 0F 85    ->    83 3D F5 31 7A 00 00 48 8B D9 0F 85

Why a DLL instead of a hex edit

Note: if you have a DRM free version you can directly change the bytes in metro.exe

2033 Redux's metro.exe is wrapped in Steam's DRM (SteamStub), and all of its code is encrypted on disk. A hex editor can't find the bytes, and editing the encrypted bytes would just corrupt the exe.

The DLL does the same one-byte change in memory, after the game has decrypted itself:

• It forwards DirectInput8Create, the only function the game imports from dinput8, to Wine's real dinput8.dll.
• On load, it starts a thread that waits until all 12 expected bytes are present, then flips 80 to 83. If the bytes never match, it changes nothing.
• It writes metro2033_fsr_fix.log next to metro.exe on each launch.

The exe on disk and the DRM are untouched, so Steam file verification won't remove it.

Install

1. Quit the game.
2. Copy dinput8.dll into the game folder, next to metro.exe. link
3. In CrossOver, select your Steam bottle, open Wine Configuration, go to the Libraries tab, add dinput8, and set it to Native then Builtin.
4. Launch the game from Steam.
5. Check metro2033_fsr_fix.log in the game folder. It should say patched after N ms.

To uninstall, delete dinput8.dll and remove the dinput8 override.

In-game settings

FSR setup is skipped, and DLSS and MetalFX aren't available. Use TSR for upscaling or anti-aliasing.

Compatibility

Built for the metro.exe with this SHA-256 (check with shasum -a 256 metro.exe):

7c35095f27beab83b31914029eca0da07991bba8630ec12ba97eec43ffc60c38

If a game update changes the exe, the log will say expected bytes never appeared (different build?) - not patching, and the crash will come back. The new offset then needs to be found and the DLL rebuilt.

dinput8.dll SHA-256:

b4be51d011b245aca8969e4d55eb42bf05055682f740176f8aed82cd7816f27c

Tested on an M4 Pro with 24 GB, CrossOver 26.3, and the D3DMetal backend.

Build from source

dinput8.c is the full source, about 80 lines. Please read it before running a DLL from the internet.

brew install mingw-w64
x86_64-w64-mingw32-gcc -O2 -shared -s -static-libgcc -o dinput8.dll dinput8.c -Wl,--kill-at

Credits

The root-cause analysis and the 0x80 → 0x83 fix come from the Metro Last Light Redux CrossOver writeup. This project ports that fix to 2033 Redux and applies it at runtime because of SteamStub.

Let me know if there is a recomp or something thank you

Just wanted to share my experience with MuMuPlayer Pro on Mac, because this whole process has been pretty frustrating.

I paid $72 for an annual subscription on April 24, 2026. That same day, the game I wanted to play kept closing with an “Illegal program has been detected! (110/0)” error. I reported it to support right away and said I wanted a refund if they couldn’t fix it promptly.

They asked for evidence, so I sent it over. After that, I kept following up for months. I asked for updates, asked how long the review would take, and even asked if there was another official support channel I should use. As late as September 2, I was still being told it was under review.

Then, on October 11, they told me refunds weren’t supported. No clear explanation of why my particular request was being refused after all that waiting.

Later that same day, I put all the evidence and the history of my case together again and sent another detailed message asking them to reconsider. All I got back was: “We’re very sorry for the inconvenience. Customer service will forward your latest request to our team today.” That’s my translation of their reply in Korean.

It’s now October 28, and I haven’t heard anything since. No update, no explanation, nothing. After months of following up, I’m honestly pretty pissed off. I went through the trouble of laying everything out again, only to get another “we’ll pass it along” and then silence for over two weeks. I genuinely don’t understand how they think this is an acceptable way to treat a paying customer.

I also tried PayPal, but my dispute was rejected because it was filed more than 30 days after the service was provided. So waiting for the seller’s review didn’t protect me from PayPal’s deadline.

That’s the part that really bothers me. This wasn’t a refund request I suddenly made months after buying it. I raised the issue on the day I paid. I sent the requested evidence and kept asking for updates while support said they were reviewing it.

I don’t know why it took so long, and I’m not saying they deliberately dragged it out. But nearly six months of waiting just to be told no, without a clear explanation, is pretty hard to accept.

Has anyone else dealt with something similar with MuMuPlayer Pro? Did you manage to get a proper response from anyone?

I've had some experience with running other games via PortingKit, but when I tried to run bedrock, it just loaded up the MC terminal and then crashed, so I likely did something wrong on launch. Is there a specific tutorial for this?

I just used the default settings and selected the MC.exe launcher.

iMac 2021 Sonoma 14.1

I'm running DOS2 from steam. The game is on an external SSD drive and every time I start the game MacOS runs verifying. And it takes forever which I think is because I'm using a crappy slow speed cable at the moment.

I haven't been gaming on this computer in about a year or so but it didn't use to do this in the past. Anyone know why? I have allowed full disk access to steam

Need tips to improve the native performance

https://youtu.be/fa4LN-wpZZk

I thought C2077 would be unplayable on my M1 Mini/16 GB, but I was wrong, this port is incredible. I even pushed it a little too far with 1080p resolution; there were some FPS drops here and there, but the fact that this works on the first M chip is crazy.

Can someone help

Access it here: https://github.com/metalsharp/MetalSharp-Wine

Use it in MetalSharp 1.0.0 (7 Months in the Making); https://github.com/metalsharp/MetalSharp/releases/tag/v1.0.0

As usual, thanks for the work Crossover does on Wine to make this possible.

Metalsharp Wine is an Arm64 / Aarch64 / Arm64EC / X86_64 / I386 & WoW64 Wine 11.20 that runs x86_64 and I386 & WoW64 through FEX, requiring no Rosetta to run. It is developer signed / notarized, working on MacOS 26.4 and beyond. It is currently in an early-access state.

Graphics Routes:

- Metalsharp-Developed VKD3D-Proton D3D12 on MacOS with a custom built universal MoltenVK 1.4.3; Tested games include Dragon's Dogma 2, God Of War Ragnarock, PEAK, and more on FL 12_2. Someone got Minecraft bedrock working with this.

- Mullion (Dxmt Fork) including D3D12 FL 12_2 Support, running D3D12 / 11 / 10. It has been tested against God of War Ragnarock, PEAK, Red Dead Redemption 2, and more.

- GcenX Dxvk-Macos; DXVK for MacOS rebuilt as Arm64x dlls for D3D11 / 10 / 9 through Vulkan -> Metal.

- OpenGL: WineMetalGL 3.7.0 for OpenGL 1.0 -> 4.6 on Metal for Older games, including GLES 2 -> 3.2 support.

Included Features;

- Pairs with WineForge to provide Rockstar Launcher / Ubisoft Connect / Battle Net loading (WFDXCompat), Mouse / Full-screen Wine issue fixes, and WFUSync (upgraded Msync).

- Ffmpeg and Gstreamer

- Gecko / Inno-Extract / Java support for normal Windows programs.

- Msync (WFUsync) / Reduced x87 Precision enabled by default.

- Wine Mono 11.3.0 for .Net

- Controller support (Xinput / Dinput)

And much more.

Credits;

Gcenx DXVK - MacOS: https://github.com/Gcenx/DXVK-macOS

WineForge; https://github.com/Alien4042x/WineForge

VKD3D-Proton MacOS: https://github.com/metalsharp/VKD3D-Proton-MacOS

Mullion: https://github.com/dttdrv/mullion

WineMetalGL: https://github.com/metalsharp/WineMetalGL

As usual, it will be free to use, forever. I hope this helps some people and this is my way of giving the community something new and working, without a single dollar needed from your pockets. This is what I love to do. It's that simple. However, I expect to see downvotes for free and open sourced work, and I refuse to be bothered.

I was watching andrew tsais video on the god of war 3 port and he said that he is aware that there is another port called "spartan port" (is what I think I heard) that runs far better on even older M-series chips than the method he shows in the video, however I cannot find any mac related port associated with "spartan port" (maybe I just heard it wrong) so could someone clarify please.

I am on an M4 air with 16gb of ram

Wanted to see if a base Mac mini could handle Ghost of Tsushima, and it actually runs. I made a video showing the whole setup.

My setup:

• Mac mini M4, 16GB unified memory, 256GB SSD
• CrossOver 26.3
• F16C fix from PCGamingWiki (without it the game won’t get past the start)

What worked for me:

• Medium graphics settings
• FSR instead of DLSS, since DLSS gave me weird colour issues
• Frame Generation and Dynamic Resolution Scaling OFF during the first katana pickup animation. Once that works properly you can try turning them on.

Performance will vary depending on your Mac, settings and CrossOver version, so this is just what worked on my machine.

Full walkthrough (setup, the fix, settings): https://youtu.be/J7rb-lJUyoU
F16C fix: https://community.pcgamingwiki.com/files/file/3122-ghost-of-tsushima-f16c-instructions-fix/

If you try it on a different Mac, tell me how it runs. I’m curious how it does on M1/M2/M3 and on 8GB machines.

I am seeing a ton of post and videos of vibe coded mac native ports of games

But i never see detailed info about it is so dam annoying, like anyone care explaining the current situation about these ports? And the current situation of mac native ports? Like the botw and totk native ports, and other platform games ports

Do they run well without stuttering freezes or visual artifacts/glitches ??

Can they be run from start to finish until completed 100%, or the game is gonna brake at some point ?

Wich games really work 100%? Does it even worth the effort to do it? Or the technology is so young that its like Quality Testing rn?

Its so annoying to be flood with these native ports and tools but no info about if they run like their native counterpart, problems, performance issues etc

Due to the lack of this i havent even tried any of those ports i feel they are just garbage and waste of time, every single one of them

Not to mention that people have lost their files, erased their folders or similar bad problems trying to run them

I figured out a way to run this thing on CrossOver 26.3 with Ultra Texture pack installed and all functional (it is feeding to the game) but the textures still come out very soft. Anyone get this going properly? Tried every setting imaginable

The game runs like a charm but I can’t find the setting for Ultrawide aspect ratio

Hi Team,

You helped me out 5 years ago, and I'm hoping you can pull through once again.

As the title states, I cannot open League of Legends on my mid-2014 Macbook Pro running Big Sur 11.7.11.

When I click on the League of Legends icon, it bounces once, and the little Riot first icon appears briefly on the top bar of my Mac (where the volume, battery symbol, wifi symbol etc. are), then disappears.

I've restarted my computer a few times, and I've downloaded the "Install League of Legends oc1 file", opened it, clicked install, and a little window pops-up saying "repairing" underneath. But nothing happens.

I'm not very computer savvy so would appreciate any other tips.

Thank you :)

Hi guys!

Can someone help me to try to fix snowrunner on Mac? The game crash while loading.

Ive tried everything. Here some teste I did:

What was analyzed (measured)

Dump (Saber's CrashDump.dmp): exception c0000005, write to address 0, at SnowRunner.exe+0x17BC07B. It is a deliberate abort (mov dword ptr [0],1) from the free() validator of the game's allocator (dlmalloc-style; mstate at 0x142b29090, least_addr at 0x142b290a8). Freed pointer: 0x9ee0600 (rbx=0x9ee05f0). Variants: +0x1770d64 (mov eax,[rbx-8], rbx=7) and once +0x17BC037. All are free() of an invalid pointer inside the script interpreter.

Game script stack: GameMain.GameMain > ApplicationMode.Init (instr 244) > InitBackendSystems > Mr2BackendSystems.__initializer > ProsClientProfileStatBiRule.__initializer (instr 8). All network objects are freshly created (null), so the crash happens before any backend connection.

Native stack of the crashing thread: only SnowRunner.exe/ntdll/ucrtbase frames. None from EOSSDK, pros.sdk, WS2_32 or MSWSOCK. Among the other 82 threads, only one (0x658) has pros.sdk frames, and it is parked in a wait.

Run history (19 runs, Sevoflurane runs/2026-10.jsonl): the failure point varies between runs, including on the ORIGINAL engine before any change (10/24: +0x17BC07B x3, +0x1770d64 x2). So the crash is not deterministic.

DXMT log: 1770x "CreateQuery1: query type not implemented: 6" (probably D3D11_QUERY_SO_STATISTICS, from memory, not verified) and 2x "Only 2D texture SRV can be created on dynamic texture". Link to the crash NOT proven.

Static analysis of the exe: it does not reference d3d12.dll or trueforce_sdk_x64.dll. Static imports (EOSSDK, pros.sdk, d3d11, dxgi, HFFBSDK, GFSDK_Aftermath, XAudio2_9Redist, etc.) are all loaded on the Mac. xinput9_1_0 and xinput1_4 also load. On Windows, d3d12 comes from System32 and trueforce from C:\Program Files\Logi\Trueforce\ (environment, not part of the game). So missing DLLs do not explain the crash.

D3DMetal: it only runs on Apple Silicon and this is an Intel Mac. The "d3dmetal" runs in the history are exit-errors with no diagnostic value.

Windows: BackendLog/LegacyLog/ModMapError/trace_truck are also 0 bytes there, so empty logs are normal. Process Monitor capture (1994 events, all SUCCESS, ~70 s): UDP loopback 61733/61734; TLS to 172.64.155.112:443; 11 connect/accept pairs on loopback; TCP to 7 IPs on ports 11701-11706 and 81.28.14.13:443; Steam UDP (27xxx). API Monitor does not work (SteamStub: "Application Load Error 3:0000065432").

Tests done and results

Initial hypothesis: the staging patchset ws2_32-af_unix (connect(addr=NULL) reading addr->sa_family, WS2_32+0xc60a). I reverted all of AF_UNIX (ws2_32/socket.c, server/sock.c, ws2_32_private.h, ntdll/unix/socket.c; ntdll.so not swapped) and compiled ws2_32.dll and wineserver. The game kept crashing with the same type of failure.

Null guard only in connect(): crashed at +0x1770d64.
Guard if (!addr || len < sizeof(sa_family)) { SetLastError(WSAEFAULT); return -1; } (ws2_32 staging + original wineserver): crashed at +0x17BC07B, with registers identical to the revert test.
msync disabled: same result.

Conclusion: no change to ws2_32/wineserver altered the outcome in any run. ws2_32 does not appear to be the cause of the crash with DXMT.

Current state
Everything is restored to the original and verified by SHA1: the engine's and the bottle's ws2_32.dll = ba56d323c7193378de28cf6d9a007f1eb2990221; wineserver = 9e12875b87ae030925827d551e1bc49a8b3b8af7; sevo diag off (level 0); renderer = dxmt. Saved on the Desktop: revert-afunix-backup.patch, ws2_32-guard-wsaefault.dll, originais-antes-do-teste/. Nothing was changed on Windows.

Mainly for gfn and switch emulation.

GOG + Steam Mac Native with tons of porting and manual testing to get everything working. Just waiting on CDPR's permission to post.

Moi direct je prend GAMING.

Been working on an app called CyberMac to make installing mods on Mac easier, and I finally got clothing and body mods working!

You can drop mod ZIPs into the app, add clothes as separate inventory items, and change V’s body shape. Should be able to get custom characters soon.

It also handles script mods and keeps backups so you can restore your previous files.

You can check it out here: CyberMac on GitHub

I have tried both, and as expected and seen in other heavy titles, the Air thermal throttles. You won’t get 60 fps.

I tried on M4 Air 16GB, everything low, FSR Ultra Performance, hit a max of 40 fps. Memory pressure was in yellow.

The game could run at good frames on base Pros and very good on Pro Chips and as expected excellent on Max and Ultra chips.

Just a heads up, if anyone was thinking of trying this.