Precisão Demanda Poder (Parte 3)

Precisão Demanda Poder: A Saga de 3GHz de Um Homem para Construir o Emulador Perfeito de SNES (III)

Table of Contents

• 1. Emulando os processadores adicionais
• 2. Preciso o suficiente?
• 3. Para Fechar
• 4. META

1 Emulando os processadores adicionais

Um dos aspectos divertidos de um sistema baseado em cartuchos é que você está plugando um PCB diretamente no seu sistema. Portanto, você pode inserir processadores adicionais, geralmente processadores digitais de sinais, diretamente ao cartucho. Isto te dá uma vantagem extra contra os títulos de seus competidores. Os coprocessadores mais populares para o SNES foram o SuperFX para renderização de polígonos e rotação de sprites (usados em Starfox e Super Mario World 2) e o DSP-1 para matemática 3D (usado em Pilot Wings e Mario Kart).

Geralmente estes processadores são tão segregados do processador anfitrião que é possível implementá-lo usando emulação de alto nível¹. Isto não é único aos coprocesssadores SNES; você também verá isto na emulação de microcódigo do N64, entre outras áreas.

A ideia aqui é não pensar em instruções individuais, mas no que um grupo inteiro delas faz em conjunto. Em outras palavras, pense sobre um programa em termos de funções como "renderize um triângulo nestes pontos" ou "gire este sprite de N graus". É possível então simular estas operações com sobrecarga virtualmente nula. Infelizmente, esta abordagem também descarta toda a informação de temporização requerida para a execução de cada instrução individual. E o pior de tudo, geralmente isto é tudo menos perfeito: pequenos casos limítrofes, idiossincrasias e falhas do jogo original são perdidas, resultando em uma operação sutilmente diferente.

A abordagem de emulação de baixo nível é tratar o DSP assim como um processador regular: execute cada instrução individual, uma por vez. Jogos não mais rodarão mais rápido do que realmente deveriam, e os casos excepcionais funcionarão todos corretamente. Mas isto é imensamente mais exigente. Enquanto Super Mario Kart com emulação de alto nível roda tão rápido quanto Super Mario World, um jogo sem coprocessadores, ele roda de 25% a 30% mais lentamente quando em emulação de baixo nível. DSPs são de fato bastante poderosos, tipicamente rodando a 21 MIPS ou mais, mesmo nos tempos do SNES.

Emulação de baixo nível também é uma operação bem dispendiosa, falando monetariamente: obter o código do DSP requer derreter o circuito integrado com ácido nítrico, escanear a superfície do chip com um microscópio eletrônico, e daí, ou pintar e ler manualmente, ou alterar fisicamente e monitorar os traços para extrair as ROMs de programa e de dados. Este tipo de serviço pode custar milhões de dólares para ser feito profissionalmente, devido ao conhecimento altamente especializado e ao equipamento envolvido. Graças aos esforços de um indivíduo que atente pelo nome "Dr. Decapitator", nós temos sido capazes de extrair estes dados de quase uma dúzia de chips apenas pelo custo dos materiais.

Uma vez terminado, você deve notar que DSPs são geralmente especialidades únicas. Os conjuntos de instruções devem ser reconstruídos com engenharia reversa de códigos binários e emulados com virtualmente nenhuma documentação afinal. Este é um processo custoso, e mostra o nível de dedicação necessário para emular precisamente estes jogos.

2 Preciso o suficiente?

Honestamente, mesmo com todos esses problemas acima listados, nós apenas arranhamos a superfície da emulação precisa. Tome o caso do DICE, o emulador de circuito digital integrado². Este é um emulador que trabalha em nível de transistor para uma recriação absolutamente perfeita dos primeiríssimos video games já criados. Para rodar Pong em cerca de 5 a 10 fps, DICE requer um processador de 3GHz. Sim, você leu isso corretamente: nenhum processador de nosso tempo pode rodar Pong no nível de circuito em velocidade completa. Não é que DICE seja um programa lento; de fato ele é bastante otimizado. É que existe aqui uma sobrecarga enorme em simular cada delay de propagação de transistor.

