Curiosidades

Curiosidades Técnicas:

Qual a parte mais complicada da conversão? (por Daniel Caetano)

Como foi minha primeira conversão completa de Spectrum para MSX, a maior dificuldade foi tomar conhecimento de todos os detalhes do ZX Spectrum, e compilá-los em um manual que, em breve, divulgarei. Este trabalho durou cerca de 15 dias e foi bastante complexo, pois muitas fontes de informação estão incompletas ou simplesmente incorretas. Em alguns momentos foi necessário recorrer até mesmo ao disassembly da ROM do Spectrum.

Mas acho que não parou por aí, não. A segunda grande dificuldade foi tornar o jogo minimamente veloz no MSX. A terceira foi fazer com que todas as músicas coubessem no pequeno espaço disponível na VRAM. Por fim, o jogo possuia alguns bugs de programação realmente chatos de serem identificados, o que foi bastante incômodo.

Por que as cores do jogo diferem das do ZX Spectrum em MSX1? (por Daniel Caetano)

Em geral, os jogos adaptados para MSX1 diferem um pouco em colorização. Entretanto, na conversão do Ghosts'n Goblins, tentei tornar as mudanças mínimas e com a alteração mais agradável possível, sem perda de cores ou definição. No modo MSX2, entretanto, a conversão de cores é perfeita, estando presentes todas as cores, em seus tons exatos.

Para que isso fosse possível, entretanto, tive de deixar a conversão de cores feita de forma "dinâmica", durante a execução do jogo.

Por que o jogo ficou bem mais lento que no Spectrum? (por Daniel Caetano)

Ghosts'n Goblins é um jogo muito intensivo com relação ao Z80, já em sua versão ZX Spectrum. Na conversão MSX, não foi possível otimizar muita coisa, isto é, não foi possível pré-converter os gráficos do jogo, o que aceleraria um pouco o jogo. Mas isso não foi possível porque o jogo não tem framebuffer e faz operações direto na VRAM do Spectrum para conseguir gerar os efeitos de scroll suave nas duas direções simultaneamente. Ocorre que se o formato dos "padrões" for modificado para o formato do MSX, o resultado é que todas estas operações ficariam ainda mais custosas, ganhando portanto de um lado (outs para o VDP), mas perdendo muito de outro (scroll da imagem).

Por essas e por outras, é necessário pelo menos um MSX2 a 7MHz para tirar proveito do jogo em velocidade similar à do Spectrum.

Por que o jogo perde detalhes nas cores em micros com 3.57MHz? (por Daniel Caetano)

Na realidade, as cores estáticas são um truque para que a tabela de cores não precise ser atualizada a cada frame, diminuindo o overhead da adaptação, permitindo que o jogo funcione em velocidade minimamente razoável a 3.57MHz e, ao mesmo tempo, não fique completamente em preto e branco. Vale lembrar que é possível mudar o modo de cores usando a tecla SELECT.

Por que o scroll no MSX não é tão suave quanto no Spectrum? (por Daniel Caetano)

Mesmo a 7MHz e em MSX2, com um VDP bem mais rápido que o do MSX1, o jogo fica bastante lerdo sem frameskip. Assim, por padrão, o jogo entra com frameskip, ou seja, ao invés de pintar todas as telas, ele pinta uma sim e uma não. Isso permite que a velocidade a 7MHz, no modo colorido, o jogo tenha a velocidade similar á do Spectrum.

Em micros bastante mais rápidos que possam ser desenvolvidos no futuro (como o OCM, por exemplo), talvez seja possível rodar o jogo sem qualquer frameskip. Vale lembrar que é possível desligar o frameskip com a tecla HOME.

De onde vieram as músicas do jogo? Onde elas foram colocadas, já que não havia espaço na RAM? (por Daniel Caetano)

As músicas do jogo vieram de outros dois jogos: do Ghosts'n Goblins do Amstrad CPC e do Ghouls'n'Ghosts do próprio ZX Spectrum (128). As músicas foram pegas no formato AY, que foi extraído para o formato PSG... e, como não havia espaço suficiente na RAM do MSX, as músicas foram armazenadas nos 48KB restantes da VRAM, em MSX2 ou superiores (já que todo MSX2 tem pelo menos 64K de VRAM).

Mas ler a música da VRAM não fica lento? (por Daniel Caetano)

