Criando um emulador perfeito de Super Nintendo - PARTE 1

Esta matéria é um relato sobre os problemas enfrentados ao buscar emular com perfeição e fidelidade o Super Nintendo, a matéria é extensa então dividirei em 3 tópicos assim o texto não se tornará tão cansativo para o leitor.

Discussões sobre emuladores são imensamente populares online, com argumentos sobre qual emulador é melhor com cada game. Hoje esta matéria fala sobre um outro ponto de vista, o do criador do emulador de super Nintendo "bsnes". Ele quer compartilhar seus pensamentos sobre a experiência em emulação: a precisão.

Não precisa-se de muita força bruta para jogar Nintendo ou Super Nintendo em um PC moderno, emuladores podiam fazer isso até nos anos 90 com meros 25Mhz de processamento. Mas emular estes consoles com precisão, bem, isto é um desafio e tanto; emuladores que funcionam com acurácia e precisão precisam de 3Ghz de potência para recriar fielmente. Nesta parte damos uma olhada no porque a precisão é tão importante e porque emular com perfeição é tão difícil.

Simplifiquemos, a precisão é a medida de quão bem um software emulador imita o hardware original. Aparentemente compatibilidade é a mais óbvia medida de precisão -- o meu velho jogo irá funcionar no meu novo emulador ? -- mas essa visão estreita passa por cima de problemas menores. Na verdade, a maioria dos softwares rodam com grande tolerância aos problemas de "timing" que aparentam estar rodando de maneira normal, mesmo se o timing estiver em off quanto a 20%.

Então uma pergunta surge: se nós atingimos uma compatibilidade básica, porque se preocupar em melhorar a precisão sendo que uma melhora gera consequência em termos de velocidade ? Duas razões: performance e preservação.

Primeiro, performance. Vamos pegar o caso de Speedy Gonzales. Esté é um jogo plataforma do SNES que não possui a função save, e possui uma duração média de 2 - 3 horas. A primeira impressão é que ele parece funcionar bem em um emulador. Porém quando se chega ao estágio 6-1, você rapidamente nota a diferença entre um emulador preciso e um emulador rápido: há um botão (switch), que é requerido para completar o level, aonde o jogo irá chegar a um beco sem saída se um raro hardware edge case não é emulado. Ai vemos quão frustrante é a sensação de ter perdido 3 horas de jogo e se deparar com um jogo que não pode ser terminado. Ao menos que o software comporte-se exatamente do mesmo modo que o hardware se comporta, o jogo continuará bugado.

Ou considere Air Strike Patrol, aonde uma sombra é vista embaixo de sua aeronave. Isto é feito usando mid-scanline raster effects, o que é um recurso extraordinariamente intensivo de emular. Mas sem os raster effects, a sombra da aeronave não irá aparecer, como você vê na figura abaixo. Isto é pouco notado, especialmente se você não sabe o que deveria estar vendo. Mas assim que você vê, se dá conta que é extremamente útil. Sua aeronave tem a abilidade de soltar bombas, e esta sombra atua como um sistema de mira para determinar aonde as bombas cairão - algo que é muito mais dificil de se realizar sem a sombra.

O segundo problema é a preservação. Dêem uma olhada na Nintendo´s Game & Watch hardware. Estes dispositivos lançados em 1980, em sua maioria dos 43 milhões produzidos falharam por conta da idade ou foram destruídos. Embora eles ainda são obtidos, sua escassez somente irá aumentar, unidades extras jamais serão produzidas. Os problemas se estende a qualquer hardware: uma vez que se para de fabricar é para sempre. Neste ponto, emuladores são a melhor maneira de se obter a experiência destes jogos antigos, então eles deveriam ser capazes de uma reprodução fiel.

Porém esta fidelidade vêm com um custo sério. Fazer um emulador duas vezes mais preciso fará com que ele seja duas vezes mais lerdo; dobre a precisão de novo e agora você tem algo quatro vezes mais lento. Ao mesmo tempo, a recompensa por esta precisão diminui rapidamente, pois a maioria dos jogos parece ser jogável nos modestos levels de precisão de um emulador. (A maioria dos emuladores procuram um "ponto ótimo" por volta de 95% de compatibilidade com uma performance otimizada.)

Não há nada de errado com estes emuladores menos precisos porém mais rápidos, este código pode rodar em hardware não tão bons, como telefones celulares e portáteis. Estes emuladores são mais voltados para uso em laptops, onde a bateria é um problema. Mas há algo a ser feito sobre a busca por precisão, e isto é o que eu tento fazer com o meu trabalho.

De volta aos anos 90, Nesticle foi um emulador NES de fácil escolha, com requerimentos mínimos de 25Mhz. Esta performance veio com um custo significante: as imagens dos jogos eram hackeadas para rodar neste emulador especificamente. Fãs realizavam alterações e hacks na emulação que fazia com que os jogos não se tornássem jogáveis no hardware real e em outros emuladores, criando uma variedade de lock-in effect que levou um tempo para conseguir ser quebrado. Naquele tempo, as pessoas não ligavam como originalmente o jogo iria parecer e ser jogado no geral, eles só se importavam se eles iriam ser jogáveis naquele ambiente artificial.