Mas um dia isto será possível. E eu estarei feliz que este clássico tenha sido completamente replicado para as gerações futuras.

Aplicar a abordagem do DICE para sistemas mais modernos seria problemático, porém. Tome o caso do Visual6502. Alguns indivíduos geniais usaram uma técnica não muito diferente de nosso método de extração de DSP para escanear a superfície da CPU 6502, usada no Nintendo e no Commodore 64, entre outros. Eles vetorizaram os transistores e providenciaram uma simulação de alto nível do chip, a qual desconsidera os delays de propagação. Este código foi famosamente demonstrado em Javascript mas também foi portado para C e otimizado. Mesmo com os atalhos que ele toma, computadores ainda não são rápidos o bastante para usar esta implementação em emulação.

Assim como eu gostaria que todo emulador suportasse cada delay de propagação, na realidade isto simplesmente não é possível. Passa a ser honesto em dizer que nós jamais veremos hardware capaz de emular um N64 neste nível em taxas de frame jogáveis nos limites de nossas expectativas de vida.

De fato, é duvidoso que isto seja possível até mesmo para o SNES. Eu compreendo que em certo nível, o poder da computação moderna tem um peso em determinar o quão preciso os emuladores podem vir a ser.

O compromisso que eu tenho mantido foi o de construir um projeto tosco que poderia ser semelhante ao hardware real e isolar limpamente cada processador, compartilhando apenas o estado que os chips reais compartilham. Enquanto o objetivo é sempre casar os resultados de todas as operações em hardware real perfeitamente, minha abordagem pelo menos cria um sistema emulado que é virtualmente indistinguível do hardware real. Mas ao contrário do DICE, não é uma forma digital perfeita do projeto original exato do hardware.

O objetivo não é melhorar o hardware, o objetivo é chegar tão perto do hardware quanto possível. Quando se chega ao N64 e além, eu noto que mesmo essa abordagem não é mais prática. Eu não tenho respostas fáceis aqui, mas eu sei que ninguém pode realisticamente ter esperança de desenvolver um emulador que não possa rodar mesmo em um simples frame por segundo nos mais poderosos sistemas do mundo

3 Para Fechar

O que me preocupa é que, em sua maioria, os desenvolvedores temem até mesmo em utilizar metade do poder de processamento disponível nos sistemas atuais. Hardware antigo fica estigmatizado nos requisitos de sistema dos mais antigos e menos precisos emuladores, que se tornam benchmarks para futuros esforços.

Eu não vejo por que não devemos utilizar cada última gota de poder que temos disponível hoje – ou talvez mesmo um pouco mais em antecipação de um hardware mais veloz no futuro. Os emuladores antigos não vão desaparecer: eles ainda estarão aí para os camaradas com hardware mais antigo e mais lento.

Para aqueles que tenham sistemas mais poderosos, por favor deem uma chance aos emuladores mais precisos! Desenvolvedores precisam desesperadamente melhorar a fidelidade de sua emulação, e eles precisam de audiência que possa encorajá-los a continuar.

---

4 META

Table 1: META

Título Original	Accuracy takes power: one man's 3GHz quest to build a perfect SNES emulator
Autor	byuu
Link Original	http://arstechnica.com/gaming/2011/08/accuracy-takes-power-one-mans-3ghz-quest-to-build-a-perfect-snes-emulator/3
Link Arquivado	http://archive.is/o76NN

---

Footnotes:

¹

N.T.: Digital Integrated Circuit Emulator; uma clara referência ao nome que a pastilha de circuito integrado é chamada em inglês

²

Do inglês HLE, high level emulation.

Created: 2018-03-24 sáb 20:03

Validate

Precisão Demanda Poder (Parte 2)

Precisão Demanda Poder: A Saga de 3GHz de Um Homem para Construir o Emulador Perfeito de SNES (II)

Table of Contents

• 1. Um Emulador para Todo Jogo
• 2. Mas Sério, 3GHz? Cê tá brincando?
• 3. Então para Onde Os 2.7GHz Vão? Sincronização
• 4. META

