AnyPS5: religar executáveis de PS5 em vez de emulá-los

Existe uma categoria de projeto que bomba no GitHub por motivos que ninguém se dá ao trabalho de registrar. AnyPS5 é um deles. Está no topo da lista semanal com cerca de 16,000 estrelas novas, chega perto de 10,000 commits, e sua descrição de uma linha — «ferramenta para portar automaticamente executáveis de PS5 para Linux e Windows» — é o tipo de frase que faz advogado procurar caneta e engenheiro procurar favorito.

A parte interessante não é que ele exista. A parte interessante é aquilo que ele se recusa a ser.

Sem emulador, sem runtime, sem console dentro de uma janela

Quase todo projeto que roda software de console no PC é um emulador. Eles modelam o hardware: a CPU, a GPU, o layout de memória, o timing. Essa abordagem é uma maravilha quando funciona e um desgaste de uma década quando não funciona, porque cada jogo vira uma negociação com o modelo incompleto de uma máquina para a qual ninguém tem documentação completa.

O AnyPS5 segue outro caminho. Ele traz um relinker que converte um executável de PS5 para o formato nativo da plataforma de destino, além de implementações das bibliotecas de sistema prx com as quais o executável espera se ligar. O README diz a consequência sem rodeios: nada de emulação, nada de processo de runtime separado. O código do jogo roda como código nativo na sua máquina, chamando bibliotecas de sistema reimplementadas do mesmo jeito que chamaria as da Sony.

É uma promessa muito mais difícil de cumprir, e muito melhor se você conseguir. A emulação taxa cada instrução. A religação taxa apenas a fronteira: as chamadas que atravessam do jogo para a camada de sistema.

A parte que decide se funciona: os shaders

Um jogo é, em boa medida, um monte de shaders vestidos de jogo. Um título de PS5 carrega programas de GPU compilados para uma pilha gráfica específica; uma máquina Windows ou Linux quer algo que o driver dela consiga engolir. O AnyPS5 inclui um recompilador de shaders que emite SPIR-V, e o repositório anota que a saída é validada com o SPIRV-Tools quando a build ativa ANYPS5_ENABLE_SPIRV_TOOLS.

Validar SPIR-V não é a mesma coisa que rodar um jogo. Significa que o módulo gerado é estruturalmente legal, e essa é a diferença entre «isso talvez funcione» e «o driver vai rejeitar isso de um jeito muito difícil de depurar». Quem já passou uma noite encarando uma tela preta reconhece o valor dessa checagem.

A página de progresso do projeto é cuidadosa com o que os números significam. A cobertura de bibliotecas mede a fatia de funções que o projeto declarou até agora, não a fatia de todas as funções que um PS5 expõe. É um enquadramento honesto, e também significa que a porcentagem vai se mexer conforme a equipe descobre o tamanho daquilo que não sabe.

Como ele falha, de propósito

Uma decisão de design diz muito sobre a maturidade de uma base de código. Estados não suportados ou inesperados lançam std::runtime_error; a mensagem vai para o stderr e o processo termina.

Soa brutal, e é a escolha certa. A alternativa — chutar, continuar, corromper o estado — produz um crash três frames depois, num ponto que não tem nada a ver com o bug de verdade. Um projeto nesse estágio precisa de falhas barulhentas, precoces e específicas. Tem um commit de meados de outubro que corrige justamente um travamento de teste no Windows causado por esse tipo de problema de ordenação: no Windows, um teste que retorna de main passa por exit, e o exit mata todas as outras threads antes que os destruidores estáticos rodem no detach da DLL, então um destruidor que depois espera por um logger morto nunca retorna. A correção envolve o main no MinGW e encerra o processo via libc. Não é trabalho glamouroso. É o trabalho que separa uma demo de uma ferramenta.

Entrada, e as pequenas coisas que importam

Controles mapeados via SDL funcionam, incluindo analógicos e gatilhos. Teclado e mouse são configurados por um arquivo anyps5-input.ini. Existe um conversor web que processa os arquivos localmente, então nada é enviado para servidor nenhum.

