Criando um emulador perfeito de Super Nintendo - PARTE 2

É possivel prever um mal dia no futuro quando um usuário final precise do ZSNES v1.42 para fazer por exemplo 4 hacks, Snes9x v1.51 para outros 6 ROM hacks, e bsnesv080 para algum jogo japonês obscuro. Isto começa a ser um fardo.

Vocês tem que perceber que emuladores, também, possuem meia-vida. Especialmente verdade para aqueles como o ZSNES que foi escrito em puras plataformas x86. Você simplesmente não consegue rodar isso no seu celular. Fazendo com que um rom hack rode somente no ZSNES, você está condenando seu hack à irrelevância. Assim como o Windows largou a compatibilidade 32-bit, assim como fez com a 16-bit, estas modificações feitas por fãs serão completamente perdidas para sempre. Chegará a um ponto em que um emulador morra como um console antigo, ao invés de continuar a manter os jogos anitgos vivos.

E há uma imensidão de problemas que fazem com que jogos de SNES não se comportem como ns consoles originais. Criando-se emuladores que imitem o hardware original, ou o mais próximo que conseguirmos, nós criaremos uma plataforma que pode se trabalhar em multiplos sistemas, e permitir que jogos e hacks rodem em uma futuras versões. A idéia é manter as especificidades do SNES vivas, não somente a idéia de jogos.

É possível que um emulador de SNES bem otimizado, com uma velocidade bem orientada rode usando uma velocidade de 300Mhz de processamento. Mas você acabará com centenas de bugs obscuros.

O que tipicamente acontece é que os problemas são especificamente hacks a volta. Ambos ZSNES e Snes9x contêem uma lista interna de 50+ jogos populares. Quando você roda estes jogos, esses emuladores aumentam seus valores de timing e aplicam patchs em certas áreas do código para fazer estes jogos rodarem. Uma importante melhora sobre o Nesticle é que os jogos são hackeados externamente, mas ainda é trapaça, independente do que o visual final resulta.

O gamer casual que joga os 20 melhores jogos não verá diferenças entre um emulador rodando que requere um processamento de 300MHz e outro que requer 3GHz, então optarão pelo mais prático. Entretanto eu respeito e aprecio emuladores com velocidade orientada (speed-oriented), a preocupação com a precisão não ajuda mas lamento o caminho que esta abordagem leva. Sem o apoio de mais jogadores usando emuladores mais precisos, nós não acharemos os bugs em todos os games que os emuladores suportam. Quando mais pessoas tiver jogando com a experiência do jogo original, melhor o emulador pode se tornar,, corrigindo bugs e problemas, não arrumando o código de cada jogo, mas arrumando a precisão do emulador.

As screenshots abaixo é um grande exemplo de um jogo de nicho. É um otimo jogo de plataforma, mas poucas pessoas ouviram falar dele. É um grande exemplo do porque os jogos populares podem rodar decentemente em emuladores não precisos, precisão ainda importa. Você nunca sabe quando aquele seu jogo favorito não tão conhecido irá rodar com bugs como este. Nas screenshots abaixo, você ve um botão (switch). Quando este botão é aitngido em qualquer emulador por ai, este jogo trava instântaneamente. O que deveria acontecer é demonstrado nas screeshots subsequentes: o botão move um bloco no meio do campo elétrico. O que é requerido para completar o level, consequentemente, o jogo. Neste ponto de writing, bsnes é o único emulador de SNES capaz de se jogar este jogo até o final.

O SNES não tem somente um modo de imagem em alta-resolução mas uma variante chamada modo "pseudo-hires". Este modo é útil para se criar um verdadeiro alpha-blending entre os layers do hardware do SNES. Ignorando este modo resulta em layers completamente obstruindo outros, como vemos na imagem abaixo.