1 Um Emulador para Todo Jogo

É possível prever um dia ruim no futuro quando um usuário final precisar do ZSNES v1.42 para uma lista de quatro traduções, SNES9x v1.51 para outros seis ROM Hacks, e bsnes v080 para algum jogo japonês obscuro. Isto acaba sendo oneroso.

Você tem que entender que emuladores, também, têm seus tempos de mostruário. Isto é especialmente verdadeiro para aqueles como o ZSNES que são escritos em puro assembly x86. Você simplesmente não consegue rodá-lo em seu celular. Travando um hack para rodar somente no ZSNES, você está destinando-o à irrelevância. Assim que o Windows eliminar a compatibildade retroativa no 32-bit, assim como ele já fez com o 16-bit, estas traduções e hacks de fãs serão perdidas para sempre. Neste ponto o emulador em si se torna quase como outro console morto, em vez de uma forma para manter os velhos jogos ainda vivos.

E tem toda aquela coisa chata de que jogos SNES deveriam rodar, bem, você sabe, num console SNES real. Criando emuladores que imitam o hardware perfeitamente, oi tão próximo quanto se possa chegar, nós criamos uma plataforma que pode rodar em múltiplos sistemas, e permitimos jogos e hacks que rodem em futuras versões. A ideia é manter os specs do hardware SNES vivos, não apenas a ideia dos jogos.

2 Mas Sério, 3GHz? Cê tá brincando?

É possível para um emulador SNES bem otimizado voltado à velocidade rodar em velocidade máxima usando somente 300MHz de poder de processamento. Você acabará também com centenas de bugs obscuros.

O que tipicamente acontece é que os problemas são especificamente contornados. Tanto ZSNES quanto Snes9x contêm listas internas de uns 50 jogos mais populares. Quando você carrega estes jogos, os emuladores ajustam seus valores de temporamento e consertam certas áreas de código para fazer estes jogos rodarem. É uma melhoria sobre os tempos do Nesticle onde os jogos eram hackados externamente, mas isto ainda é trapacear, não importando o resultado visual final.

O jogador casual que só joga os 20 jogos mais famosos não verá diferenças visíveis entre um emulador requerindo 300MHz e outro requerindo 3GHz, então obviamente ele ficará com o primeiro. Apesar de eu seriamente respeitar e apreciar emuladores voltados à velocidade, açguém preocupado com precisão nada pode além de lamentar a forma que isto trava o progresso. Sem mais jogadores usando os emuladores mais precisos, nós não encontraremos os bugs em todos os jogos que o emulador suporta. Quanto mais pessoas temos jogando os jogos da forma que eles foram intencionados, melhor os emuladores podem se tornar dado que problemas são encontrados e eliminados - não consertando cpodigo específico para cada jogo, mas consertando a precisão do emulador.

A captura de tela abaixo é um grande exemplo de um jogo de nicho. É na realidade um bom jogo de plataforma, mas poucas pessoas ouviram dele falar. É um grande exemplo de porque ainda que os jogos mais populares possam rodar decentemente com emuladores imprecisos, ainda assim precisão importa. Você nunca saberá quando aquele seu jogo favorito um-pouco-menos-comum pode acabar caindo num bug desses. Nas capturas abaixo, você vê um interruptor. Quando este interruptor é acionado em qualquer outro emulador, o jogo trava instantaneamente. O que deveria acontecer é demonstrado nas capturas seguintes: o interruptor move o bloco no meio do campo elétrico. É necessário que isto seja feito para completar o nível e, por conseguinte, o jogo. No nomento deste escrito, bsnes é o único emulador de SNES capaz de jogar completamente este jogo.

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

Video games são uma peça da nossa história, e nós precisamos respeitar o fato de que existe uma forma verdadeira na qual eles foram lançados. Imagine se tivéssemos somente um JPEG de MonaLisa, uma stream RealVideo da aterrissagem na lua, ou uma rendição MIDI de "Walkin in the Air". Nós temos a capacidade de manter o nosso passado vivo, e eu sinto que é quase um dever fazê-lo.