De fato, a leitura simples da VRAM ficou lenta. Por esta razão, foi implementado um sistema de buffer em RAM (256 bytes), que é preenchido nos poucos momentos de ociosidade da CPU. Com este recurso, foi possível ter a música tocando a partir da VRAM com o mesmo desempenho da música tocando direto da RAM.

Mas as músicas PSG são enormes, como couberam tantas músicas em 48K de VRAM? (por Daniel Caetano)

Não há como negar que as músicas do tipo PSG dão enormes. No total, as músicas do jogo somam 160KB no formato PSG. Por esta razão, houve a necessidade de criar um compressor que compactasse as músicas de forma que elas ficassem menores e pudessem ser tocadas sem serem descomprimidas. Isso custou umas duas semanas de trabalho, até que a primeira versão do padrão de música MPM ficou pronto (MSX PSG Music file). O compressor fez com que os 160KB de música se tornassem meros 38KB (23,8% do tamanho original).

O padrão MPM foi criado com o objetivo de reduzir o tamanho das músicas sem aumentar em demasia o consumo de CPU pelo replayer. MPM players e programas de conversão entre formatos logo serão disponibilizados.

É mais simples usar a VRAM que mapper ou MegaRAM para as músicas? (por Daniel Caetano)

Com relação à mapper, não; Mapper é mais fácil. Entretanto, entre requerer mapper e requerer 64KB de VRAM, prefiro este último, já que todo MSX2 tem 64KB de VRAM ou mais, mas nem todos possuem mapper. A solução MegaRAM seria útil para usuários brasileiros com MSX1, mas seria inútil para usuários da Europa e, adicionamente, usar a MegaRAM seria razoavelmente mais complexo (e, talvez, mais lento) que usar a VRAM. Sei que mapper funciona em MSX1 (o meu MSX1 suporta), mas o número de usuários que possuem essa configuração não justificaria o trabalho.
O único problema que tive usando a VRAM foi um completamente inesperado: o VDP se comporta de forma distinta durante a escrita e leitura da VRAM. Na escrita, ele sempre atualiza corretamente o endereço, ou seja, se for escrito no endereço 7FFFh da VRAM, a próxima escrita será no endereço 8000h. Na leitura, entretanto, existe um "bug", que faz com que depois de ler, por exemplo, o endereço 7FFFh, o próximo endereço a ser lido será o 4000h. Isso me deu muitas horas de dor de cabeça, até que descobri este "detalhe" (que não me lembro de ter lido em qualquer lugar) através de um debug pelo BlueMSX (que emula corretamente a característica do VDP).

Li em algum lugar que o jogo original tinha bugs e que usa os bits 3 e 5 do registrador F. Isto é verdade? (por Daniel Caetano)

Sim, as duas coisas são. O jogo tinha uma porção de bugzinhos estranhos. Um deles era justamente o fato de o jogo fazer um RET sem ter feito o último POP AF em uma dada rotina. Isso fazia com que o jogo retornasse para o endereço apontado por AF (!) que, no Spectrum real, com os valores corretos dos bits 3 e 5, acaba sendo um endereço na ROM BIOS e que, após algumas instruções sem nexo, volta para a execução normal. Como no MSX isso não acontecia (a ROM BIOS do Spectrum não está onde o jogo gostaria), o jogo travava ou o micro resetava. A correção foi reescrever a rotina para fazer o correto POP AF antes do RET.

Um outro "bug" (que aparece apenas na conversão), comum em jogos de Spectrum, é que durante o scroll do demo do jogo ele não tinha qualquer pudor em escrever na área de 0000h a 4000h, que no Spectrum é ROM... Mas na adaptação pra MSX, é RAM! A correção foi criar uma rotina que faz um "clipping" para não deixar escrever nesta área da RAM.

Finalmente, um outro "bug" comum (que aparece apenas na conversão) é que o jogo usava o endereço FFFFh para armazenamento temporário do High-Score e isso fazia o jogo travar no MSX, quando o jogador batia um recorde. A solução foi mover esta área temporária para outro lugar.

Curiosidades Não-Técnicas:

Quais as músicas que foram "tema" do desenvolvimento? (por Daniel Caetano)

AC/DC - Highway to Hell e as músicas de PSG do próprio jogo.

Qual era a alimentação durante o desenvolvimento? (por Daniel Caetano)

As mais diversas, de Chocookie até Miojo.

E a bebida oficial do projeto? (por Daniel Caetano)

Suco de Uva DelValle Light!

Visitante #84172 desta página