3 pontos por GN⁺ 2024-05-16 | 2 comentários | Compartilhar no WhatsApp
  • Jogos do Nintendo 64 lançados em 1996 agora podem ser recompilados como ports nativos para PC em vez de serem emulados, permitindo aplicar melhorias como ray tracing, ultrawide e FPS alto
  • As principais ferramentas são N64Recomp e Zelda64Recomp, publicadas por Mr-Wiseguy no GitHub; Zelda64Recomp porta The Legend of Zelda: Majora's Mask para PC
  • Essa abordagem é diferente do port de Super Mario 64 para PC baseado em descompilação completa, lançado em 2020, mas ambas rodam nativamente no PC e podem aumentar o desempenho e a precisão dos efeitos
  • Enquanto a descompilação manual exigiria anos de trabalho de uma ou mais pessoas, N64Recomp é uma abordagem para transformar jogos de N64 mais rapidamente em uma forma executável no PC
  • O resultado não inclui assets, portanto é necessário ter a ROM para jogar; Banjo-Kazooie, Rocket Robot e Superman 64 também são citados como exemplos em execução

Mudanças na forma de portar jogos de N64

  • Mesmo em 2024, o hardware original e os jogos do Nintendo 64 continuam recebendo interesse constante da comunidade de entusiastas
  • Há uma possibilidade crescente de que o próximo passo para jogar N64 em nível avançado não seja a emulação, mas sim ports recompilados para PC
  • Mr-Wiseguy, do GitHub, publicou N64Recomp e Zelda64Recomp
    • N64Recomp é a ferramenta-base para transformar jogos de N64 em ports nativos para PC
    • Zelda64Recomp porta The Legend of Zelda: Majora's Mask para PC e aplica melhorias gráficas e de conveniência do N64Recomp

Melhorias possíveis em ports para PC

  • Ports recompilados para PC podem adicionar melhorias do ambiente de PC aos jogos originais de N64
    • Ray tracing real

      • Remoção do limite de frames
      • Suporte adequado a ultrawide
      • Melhorias gráficas e de conveniência esperadas no PC
      • Majora's Mask é apresentado como caso de comparação entre execução ultrawide via emulação e via recompilação nativa para PC

Diferença em relação ao port de Super Mario 64 para PC

  • O port de Super Mario 64 para PC baseado em descompilação completa, lançado em 2020, possibilitou recursos como ray tracing e substituição completa de modelos, e os mods continuam até hoje
  • Ports por recompilação diferem de ports por descompilação, como o port de SM64 para PC, na forma como são produzidos
  • Ambas as abordagens rodam nativamente no PC e podem oferecer melhorias no estilo PC esperadas da emulação, aumentando o desempenho e a precisão dos efeitos em relação ao hardware original

Por que o N64Recomp é importante

  • N64Recomp é uma ferramenta que, por meio da abordagem de recompilação, busca combinar as vantagens da emulação e dos ports nativos
  • Descompilar manualmente jogos de N64 exigiria anos de trabalho de uma ou mais pessoas
  • Uma ferramenta que transforma jogos de N64 em um estado rapidamente executável no PC de forma mais eficiente também pode ser útil para preservacionistas

RT64 e exemplos de execução

  • Dario é o desenvolvedor que cria o plugin RT64, usado pelo N64Recomp e por alguns emuladores de N64
  • Segundo uma publicação de Dario, Wiseguy trabalhou em particular por um ano em uma ferramenta para criar ports de jogos de N64 para PC sem uma descompilação completa
  • O resultado não inclui assets, e apenas a ROM é necessária para jogar
  • Os seguintes jogos são citados como exemplos em execução
    • Banjo-Kazooie
    • Rocket Robot
    • Superman 64

Outros movimentos no ecossistema do N64

  • Outros avanços para fãs da biblioteca do N64 e do hardware original também continuam surgindo
  • O SummerCart64 open source é um flash cart para consoles existentes e também implementa suporte ao 64DD
  • Jogos homebrew de N64 compatíveis com hardware real e ROM hacks continuam sendo lançados
    • Smash Remix, que oferece 30 lutadores
    • Peach's Fury, um projeto de reescrita da engine de Mario 64