3 Então para Onde Os 2.7GHz Vão? Sincronização

O erro de conceito mais comum em estimar o desempenho de um emulador é que você pode simplesmente observar a taxa de clock do processador primário. Infelizmente, isto realmente não te diz nada. A CPU do Nintendo 64 pode ser clockada em 35 vezes a CPU do SNES, e ainda assim o UltraHLE requer o mesmo poder de processamento que o ZSNES.

As demandas primárias de um emulador são o total de vezes por segundo que um processador deve sincronizar com outro. Um emulador é um processo inerentemente serial. Tentar se apoiar nos processadores multicore de hoje em dia leva a toda espécie de problemas de temporização. Pegue a analogia da linha de montagem: uma pessoa descarrega as caixas, a outra passa o scan nelas, a outra abre, a outra começa a colocar os itens juntos etc. Sincronização é o equivalente de obstruir e limpar completamente a linha, e então iniciar um novo produto. Isto é um incrível golpe no fluxo. Ele anula completamente os efeitos do pipeline e da execução fora de ordem. Quanto mais você tem que sincronizar, mais rápido sua linha de montagem tem que se mover para prosseguir.

Vamos comparar as razões de sincronização entre o ZSNES e o bsnes:

Table 1: DADOS COMPARATIVOS

Componente	ZSNES	bsnes
S-CPU	600.000	21.477.272
S-SMP	256.000	24.576.000
S-DSP	032.000	24.576.000
S-PPU	015.720	21.477.272
Total	903.720	92.106.544

Vamos começar com a CPU, que tipicamente é assumida como rodando a 3.58MHz. Esta taxa aplica-se ao número de ciclos executados por segundo. Uma instrução típica pode consumir de quatro a oito ciclos, e ZSNES sincroniza uma vez por instrução. Mas para ficar ainda mais técnico, ciclos são quebrados em delays de barramento que requerem temporização no nível bruto do oscilador. A CPU do SNES está clockada em 21.47MHz. O mesmo se aplica ao SMP, cujo oscilador está clockado em 24.58MHz.

Quando chegamos ao vídeo, 99% dos jogos não tentam modificar os registradores de exibição enquanto se está montando a tela. Isto permite que scanlines inteiras sejam traçadas de uma vez, requerendo 262 scanlines X 60 frames por segundo de sincronização. Mas rode um jogo como Air Strike Patrol, que escreve no registrador de brilho múltiplas vezes por scanline, e você terá que sincronizar em cada ciclo de clock se quiser precisão perfeita.

Quando chegamos ao áudio, virtualmente todos os títulos rodarão bem se você apenas sincronizar pela taxa de áudio para casar a frequência de 32kHz do SNES. Mesmo assim, rode um título como Earthworm Jim 2 e você verá que os efeitos de som irão se perder se não sincronizar por ciclo. koushien 2 pode até mesmo travar periodicamente.

Então, apesar de bsnes rodar dez vezes mais lentamente que ZSNES, ele é literalmente umas cem vezes mais preciso. Na verdade, é de fato bastante impressionante que isto seja possível em meros 3GHz. Somente porque eu tenho utilizado multithreading cooperativo e sincronização just-in-time, técnicas que eu nunca vi antes usadas em emulação, eu consegui melhorar o desempenho que o bsnes atualmente tem. Máquinas de estados, que dirá agendamento de kernel, simplesmente não servem para a tarefa.

A observação mais imediata é o fato que mesmo em um centésimo da taxa de sincronização, ZSNES ainda roda bem a maior parte dos jogos. Não há por que negar, sincronização perfeita absoluta raramente é requerida. Mas o fato é, há casos em que ela é necessária. Sendo a CPU do SNES lenta como é, muitos jogos originais levam o sistema aos seus absolutos limites.

Se você não calcular o tempo perfeitamente, acabará em um eterno jogo de bate-na-toupeira. Conserte um jogo para quebrar outros dois, conserte-os e quebre mais dois. Conserte-os para quebrar o jogo inicial de novo. Você só precisa olhar os changelogs dos últimos quinze anos para verificar isto.