Hoje em dia, os emuladores dominantes são Nestopia e Nintendulator, requerendo 800Mhz e 1.6Ghz, respectivamente, para se obter velocidade máxima. A necessidade por velocidade não é porque os emuladores não otimizados, mas porque eles estão muito longe de recriar com perfeição o hardware original.

Agora comparado aos antigos emuladores de N64, UltraHLE, os requerimentos mínimos eram de 350Mhz. Para um observador casual, é um paradoxo Mario 64 requerer menos poder de processamento que o Mario Bros. original.

A minha experiência em emulação é no campo de SNES, trabalhando com o "bsnes". Eu adoro o ideal por trás de Nestopia, e quero recriar o nível de precisão para o Super Nintendo. Do mesmo jeto, a dedicação em atingir tal precisão irá elevar os requerimentos mínimos para a casa dos 2-3Ghz, dependendo do jogo.

Timecop rodando em dois emuladores diferentes

O Nestopia vingou porque seus requerimentos são possíveis atualmente, mas eu não tenho dúvida que se fosse lançado em 1997 seria um desastre. Meu emulador requer um computador com maior potência, eu vi que rodando ele em um computador com menor potência causa blacklash entre outros problemas. É fácil culpar o software ao invés de seu próprio hardware, mas na verdade emular um console hardware em um software é um processo intenso.

Então se um emulador aparenta rodar todos os jogos corretamente, porque então melhorarmos ? A simples resposta é porque melhorará coisas que ainda não sabemos sobre. Isto é particularmente proeminente em um software menos popular.

Um exemplo, comparando a animação de spining da triforce na abertura de Legend of Zelda no ZSNES e BSNES. Na forma, a triforce irá completar sua rotação tão quanto o resultado de desempenho da CPU, 40% mais rápido que o real SNES. Estes são apenas pequenos detalhes, mas se você tiver um olho para a precisão, pode ser enlouquecedor.

Eu encontrei duzias de jogos com detalhes obscuros. Algumas vezes o correto, a emulação mais precisa, produz um resultado errado. Super Bonk´s atract mode demo atualmente desincroniza, fazendo com que Bonk fique preso a uma parede. E Starfox sofre significantemente de slowdowns ao longo do jogo. Este certamente não são atributos desejáveis, mas está correto mesmo assim. Nós não arrendondáriamos Pi para 3 siplesmente porque números irracionais são incovenientes certo ?

Eu não nego as vantagens de se tratar jogos clássicos como algo que possar ser otimizado: emuladores de N64 empregam um monte de texturas de alta resolução e 1080p upscaling, enquanto o SNES provêem 2x anti-aliasing for Mode7 graphics e cubic-spline interpolation para audio samples. Estes jogos emulados parece e soam melhores. Enquanto não há nada de errado com isto, mas é o contrário do objetivo que é emular com precisão e fidelidade. Estas técnicas de otimização tipicamente fazem com que seja mais dificil haver a opção de se emular com precisão.

Outro grande problema na área aonde a precisão é um benefício, é trabalhos criados por fãs, ROM hackers, e desenvolvedores de homebrews. Poucos deles tem acesso para rodar um código em um hardware real, então eles preferem rodar seus projetos em softwares usando emuladores. Infelizmente, emuladores speed-oriented irão ignorar as limitações de hardware. Isto nunca foi um problema para um jogo comercial: pois se testado em um hardware real, o bug será descoberto e resolvido. Mas você só pode testar em um emulador específico, no qual bugs tendem a persistir.

Eu posso dar vários exemplos. As criações de fãs como Dragon Quest 1&2, Dual Orb 2, Sailor Moon: Another Story e Ys 4, todos sofrem com problemas de textos invisíveis como resultado de writing na video RAM enquanto o processador de video está ocupado renderizando a tela. Poucos destes títulos foram concertados.

Nós sabemos desta limitação de hardware desde 1997, que consiste em one-line code fix, mas a maioria dos emuladores populares não suportam este tipo de comportamento. Como resultado, as alterações por fãs feitas somente para emuladores específicos continuam a ter problemas e travam. Quem gostaria de usar um emulador mais preciso mas que nunca irá rodar jogos feitos por fãs ?

E não para por ai. O hardware original tem um delay com a unidade matemática para resultados de multiplicação e divisão. De novo, qualquer jogo comercial lançado respeitava este delay, mas jogos feitos por fãs não, implicando por exemplo em musíca cortada em Zelda.

Ou um emulador ignora o fato de que o processador de som escreve echo samples na shared RAM. Não é um problema até você aparecer com hacks que usam tamanhos de echo buffer não realistas, que acabam se tornando um overwriting no programa de audio na memória, dando crashs. O que fez com que vários jogos do Super Mario feitos por fãs dessem problemas.