Curiosidades

Curiosidades Técnicas:

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

Nesta minha segunda conversão, certamente a parte mais difícil foi o carregamento do jogo. O jogo era todo compactado na fita, e era descomprimido pelo carregador, mas isso era feito de uma forma bastante confusa. Era impossível estabelecer a correlação necessária entre código fonte e código carregado. Então o processo teve de ser revertido, os dados expandidos "na marra" e depois recomprimidos no carregador final de MSX.

Houve um ou outro aspecto desafiador, mas envolvendo melhorias no jogo, como por exemplo a inclusão de suporte à mouse. Não era possível usar a BIOS/SubROM por duas razões:

• Ficaria lentíssimo, já que o jogo destrói vários aspectos vitais ao chaveamento de slots do MSX-DOS e boa parte do MSX-DOS teria de ser restaurado a cada leitura de mouse.
• Não funcionaria em MSX1, já que a BIOS do MSX1 não suporta mouse

Estes fatos forçaram o desenvolvimento de um driver de mouse que funcionasse em todos os MSX, do MSX1 a 3.57MHz até um OCM a 20MHz. Esta parte não foi tão simples, dado que a documentação sobre acesso direto para a leitura do mouse é bastante esparsa.

Como o jogo mantém a fluidez de simulação e interatividade com o usuário? (por Daniel Caetano)

Para minha grande surpresa, me deparei com algo que jamais pensei ver em um jogo de um micro de 8 bits: multitarefa. O jogo implementa um sistema de task-switch preemptivo, usando a interrupção de vídeo como ativador da troca de contexto. O sistema é bastante bem feito, e simples, usando multiplas pilhas: quando ativada a troca de contextos, a pilha atual é trocada na interrupção e, ao sair da interrupção, a execução já está em outro processo. Em alguns momentos (quando a simulação está em pausa), esta troca de contexto é desativada.

Até onde pude perceber, o jogo tem 3 processos em paralelo, sendo um deles responsável pela simulação, outro para a animação do mapa e outro pra a interação com o usuário. Posso estar enganado quanto à função de algum dos processos (não fiz essa análise a fundo), mas um certamente é relativo à simulação, em paralelo com a interação com o usuário. Isso permite uma interação constante com uma simulação constante, fluida, sem slow-downs e sem a necessidade de implementar o jogo em turnos.

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. Como no 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 foi feita para melhorar o visual, torná-lo mais próximo ao visual do SimCity em outros equipamentos. Pela mesma razão do Ghosts'n Goblins, a conversão da palheta é dinâmica.

Anteriormente foi dito que não era possível um jogo de Spectrum ficar tão rápido no MSX. Agora SimCity foi convertido com velocidade "full". Como se explica isso? (por Daniel Caetano)

SimCity é um jogo muito complexo e grande parte do tempo de CPU é gasto com tarefas que nada têm a ver com o vídeo... sendo a atualização do vídeo feita com menos freqüência que em um jogo de ação. Na adaptação o update da tela é feito em 6 etapas, uma em cada interrupção, o que faz com que a tela seja atualizada no total 10 vezes por segundo. A este framerate a perda de velocidade é bem minimizada, mas ainda existe.

Entretanto, foi possível otimizar algumas rotinas do jogo, que faziam trabalho replicado desnecessário, além de mudar o ponteiro do mouse de shape para sprite. Como as rotinas do Spectrum que realizavam este processo não eram as mais eficientes do mundo, o ganho de desempenho aí foi substancial. Com isso, a velocidade do jogo a 3.57MHz acabou ficando bem próxima da velocidade do jogo no Spectrum. A 7.16MHz foi necessário incluir temporização com HALT, para evitar que o jogo ficasse muito rápido, ficando o jogo na velocidade esperada.

De onde veio a música do jogo, que eu nunca havia visto no Spectrum? (por Daniel Caetano)

A música veio do próprio jogo de Spectrum. Por alguma razão que foge ao meu conhecimento, parece que a música nunca rodou nos emuladores e, talvez, nem rode em todos os Spectrum 128; em muitos destes, ao tentar carregar o jogo no modo 128 (em que a música tocaria), ocorre um reset, sendo necessário rodar o jogo no modo 48K, sem música. No MSX, entretanto, se houver 128K de Mapper, o jogo entrará com a música normalmente, mesmo em MSX1 (lembrando que a BIOS precisa estar modificada para que isso funcione), não havendo bugs conhecidos nesta parte.

Por que mapper e não megaram? (por Daniel Caetano)

Porque a mapper é a extensão de RAM padrão do MSX e porque facilitava a adaptação, já que a mapper funciona de maneira muito similar ao mapeamento do Spectrum (sendo a mapper do MSX muito mais flexível, claro).

Curiosidades Não-Técnicas:

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

A música de PSG do próprio jogo.

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

Nenhuma, foi na correria (não dava tempo de comer).

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

Guaraná Ideal.

Visitante #64359 desta página