Video games são um pedaço de nossa história, e precisamos respeitar o fato que eles possuam uma verdadeira forma como a qual foram lançados. Imagine se tivessemos somente um JPEG da Monalisa, uma transmissão real do pouso na lua ou um MIDI de "Walking in the Air". Nós possuimos a habilidade de manter nosso passado vivo, eu sinto como se fosse meu dever.

A mais comum e errônea concepção é pensar que a performance do seu emulador está relacionada com o clock do processador do seu computador. Infelizmente, esta não é a realidade. O CPU do N64 é 35x mais rápido que o CPU do SNES, mesmo assim UltraHLE requer o mesmo poder de processamento que o ZSNES.

A demanda primária de um emulador é de quantas vezes por segundo um processador pode sincronizar com o outro. Um emulador é inerentemente um processo serial. Atualmente os processadores multi-core levam a diversos problemas de timing. Veja a analogia com um processo de produção: uma pessoa descarrega caixas, outra pessoa escaneia-as, outras as abrem, outras começam a colocar os item juntos, etc. Sincronização é o equivalente a todo o processo do começo ao fim, ai então começa a entrada de um novo produto. É algo bem complexo, pois quanto mais você tem que sincronizar, mais rápido tem que ser o processo de produção.

Vamos comparar as taxas de sincronização entre ZSNES e bsnes:

S-CPU: 600,000 vs 21,477,272
S-SMP: 256,000 vs 24,576,000
S-DSP: 32,000 vs 24,576,000
S-PPU: 15,720 vs 21,477,272
Total: 903,720 vs 92,106,544

Vamos começar com o CPU, o que tipicamente é assumido como rodando a 3.58MHz. Esta taxa aplica a um numero de ciclos executados por segundo. Uma instrução típica pode consumir de quatro a oito ciclos, e ZSNES sincroniza um ciclo por segundo. Para fica ainda mais técnico, ciclos são quebrados em bus hold delays que requerem timing no raw oscillator level (achei melhor não traduzir termos técnicos, não é a minha área). O CPU do SNES oscila a uma taxa de 21.47MHz. O mesmo aplica a o SMP, que oscila a uma taxa de 24.58MHz.

Quanto ao video, 99% dos jogos não tentam modificar os registros de display enquanto a tela está sendo "desenhada". Isto permite que os scanlines sejam desenhados de uma vez, requerendo 262 scanlines * 60 frames por segundo de sincronização. Mas rodar jogos como Air Strike Patrol, que escreve para o registro do brilho do display multiplas vezes por scanline, e voce deve sincronizar a cada ciclo do clock se quiser algo totalmente preciso.

Quanto ao audio, virtualmente todos os títulos rodam bem se voce sincronizar um por taxa de audio para equivaler às 32kHz de frequência do SNES. Ainda assim rodar titulos como Earthworm Jim 2 você irá achar que o som está cortando se não sincronizar por cada ciclo. Koushien 2 pode até travar periodicamente.

Entretanto o bsnes roda dez vezes mais lento que o ZSNES, é literalmente cem vezes mais preciso. na verdade, é impressionante que ele consiga isso com meros 3GHz. Somente porque eu utilizei a cooperacão de multithreading e just-time synchronization, técnicas que nunca vi serem usadas em emulação, eu tive que deixar a performance do bsnes do jeito que está. State Machines, deixam o kernel scheduling, simplesmnete não aptas a tarefa.

A observação mais imediata é o fato que mesmo 1/100th de taxa de sincronização, ZSNES ainda roda bem a maioria dos jogos. Não há duvida disso, uma sincronização perfeita é raramente requerida. Mas o fato é que, há casos que se requerem. Com o CPU do SNES sendo lento, muitos jogos originais puxam o sistema até o limite.

Se você não atinge o timing perfeito, você acabará jogando perpetuamente um jogo de whack-a-mole. Arrumando uma coisa para quebrar duas, arrumando de novo e quebrando mais duas. Você precisa olhar nos changelogs dos ultimos 15 anos para verificar isso.