4 META

Table 2: META

Título Original	Accuracy takes power: one man's 3GHz quest to build a perfect SNES emulator
Autor	byuu
Link Original	http://arstechnica.com/gaming/2011/08/accuracy-takes-power-one-mans-3ghz-quest-to-build-a-perfect-snes-emulator/2
Link Arquivado	http://archive.is/lXA7Y

Created: 2018-03-24 sáb 20:06

Validate

Precisão Demanda Poder (Parte 1)

Precisão Demanda Poder: A Saga de 3GHz de Um Homem para Construir o Emulador Perfeito de SNES (I)

Table of Contents

• 1. INTRO
• 2. Fazendo em software
• 3. Por Que Precisão Importa
• 4. META

---

Emuladores para jogar antigos jogos são imensamente populares online, com argumentos regulares surgindo violentamente sobre qual emulador é o melhor para qual jogo. Hoje apresentaremos um outro ponto de vista de um gentil-homem que criou o emulador de Super Nintendo bsnes. Ele deseja compartilhar seus pensamentos sobre a mais importante parte da experiência de emulação; a precisão.

---

1 INTRO

Não é necessário muito poder bruto para jogar Nintendo ou SNES em um PC moderno; emuladores podiam fazer isso nos anos 90 com meros 25MHz de poder de processamento. Mas emular estes consoles precisamente - bem, este já é um outro desafio completamente diferente; emuladores precisos podem precisar de uns 3GHz de poder para recriar fielmente tecnologia anciã. Neste espaço nós daremos uma olhada em por que precisão é tão importante para emuladores e por que é tão difícil de conseguir.

Simplificando, precisão é a medida de quão bem o software de emulação imita o hardware original. Compatibilidade aparente é a mais óbvia medida de precisão - um jogo antigo rodará no meu emulador novo? - mas tal visão estreitada pode ignorar muitos probleminhas. Na realidade, a maior parte do software roda com grande tolerância a detalhes de temporização e parece funcionar normalmente mesmo se a temporização estiver desajustada de uns 20%.

Então vem a questão: se podemos alcançar compatibilidade básica, por que se importar melhorando a precisão além quando tal melhoria virá com grandes custos em velocidade? Duas razões: desempenho e preservação.

Primeiro, desempenho. Vamos pegar o caso de Speedy Gonzales. Este é um jogo de plataforma do SNES sem nenhuma funcionalidade de salvar, e tem umas 2-3 horas de duração. À primeira vista, parece que ele roda bem em qualquer emulador. Mesmo assim, quando se chega no estágio 6-1, você pode rapidamente notar a diferença entre um emulador preciso e um rápido: existe um interruptor, requerido para completar o nível, onde o jogo irá travar em deadlock se um caso-limite raro do hardware não é emulado. Podemos imaginar a frustração de perder instantaneamente três horas de progresso e estar de frente a um jogo não-finalizável. A não ser que o software faça exatamente o que o hardware costuma fazer, o jogo permanece injogável.

Ou imagine Air Strike Patrol, onde uma sombra é desenhada debaixo de seu avião. Isto é feito usando efeitos de rasterização mid-scanline, que são extraordinariamente intensivos em termos de recursos para emular. Mas sem os efeitos de rasterização, a sombra do seu avião não vai aparecer, assim como você vê no screenshot abaixo. Isso é fácil de negligenciar, especialmente se você não sabia que ela deveria estar ali. Mas uma vez que você a nota de fato, você vê que ela é bastante útil. Seu avião tem a capacidade de soltar bombas, e esta sombra age como um tipo de sistema de mira para determinar onde as bombas cairão. Algo que fica um pouco mais difícil sem este efeito aparentemente menor.

