Flycast macOS received an important fix for the Vulkan renderer with per-pixel alpha sorting on September 28, 2026. The commit addresses synchronization flaws that could cause approximately a one-frame flicker on Macs with MoltenVK. The change entered the Flycast codebase after analyzing an issue reproduced with Shenmue on an M3 MacBook Air.
The original report emerged on September 15. The user was running Flycast 2.7-1-g44e4c7b50 on macOS 15.7.8 Sequoia, with a 16 GB M3 MacBook Air. According to the test, the sorting Per-Triangle produced errors in transparency overlapping. The Per-Pixel mode, however, Per-Pixel fixed this order, but introduced a fast, periodic glitch.
Comparison with triangle sorting in Shenmue. Video: official Flycast issue on GitHub.
Flycast macOS fixes synchronization in Vulkan
Developer richstokes investigated the OIT pipeline (Order Independent Transparency) of Vulkan and encountered synchronization hazards between render passes and consecutive frames. In summary, different stages could access the same resources without sufficient dependencies and barriers to guarantee the correct order.
) This affected the OP+PT color attachment, depth and stencil buffers, the so-called a-buffers, and the pixel counter. Furthermore, resetting this counter used a buffer copy without an adequate barrier against the fragment shaders that also accessed the resource.
) In many desktop drivers, execution ended up hiding the problem by serializing the work. However, the scenario changes on recent macOS. MoltenVK translates Vulkan to Metal and, on macOS 15 or higher, can use Metal 3 argument buffers with ) residency sets. Along this path, the application must correctly declare dependencies and barriers to avoid problematic concurrent accesses.
Pixel-based mode fixes overlapping, but the report noted periodic flicker before the fix. Video: official Flycast issue on GitHub.
What changed in the Flycast renderer
Commit e36e9df adds external dependencies for subpasses that make the first use of color, depth, and stencil attachments. The change also covers writes to storage buffers and better organizes the transition between OIT renderer passes.
In addition, the code gained barriers before and after the copy that resets the pixel counter. This way, the renderer prevents the reset from racing with fragment shaders that still use the same counter. The fix also chains the necessary color operations when Flycast swaps buffers between passes.
The change does not create a new backend and does not replace MoltenVK. In practice, it fixes synchronization in the existing Vulkan path. The project itself maintains Vulkan support on macOS through MoltenVK, which implements a Vulkan portability layer over Apple's Metal.
Tests found hazards before the fix
The author of the fix compiled and executed Flycast on a Mac with Apple M5 Pro, using MoltenVK 1.4.2. The tests used Shenmue from the United States with pixel ordering, both at native resolution and at 4x internal resolution.
Before the change, the Khronos validation layer logged hazards of types WRITE-AFTER-WRITE, READ-AFTER-WRITE and WRITE-AFTER-READ on the attachments of the OIT render pass. After the change, these specific warnings disappeared. The test still found another warning related to the path between swapchain acquisition and presentation, but the author explained that it affects all renderers and does not belong to the OIT issue.
There is an important limitation: the developer was not able to visually reproduce the flicker on their M5 Pro machine with a newer version of macOS. Therefore, the technical validation confirmed the removal of the detected hazards, while the original visual reproduction came from the issue author's M3 MacBook Air. This distinction avoids turning a specific test into a broader conclusion than the evidence allows.
Fix already merged into the code on September 28
Pull request #2507 opened on September 23 and closed on September 28. On the same day, the repository recorded commit e36e9df with the fix and a direct reference to issue #2495. Thus, users of recent builds from the main branch may receive the change prior to a future numbered stable release.
Flycast offers recent main branch builds, development builds, and stable releases. Therefore, the presence of the fix in the code does not mean every user of stable version 2.7 already has the patch installed. Anyone relying specifically on this fix should check the channel and date of the build being used.
Flycast emulates Dreamcast, Naomi, Naomi 2, and Atomiswave across multiple platforms. For those following emulation on Apple devices, Allves Games also maintains a list of emulators for iPhone and iPad. Additionally, our guide on DLSS 5 in emulators shows another experimental path focused on rendering classic games.
Sources: Flycast issue #2495; pull request #2507; commit e36e9df; MoltenVK.