2 comentários

 
GN⁺ 2024-05-16
Comentários no Hacker News
  • Para usar essa ferramenta, ainda é preciso primeiro desassemblar a ROM e adicionar muitas anotações para que ela possa ser recompilada
    A ferramenta em si é excelente, mas parece exagero dizer que ela transforma quase com um clique qualquer ROM em um executável independente

    • Ainda assim, ao contrário do PS2 ou do Game Boy, o N64 teve apenas 388 jogos lançados, então parece realisticamente possível organizar todos os jogos lançados passando por esse processo
    • Acho que isso não é verdade
      No vídeo do post, eles recompilaram um jogo de N64 sem nome e ele rodou bem; não parecia precisar de anotações separadas
    • Esse trabalho só precisa ser feito uma vez e depois armazenado em algum lugar para ser compartilhado
      ROM é literalmente somente leitura, então seria possível inserir a ROM e obter um port nativo
    • Não entendo por que seria necessário primeiro desassemblar a ROM e adicionar muitas anotações
      Uma conversão de binário para binário seria mais intuitiva, e não parece que exigiria intervenção humana
    • Fico curioso sobre o que exatamente é esse processo e se pelo menos parte dele poderia ser tratada pelo ChatGPT
  • Muito legal
    Várias ferramentas de base criadas para a decompilação do N64 estão se espalhando para pacotes de decompilação de outros sistemas
    Vi recentemente o https://decomp.me/, que oferece suporte a decompilação colaborativa para vários sistemas, com SDKs relacionados e presets de hardware
    Acho que veremos esse movimento surgir em mais sistemas nos próximos anos

  • Quando isso saiu, eu vi a notícia e, como alguém que não acompanha a cena de ROM hacking, fiquei curioso sobre por que essa abordagem demorou tanto para aparecer
    Traduzir instruções de assembly para C e depois recompilar parece um método óbvio para tentar logo no começo; fico me perguntando se antes era impossível e se houve algum outro avanço que agora tornou isso viável

    • O N64 tem uma GPU diferente das GPUs modernas, e essa GPU é necessária para renderizar os gráficos
      Dando uma olhada no repositório do GitHub, parece que ele usa internamente o rt64 para suporte a ray tracing (https://github.com/rt64/rt64)
      O rt64 usa a técnica de ubershader para emular a GPU, e este excelente texto explica o que são ubershaders, por que são necessários e o quão caóticos eles são: https://dolphin-emu.org/blog/2017/07/30/ubershaders/
    • Outros emuladores tentam resolver o problema de forma genérica, mas esta solução não é totalmente assim
      Fazer recompilação estática de uma linguagem de máquina para outra linguagem fica, na prática, entre algo muito difícil e algo geralmente impossível [1]
      Para fazer esse tipo de recompilação direito, também é preciso ajuda do lado do binário que facilite a recompilação [2], além de patches para fazê-la funcionar [3]
      A recompilação dinâmica não tem esses problemas, então, ao fornecer o binário original e os assets, ou seja, a ROM, em geral é possível criar software emulado
      Há muita confusão sobre o quão genérica é esta solução
      Ela é muito impressionante e valiosa como forma de reduzir a quantidade de trabalho, tornando recompilações ou ports muito mais fáceis, mas não substitui a necessidade de emuladores tradicionais
      [1]: https://cs.stackexchange.com/questions/155511/why-is-static-...
      [2]: Os binários de jogos de N64 podem ajudar essa abordagem porque, por acaso, evitam vários fatores que dificultam a recompilação estática genérica, mas na prática não sei ao certo
      [3]: O repositório de recompilação de Majora's Mask contém muitos patches feitos à mão para funcionar: https://github.com/Mr-Wiseguy/Zelda64Recomp
    • A emulação de hardware normalmente precisa emular, com precisão de ciclo, coisas que rodam em paralelo, então não é um problema simples de lidar apenas com o programa dentro da ROM
    • Fico curioso se ele usa código automodificável ou outros elementos que tornem isso difícil
  • O Jamulator já fazia isso em 2013 para o NES, mas parece que ninguém ligou muito
    https://andrewkelley.me/post/jamulator.html
    Também existe o Winlator, que executa programas do Windows no Android
    https://github.com/brunodev85/winlator
    E o vídeo do YouTube linkado no texto usa voz de IA?

    • Pelo menos o Mr WiseGuy parece se importar
      No repositório GitHub do N64Recomp[0] está escrito assim:
      "This is not the first project that uses static recompilation on game console binaries. A well known example is jamulator, which targets NES binaries."
      [0]: https://github.com/Mr-Wiseguy/N64Recomp
    • O Jamulator não teve sucesso porque os cartuchos tinham hardware adicional demais
      Nesse cenário, a recompilação só complica as coisas e não traz muita vantagem
      O N64 tem hardware fixo, então é um pouco mais fácil
      Mesmo assim, este projeto ainda usa emulação para o RDP
      Não sei como ele lida com o microcódigo RSP gerado, e talvez nem lide
      Muitos jogos simplesmente usavam as bibliotecas oficiais
    • O Jamulator não foi além do que um emulador de NES consegue fazer, exceto pela forma de execução
      Se o Jamulator tivesse saído com melhorias parecidas para Zelda, teria sido muito mais popular
      O interesse parece vir mais do que se pode fazer agora com isso do que do método em si
      A narração do vídeo é só de uma pessoa real chamada Nerrel
      É bem impressionante, em um sentido interessante, que as vozes de IA tenham ficado tão boas hoje em dia a ponto de suspeitarmos que alguém é IA quando essa pessoa não fala do jeito que esperamos
    • É só o Nerrel
      A narração dele é tão plana que há tempos soa como IA, e gosto da forma como isso se mistura com o humor
  • Seria bom se todos os executáveis de jogos fossem independentes do sistema operacional, de forma parecida com WebAssembly
    Algo como GameAssembly, por exemplo
    Nos macOS novos já não dá para jogar jogos de 32 bits, e no Wine também não dá para rodar jogos de Windows de 32 bits
    Também é quase impossível encontrar arquivos .exe de 64 bits que rodem direito no Wine/Crossover

    • Em jogos, o código executado na CPU pode ser visto como um problema menor
      No caso dos consoles, especialmente em títulos antigos e exclusivos de plataforma, eles muitas vezes dependem de detalhes de implementação da GPU em nível muito baixo
      Consoles mais antigos tinham outros chips dedicados que faziam coisas importantes além de simples entrada e saída
      Por exemplo, o chip de som do SNES era uma CPU completamente independente que executava seu próprio programinha em paralelo com a CPU e a GPU
      Claro, seria possível tornar obrigatória uma máquina virtual de alto nível para todo desenvolvimento de jogos daqui em diante, mas, considerando que as especificações de hardware dos consoles são fixas, isso não seria competitivo para títulos que querem aproveitar gráficos modernos
    • Concordo com a ideia, mas tenho rodado jogos de Windows de 32 bits de forma bastante satisfatória no Linux x86_64
      No Debian, foi preciso executar o seguinte
      dpkg --add-architecture i386 && apt-get update
      Depois é só instalar o pacote wine32
    • Para tornar jogos portáveis, não basta fornecer apenas código de máquina portável
      Jogos precisam de várias APIs, como API gráfica, API de janelas, API de entrada, API de som, API de disco etc.
      Às vezes também precisam de módulos de kernel por causa de anticheat ou proteção contra cópia
      O lamentável é que os sistemas operacionais de código aberto não tentem oferecer um conjunto comum de APIs para que o desenvolvedor escreva e teste o código uma vez e ele funcione em qualquer lugar
      Existe o Flatpak, mas, pelo que entendo, ele não fornece um conjunto de APIs; é mais como empacotar uma distribuição Linux dentro de uma máquina virtual, sem especificação nem documentação
      É feio e também não oferece compatibilidade com pequenos sistemas operacionais que não sejam Linux
    • No Wine para Mac, mesmo no Apple Silicon, era possível executar jogos de Windows de 32 bits
      Rodei GTA IV em um M1 mini
      Parece que há algum tipo de emulação "32 on 64" dentro da versão de 32 bits do Wine instalada pelo PlayOnMac, mas é tão difícil pesquisar sobre isso que não sei como realmente funciona
      É engraçado que o Mac seja mais compatível com programas antigos do Windows do que com programas antigos de Mac
    • A JVM consegue fazer isso muito bem com Minecraft
      Sem a JVM, fico em dúvida se Minecraft teria dado suporte a Linux, sistemas da família BSD etc.
      A Bedrock Edition, que não é a versão JVM, dá suporte a Windows, consoles e celulares, mas não dá suporte a macOS, embora claramente fosse possível
  • Espero que isso acabe funcionando também no Linux, para que seja possível jogar jogos de N64 de forma estável em dispositivos portáteis de baixíssimo desempenho.
    O N64 é notoriamente difícil de emular, mas, se houver um build nativo para a plataforma, os problemas de desempenho desaparecem.

    • É quase certo que o Linux seja suportado nativamente via N64Recomp: https://github.com/Mr-Wiseguy/N64Recomp
      Dá para ver exemplos aqui: https://github.com/Mr-Wiseguy/Zelda64Recomp?tab=readme-ov-fi...
    • Eu não esperava que o N64 fosse difícil de emular.
      Não conheço bem os detalhes da emulação de N64, mas desde o começo dos anos 2010 venho rodando emuladores de N64 perfeitamente.
      Como joguei principalmente os grandes clássicos, não sei bem como é o desempenho dos títulos mais de nicho.
    • Testei diretamente em um PC com Ubuntu e funciona muito bem.
      Joguei por cerca de uma hora sem problemas.
    • Vi há alguns dias o vídeo do YouTube linkado por este post, e ele mencionava suporte a Linux, dizendo especialmente que também deveria funcionar no Steam Deck.
    • Já funciona no Linux.
      Eu mesmo testei.
  • Isso pode ser bem útil para jogos como GoldenEye.
    Ele é difícil de jogar no PC porque pressupõe uma entrada de joystick estranha; seria legal ter um port nativo de GoldenEye com comportamento normal de mouse, como em outros FPS.

    • WASD e mira com mouse, na verdade, não combinam muito bem com esse jogo.
      O modo de alternância da mira e o tempo que o cursor leva para se mover e voltar ao centro fazem parte do que torna o jogo divertido.
      Se você pudesse mirar livremente enquanto corre, como em um FPS de PC, acho que isso até quebraria o jogo, já que a campanha foi projetada com a outra premissa.
      Escolher onde parar para mirar e manter a calma enquanto mira é parte do charme.
      Dito isso, poderia ser interessante manter a alternância de modo e fazer com que o mouse 1) gire o Bond como o eixo horizontal do stick e 2) controle o cursor apenas quando R estiver pressionado no "modo de mira".
      Sinceramente, acho uma pena que todos os shooters tenham ido direto para o modelo Quake de WASD + mira livre com mouse.
      O modo de alternância dá a GoldenEye uma sensação física de que gosto.
    • Existe um hack de emulador que adiciona suporte a WASD + mouse ao GoldenEye, e ouvi dizer que funciona bem.
      https://github.com/Graslu/1964GEPD/releases/tag/latest
    • Ainda assim, ele não continuaria esperando um joystick estranho?
    • O hack de mouse + WASD funciona muito bem.
      Também funciona em Perfect Dark.
  • É bem interessante, e fico curioso se isso poderia levar a uma versão de Conker que funcione corretamente no MiSTer.
    Por exemplo, será que isso poderia ser usado como auxílio à decompilação, para alguém criar uma versão modificada?

  • Fico me perguntando qual é a vantagem em comparação com um emulador.
    No fim das contas, não é uma espécie de emulador que traduz tudo previamente?
    Esse tipo de abordagem já existiu antes, com coisas como o Bleem, e pode trazer vantagem de desempenho, mas em PCs modernos um bom emulador geralmente funciona bem.
    https://en.wikipedia.org/wiki/Bleem!

    • O objetivo deste projeto e o objetivo da emulação de N64 são bem diferentes.
      O objetivo de um emulador de N64 geralmente é reproduzir com precisão o comportamento do console original.
      Por outro lado, há muita gente que quer jogar SM64, OOT e MM a 60 fps, em widescreen, com pacotes de textura, randomizer e várias outras melhorias gráficas.
      Para essas pessoas, o fato de esses jogos originalmente rodarem no N64 praticamente não importa.
      É mais um obstáculo do que qualquer outra coisa.
      O pipeline gráfico do N64 é trabalhoso de emular e atrapalha ativamente melhorias modernas.
      Este projeto parece estar mais focado em tratar o jogo em si de forma moderna e remover completamente da equação os elementos centrados no N64.
    • Emulação JIT pode causar engasgos, mas AOT não deveria causar.
      Hoje os computadores são muito mais rápidos que o N64, então talvez a diferença nem seja perceptível.
    • No vídeo, eles mostram que usar essa abordagem elimina vários bugs em comparação com a emulação.
    • Recompilação não é emulação.
  • Emuladores comuns compilam com antecedência ou usam JIT?
    Se não, fico curioso sobre o motivo.
    Essa abordagem, ou seja, a compilação antecipada, parece ter grandes vantagens.

    • Cite qualquer nome de técnica de compilação ou de interpretador e haverá pelo menos um emulador que a usa.
    • Entre emuladores de gerações de 32 bits em diante, muitos usam recompilação JIT.
      Mas, a menos que o TeknoParrot funcione dessa forma, não conheço muito sobre tradução antecipada.
      Por exemplo, com o TeknoParrot é possível executar no Windows jogos de arcade Linux que usam binários ELF, mas, como a arquitetura é a mesma, eu não chamaria isso de emulação em nenhum dos casos.
    • Existem muitas formas de emulação, mas a execução interpretada provavelmente é a mais comum, ou pelo menos muito comum.
      Execução interpretada consiste em escrever uma máquina virtual que representa o estado de várias partes da máquina e executar instruções que alteram esse estado, com diferentes níveis de precisão.
 
lifeisliving 2024-05-18

A habilidade dos nerds! Indo além de equipar emuladores com compilador JIT, agora já dá até para converter para C com binary lifting e recompilar nativamente.