A compatibilidade jogo a jogo não é mantida no README. Ela vive num mapa de bloqueios da comunidade, montado com dados públicos do GitHub, com tópicos por título nas discussions do repositório para os relatos de teste. Vale entender isso antes de baixar qualquer coisa: o projeto rastreia onde cada título trava, não uma lista verde de jogos que funcionam.

A frase jurídica que você deveria realmente ler

O aviso legal diz que o projeto é para interoperabilidade, pesquisa, preservação e compatibilidade. Diz que não inclui, distribui nem exige software protegido por direitos autorais, firmware, chaves criptográficas ou bibliotecas proprietárias. E diz que os usuários são responsáveis por garantir que os binários que usam foram obtidos e são usados de forma lícita.

É uma linha traçada com cuidado, e é todo o jogo. A ferramenta em si é GPL-2.0-only e não contém nenhum dado de jogo. O que você coloca nela é problema seu, e na maioria das jurisdições «eu mesmo religuei» não é uma defesa que já tenha sido testada em tribunal.

Onde a fronteira fica de fato

O trabalho de um relinker é resolução de símbolos. O executável pede funções por nome; a ferramenta tem que garantir que cada um desses nomes resolva para algo chamável no carregamento, na convenção de chamada correta, numa máquina que não é a máquina para a qual o binário foi compilado. Erra um e o processo morre na inicialização, normalmente com uma mensagem que nomeia uma biblioteca e mais nada.

É por isso que a página de cobertura do projeto é o documento mais honesto do repositório. Ela informa a fatia de funções declaradas que estão implementadas — não a fatia de toda a superfície de API de um PS5. A diferença é enorme, e significa que a porcentagem vai cair conforme a equipe descobre mais daquilo que não sabe. Quase todo projeto esconde essa dinâmica. Este coloca uma nota ao lado do número.

A mesma lógica explica o lado da GPU. Tradução de shader não é um problema único; é um problema diferente por shader, e um título que renderiza certo por vinte minutos e então entra num caminho de instruções não traduzido vai quebrar de um jeito que parece bug de driver. A etapa de validação de SPIR-V pega problemas estruturais cedo. Não pega os semânticos, e o projeto não afirma que pega.

Então a pergunta prática não é «funciona?». É «onde o meu título para?», e o mapa de bloqueios responde isso jogo a jogo, com as issues abertas anexadas.

Por que viralizou agora

Preservação está em alta. Disco que apodrece, loja que retira jogo do catálogo, servidor desligado: o argumento para manter software executável deixou de ser sentimental e virou prático. Um relinker é uma ferramenta de preservação de um jeito que um emulador não é: ele não precisa modelar uma máquina, só satisfazer a interface que o software espera.

Há também uma explicação mais simples. O projeto é enorme, os commits caem às centenas, e boa parte deles é claramente escrita com agentes de código no meio — o repositório inclui até um arquivo AGENTS.md listando as regras que os agentes costumam quebrar. Ver um projeto de 10,000 commits sendo erguido em cerca de dois meses e meio é um espetáculo por si só, e explica uma curva de estrelas que tem pouca relação com quantos jogos sobem.

O que fazer com isso

Se você tem um executável obtido legalmente e uma noite livre, a expectativa honesta é esta: vai aprender muito sobre como um título de console moderno é montado, e provavelmente não vai zerar um jogo. Leia primeiro o mapa de bloqueios do seu título. Leia o documento de dívida técnica antes de abrir uma issue. E leia a licença antes de publicar qualquer coisa construída com isso.

O ponto maior continua de pé, não importa quantos títulos cheguem a subir. Por vinte anos, a resposta para «esse software de console roda em outro lugar?» foi «só se alguém emular a máquina». O AnyPS5 é uma tentativa séria de uma segunda resposta, e o fato de estar sendo escrito em público, nessa velocidade, com tanta encanação sem glamour é justamente o motivo de ele merecer a página de tendências.