O segundo assunto é preservação. Dê uma olhada nos hardwares da Nintendo Game&Watch. Estes dispositivos surgiram em 1980, e por ora a maior parte dos 43 milhões produzidos falharam devido à antiguidade ou foram destruídos. Ainda que eles sejam relativamente obteníveis, sua escassez só aumentará, dado que nenhuma unidade adicional será produzida. Este mesmo problema se estende a qualquer hardware: uma vez que se foi, se foi de vez. Neste ponto, emuladores são a única forma de experimentar estes velhos jogos, então eles devem ser capazes de fazê-lo precisamente.

Mas esta precisão vem a um sério custo. Fazer um emulador duas vezes mais preciso o tornará umas duas vezes mais lento; dobre esta precisão novamente e você o terá umas quatro vezes mais lento. Ao mesmo tempo, as recompensas por esta precisão diminuem rapidamente, já que muitos jogos parecem e agem "jogáveis" nos mais modestos níveis de precisão do emulador. (A maior parte dos emuladores almeja um "pote de ouro" de 95% de compatibilidade com desempenho optimal.)

Não há nada de errado com emuladores menos precisos mas mais velozes, e tal código pode rodar em hardware com pouco recurso como celulares e dispositivos de jogo portáteis. Estes emuladores são também mais apropriados para uso em laptops onde a vida da bateria é uma preocupação. Mas existe algo a ser dito sobre buscar precisão, também, e isto é o que eu tenho tentado em meu próprio trabalho. É isto o que importa para mim.

2 Fazendo em software

De volta ao fim dos anos 90, Nesticle era facilmente o emulador NES mais famoso, com requisitos de sistema em volta de uns 25MHz. Este desempenho veio a um custo significativo: imagens dos jogos eram hackadas para funcionar neste emulador especificamente. Traduções e hacks feitos por fãs confiavam nestas estranhezas que tornavam os jogos injogáveis tanto em hardware real quanto em outros emuladores, criando um tipo de efeito lock-in que levou muito tempo para ser desfeito. Naquele tempo, as pessoas não se preocupavam em como os jogos originalmente pareciam e jogavam em geral, eles apenas se preocupavam em como eles ficavam neste ambiente artificial e arbitrário.

Nestes dias, os mais dominantes emuladores são Nestopia e Nintendulator, requerendo 800MHz e 1.6GHz respectivamente para alcançar velocidade total. A necessidade de velocidade não é porque estes emuladores não sejam otimizados: é porque eles são uma recriação bem mais fiel do hardware do NES em software.

Agora, compare com o mais antigo emulador de N64, UltraHLE, cujos requisitos de sistema são um fracote sistema Pentium II de 350MHz. Para o observador casual, pode ser bastante espantoso ver Mario 64 requerendo menos poder de processamento que o Mario Bros original.

Minha experiência em emulação é no campo do SNES, trabalhando no emulador bsnes. Eu me apaixonei pelo ideal por detrás do Nestopia, e quis recriar este nível de precisão para o Super Nintendo. Como se mostrou, o mesmo nível de dedicação à precisão elevou os requerimentos no intervalo de 2 a 3GHZ, dependendo do título.

Nestopia deu certo porque seus requerimentos eram pequenos para o seu tempo, porém eu não tenho dúvida que liberá-lo em 1997 teria sido desastroso. Desde que meu emulador definitivamente requer um sistema computacional com mais poder que metade do mercado, eu vi em primeira mão o efeito de especificações altas e a repercussão que isto causa. É mais fácil acusar o programa que admitir que seu computador não é poderoso o suficiente, mas a realidade é que imitar um console de jogos completo em software é um processo intenso.

3 Por Que Precisão Importa

Então se um emulador parece rodar todos os jogos corretamente, por que devemos melhorá-lo? A resposta simples é porque isto melhora as coisas que ainda não conhecemos sobre. Isto é particularmente proeminente em software menos popular.

Como um exemplo, compare a animação da Triforce giratória da abertura de Legend of Zelda nos emuladores ZSNES e bsnes. No anterior, as triforces completarão suas rotações muito rapidamente como resultado de a CPU estar rodando mais de 40% mais rápido que um SNES real. Estes são pequenos detalhes, mas se você tem um olho para precisão, eles podem ser bastante incômodos.

