Flycast macOS recebeu em 28 de setembro de 2026 uma correção importante para o renderer Vulkan com ordenação alfa por pixel. O commit ataca falhas de sincronização que podiam causar um flicker de aproximadamente um quadro em Macs com MoltenVK. A mudança entrou no código do Flycast após a análise de um problema reproduzido com Shenmue em um MacBook Air M3.
O relato original surgiu em 15 de setembro. O usuário executava o Flycast 2.7-1-g44e4c7b50 no macOS 15.7.8 Sequoia, com um MacBook Air M3 de 16 GB. Segundo o teste, a ordenação Per-Triangle produzia erros na sobreposição de transparências. Já o modo Per-Pixel corrigia essa ordem, porém introduzia um glitch rápido e periódico.
Comparação com ordenação por triângulo em Shenmue. Vídeo: issue oficial do Flycast no GitHub.
Flycast macOS corrige sincronização no Vulkan
O desenvolvedor richstokes investigou o pipeline OIT (Order Independent Transparency) do Vulkan e encontrou hazards de sincronização entre passes de renderização e quadros consecutivos. Em resumo, diferentes etapas podiam acessar os mesmos recursos sem dependências e barreiras suficientes para garantir a ordem correta.
Isso afetava o attachment de cor OP+PT, buffers de profundidade e stencil, os chamados a-buffers e o contador de pixels. Além disso, o reset desse contador usava uma cópia de buffer sem uma barreira adequada contra os fragment shaders que também acessavam o recurso.
Em muitos drivers de desktop, a execução acabava escondendo o problema ao serializar o trabalho. Entretanto, o cenário muda no macOS recente. O MoltenVK traduz Vulkan para Metal e, no macOS 15 ou superior, pode usar argument buffers do Metal 3 com residency sets. Nesse caminho, o aplicativo precisa declarar corretamente dependências e barreiras para evitar acessos concorrentes problemáticos.
O modo por pixel corrige a sobreposição, mas o relato registrou flicker periódico antes da correção. Vídeo: issue oficial do Flycast no GitHub.
O que mudou no renderer do Flycast
O commit e36e9df adiciona dependências externas para os subpasses que fazem o primeiro uso dos attachments de cor, profundidade e stencil. A alteração também cobre as escritas nos storage buffers e organiza melhor a transição entre os passes do renderer OIT.
Além disso, o código ganhou barreiras antes e depois da cópia que zera o contador de pixels. Dessa forma, o renderer impede que o reset concorra com fragment shaders que ainda usam o mesmo contador. A correção também encadeia as operações de cor necessárias quando o Flycast alterna os buffers entre passes.
A mudança não cria um novo backend e não substitui o MoltenVK. Na prática, ela corrige a sincronização do caminho Vulkan já existente. O próprio projeto mantém suporte a Vulkan no macOS por meio do MoltenVK, que implementa uma camada de portabilidade Vulkan sobre o Metal da Apple.
Testes encontraram hazards antes da correção
O autor da correção compilou e executou o Flycast em um Mac com Apple M5 Pro, usando MoltenVK 1.4.2. Os testes utilizaram Shenmue dos Estados Unidos com ordenação por pixel, tanto na resolução nativa quanto em resolução interna 4x.
Antes da mudança, a camada de validação Khronos registrava hazards dos tipos WRITE-AFTER-WRITE, READ-AFTER-WRITE e WRITE-AFTER-READ nos attachments do render pass OIT. Depois da alteração, esses avisos específicos desapareceram. O teste ainda encontrou outro aviso relacionado ao caminho entre aquisição do swapchain e apresentação, mas o autor explicou que ele afeta todos os renderers e não pertence ao problema do OIT.
Há uma limitação importante: o desenvolvedor não conseguiu reproduzir visualmente o flicker em sua máquina M5 Pro com uma versão mais nova do macOS. Portanto, a validação técnica confirmou a remoção dos hazards detectados, enquanto a reprodução visual original veio do MacBook Air M3 do autor da issue. Essa distinção evita transformar um teste específico em uma conclusão mais ampla do que as evidências permitem.
Correção já entrou no código em 28 de setembro
A pull request #2507 abriu em 23 de setembro e fechou em 28 de setembro. No mesmo dia, o repositório registrou o commit e36e9df com a correção e referência direta à issue #2495. Assim, usuários das builds recentes do branch principal podem receber a mudança antes de uma futura versão estável numerada.
O Flycast oferece builds recentes do branch principal, builds de desenvolvimento e releases estáveis. Por isso, a presença da correção no código não significa que todo usuário da versão estável 2.7 já tenha o patch instalado. Quem depende especificamente dessa correção deve conferir o canal e a data da build utilizada.
O Flycast emula Dreamcast, Naomi, Naomi 2 e Atomiswave em várias plataformas. Para quem acompanha emulação em dispositivos Apple, o Allves Games também mantém uma lista de emuladores para iPhone e iPad. Além disso, nosso guia sobre DLSS 5 em emuladores mostra outro caminho experimental voltado à renderização de jogos clássicos.
Fontes: issue #2495 do Flycast; pull request #2507; commit e36e9df; MoltenVK.