Eu encontrei dúzias de títulos com problemas obscuros. Algumas vezes a emulação mais correta, mais precisa, produz um resultado "errado". O modo attract de Super Bonk na realidade dessincroniza, causando Bonk a ficar travado perto do muro em muitos sistemas reais. E Starfox sofre de sérios problemas de retardo ao longo do jogo. Estes certamente não são atributos desejáveis, mas são corretos de qualquer forma. Nós não arredondamos pi para 3 só porque irracionais são inconvenientes, certo?

Eu não nego as vantagens de tratar jogos clássicos como algo que possa ser melhorado: emuladores de N64 empregam impressionantes pacotes de texturas de alta resolução e 1080p-upscaling, enquanto emuladores de SNES geralmente proveem 2x anti-aliasing para gráficos Mode7 e interpolação cúbica para samples de áudio. Tais jogos emulados tem uma melhor aparência. Enquanto não há nada de errado com isto, isto é contrário ao objetivo de um escrever um emulador preciso fiel ao hardware. Estas técnicas de melhoria tipicamente o tornam mais complicado, até mesmo para permitir a opção de emulação precisa, de fato.

Outra área majoritária onde precisão é um benefício é em trabalhos feitos por fãs, como traduções, ROM Hacking, e desenvolvedores caseiros. Poucos deles têm acesso a odar código em hardware real, então eles geralmente desenvolverão seus softwares usando emuladores. Infelizmente, emuladores voltados à velocidade geralmente ignorarão limitações do hardware. Isto jamais é problema para um jogo desenvolvido comercialmente: uma vez requerido o teste em hardware real, o problema seria rapidamente descoberto e resolvido. Mas se você só pode testar em um emulador específico, tais bugs tendem a persistir.

Eu posso apontar alguns poucos exemplos. As traduções por fãs de Dragon Quest 1&2, Dual Orb 2, Sailor Moon: Another Story e Ys 4 todas sofrem de problema de texto invisível como resultado de escreverem na RAM de vídeo enquanto o processador de vídeo o travou para renderizar a tela. Apenas metade destes títulos foi subsequentemente consertada.

Nós já sabíamos desta limitação do hardware desde 1997, a qual consistia de uma simples linha de código para consertar, mas o emulador mais popular não suporta este comportamento. Como resultado, gtraduções feitas somente para este emulador continuarão a causar problemas e lock-in. Quem iria querer usar um emulador mais preciso que não pudesse rodar um grande número de suas traduções favoritas?

Isto não para por aqui, porém. O hardware original tinha um delay sob a solicitação para a unidade matemática para resultados de multiplicação e divisão. Novamente, qualquer jogo comercial já lançado respeitaria tais delays, mas hacks feitos por fãs levaram a uma música da tradução de Zelda ficar cortada e ao chain-chomp de Super Mario World ficar desordenado.

Ou um emulador pode ignorar o fato que o processador de som escreve 'echo samples' em RAM compartilhada. Não é um problema, até que você conclua hacks que usem echo buffers de tamanhos loucamente irrealísticos, que por sua vez acabam sobrescrevendo todo o programa de áudio em memória, falhando de maneira espetacular. Este pequeno detalhe sozinho tornou dúzias de fases feitas por fãs para Super Mario World injogáveis.

---

4 META

Table 1: META

Título Original	Accuracy takes power: one man's 3GHz quest to build a perfect SNES emulator
Autor	byuu
Link Original	http://arstechnica.com/gaming/2011/08/accuracy-takes-power-one-mans-3ghz-quest-to-build-a-perfect-snes-emulator/
Link Arquivado	http://archive.is/rrZLY

Created: 2018-03-24 sáb 20:04

Validate

Toonz Software, usado pelo Studio Ghibli e 'Futurama', será livre e de código aberto

por Amid Amidi

Com um anúncio, o jogo dos softwares de animação mudou para sempre. `Toonz

System Message: WARNING/2 (toonz.rst, line 14); backlink

Inline interpreted text or phrase reference start-string without end-string.

<http://www.toonzpremium.com/>`__, o software usado pelo Studio Ghibli para produzir filmes como Kaguya-hime no Monogatari, Howl Ugoko Shiro, Gake no Ue no Ponyo, Kaze Tachinu, será transformado em livre e de código aberto para a comunidade de animação a partir de 26 de março

O acontecimento, que pode trazer um impacto potencialmente profundo na indústria da animação, foi possibilitado após a publicadora japonesa Dwango adquirir o software Toonz da companhia italiana de tecnologia Digital Video, que tem produzido o pacote de animação desde 1993.

Ghibli tem usado o Toonz desde a produção de Mononoke Hime, e o novo OpenToonz será chamado "Toonz Ghibli Edition" devido a todas as adições customizadas que Toonz tem desenvolvido ao longo dos anos para o lendário estúdio japonês.

Atsushi Okui, diretor executivo de imagem do Studio Ghibli, explicou que eles escolheram o Toonz desde 1995 "a fim de produzir animação com qualidade cinematográfica sem tensões adicionais", e no desejo por um software que tivesse "a habilidade de combinar animação feita à mão com a pintada digitalmente de uma forma contínua".

Porém, Toonz não é exclusivo da Ghibli e é usado por uma série de outros estúdios, incluindo Rough Draft, que produziu Futurama de Matt Groening com ele, e Folimage, que usou-o para seu mais recente longa, Phantom Boy.

O software ostenta uma extensa história, datada desde 1993, e tem sido usado na produção de muitos longas de Hollywood e séries de TV, como Anastasia da Fox, Balto da Amblimation e The Maxx da MTV, bem como jogos populares como Discworld 2 da Psygnosis. Toonz estava originalmente disponível somente para workstations de alta tecnologia da SGI, e por um período de tempo era parte do braço da Microsoft Softimage, que depois se tornou a Autodesk.

Digital Video continuará a desenvolver e vender o software Toonz, e oferecerá serviços de instalação, configuração, treinamento, suporte e customização para os estúdios. Uma versão premium continuará sendo vendida a "um preço bastante competitivo" para companhias que desejarem investir na customização do Toonz para projetos maiores.

"O contrato com a Dwango, que oferecerá a plataforma de código aberto Toonz para a comunidade de animação, possibilitou a Digital Video a realizar uma de suas estratégias, a saber, tornar o Toonz um padrão mundial para a animação 2D", disse Claudio Mattei, diretor-gerente da Digital Video. "Este acordo será também o início de um novo e excitante plano de adotar o modelo de negócios de código aberto, apoiando o treinamento e a customização do Toonz para novos e antigos usuários".

Toonz não é exatamente um nome muito conhecido, mesmo entre os maiorais da indústria, mas a lista de grandes companhias e projetos que já o tem utilizado (bem como o audível apoio de Ghibli) deve ser o suficiente para convencer muitos artistas a experimentarem-no. Enquanto certamente existirá uma curva de aprendizado para artistas acostumados com os padrões da indústria como Flash e Toonboom, Toonz também é mais hábil para lidar com produções maiores, e os benefícios de longo prazo pela substituição para o código aberto podem se mostrar atrativas para muitos estúdios.

O anúncio do OpenToonz veio em um momento que a animação está experimentando o maior período de crescimento em sua história. A fortemente difundida disponibilidade de hardware está possibilitando a expansão da produção de animação para partes do mundo que não têm sido tradicionais produtoras (como as Américas Central e do Sul, África e Oriente Médio).

Porém, muitos jovens artistas destas regiões não têm recursos para investir em softwares proprietários. É especialmente por isso que vemos o OpenToonz, um software livre para animação 2D profissional, como um completo e total divisor de águas para o avanço da indústria de animação. As portas do dilúvio da animação estão enfim abertas.

---

META

Título Original	Toonz Software Used by Studio Ghibli and ‘Futurama’ Being Made Free and Open Source
Autor	Amid Amidi
Link Original	http://www.cartoonbrew.com/tech/toonz-software-used-studio-ghibli-futurama-made-free-open-source-138111.html
Link Arquivado	http://archive.today/Vn1Eg