a5k - Another World / Out of This World portado para FPGA

• Um projeto pessoal de homenagem que implementa em hardware FPGA, sem CPU padrão, a VM, o blitter e o rasterizer de Another World / Out of This World
• O design central consiste em transformar a VM em um processador customizado de verdade e em um SoC que reúne o blitter responsável por copiar/preencher entre framebuffers, o rasterizer que desenha polígonos e a atualização de display
• Os 128KB de SPRAM do Lattice UP5K cabem em 4 framebuffers de 320x200 com 4 bits, e cada bloco SPRAM de 32KB corresponde a um framebuffer nessa disposição de memória
• Os dados do jogo não estão incluídos no repositório; é preciso copiar BANK01~BANK0D e MEMLIST.BIN para a pasta GAMEDATA para poder usar o pacote de dados e o bitstream
• O modo de execução contempla tanto simulação quanto hardware real
  • A simulação pode rodar a intro com make simul1 após instalar o Silice
  • O hardware oferece suporte a icebreaker + VGA PMOD, mch2022 badge e ULX3S HDMI
  • Há bitstreams pré-compilados incluídos, mas os dados do jogo continuam sendo necessários à parte
• A execução da VM busca instruções e operandos na memória SPI e, para reduzir a latência, primeiro lê 64 bytes para um pequeno cache BRAM
• O caminho gráfico usa 4 framebuffers, double buffering, restrição de acesso durante o intervalo vblank e arbitragem de acesso ao framebuffer entre o blitter e o rasterizer
• O rasterizer desenha os polígonos convexos de Another World como spans horizontais e, para efeitos de transparência, pode ler e modificar o valor do pixel existente ou copiar pixels de outro framebuffer de origem
• A renderização de texto e alguns fundos da parte 6 são tratados armazenando no ROM buffers de pixels pré-renderizados devido ao orçamento restante de LUT, e copiando-os pelo caminho op_drawString
• As limitações e tarefas restantes declaradas incluem ausência de som e música, necessidade de bitstream e pacote de dados separados por parte, validação ainda incompleta do jogo inteiro, ajuste de timing mais rápido que o original e exploração da forma de conectar as partes
• A licença é: design em Silice sob MIT License, documentação sob CC BY-NC-SA 4.0, porta C++ modificada mantendo a GPL original, e os dados do jogo permanecem protegidos por direitos autorais

[GN⁺]

Opiniões no Hacker News

• Quando eu era criança e jogava Out of this World no Sega Genesis, achava que os gráficos não poderiam ficar melhores do que aquilo
  Foi a primeira vez que vi cutscenes totalmente animadas daquele tipo no Sega, e eram realmente incríveis. Claro que os gráficos melhoraram, mas sinto que Another World ainda se sustenta muito bem artisticamente. Ele tem um estilo marcante e, quando rejoguei cerca de um ano atrás, ainda me impressionou
  Boa parte dos puzzles é quase tentativa e erro, e o jogo também é extremamente curto, mas mesmo assim não há nada que eu gostaria de mudar. Se você é fã de Another World, também recomendo Flashback: The Quest for Identity. Ele tem uma atmosfera cinematográfica parecida e, embora eu não tenha gostado muito no começo, fui gostando cada vez mais ao longo da última década
  • Eu gosto muito de Flashback. O cenário cyberpunk combina com meu gosto, os fundos são lindos e a história é ótima
    Ainda assim, Another World é uma obra de arte. O pôster do jogo parece uma pintura a óleo e é realmente lindo [1]
    [1] http://www.anotherworld.fr/download/AnotherWorld_Poster.jpg
  • Eu gostava tanto de Flashback que tentei terminá-lo na dificuldade Expert, mas travei lá pelo fim e não consegui derrotar o slime man
  • A versão de Genesis saiu relativamente tarde. Joguei a versão de Amiga logo após o lançamento, em 1991, e fiquei completamente chocado; nunca tinha visto um jogo daquele tipo antes
  • Conheci Flashback primeiro no Sega e gostei dele de imediato. Quando joguei Out of this World depois, levei um tempo para me envolver, mas ambos são excelentes obras de arte
  • Flashback é uma obra da Delphine Software, e o jogo de detetive Cruise for a Corpse também usava parte da mesma tecnologia de polígonos
• Materiais relacionados que valem ver:
  Engenharia reversa e port para JavaScript de Infernal Runner, do cyxx, para Amstrad CPC. É uma obra do criador de Another World, e ambos usam uma arquitetura de máquina virtual: https://github.com/cyxx/infernal_js
  Apresentação The Virtual Machine Architecture of Infernal Runner, de Norbert Kehrer. A palestra é em alemão, com slides em inglês: https://media.ccc.de/v/vcfb20_-146-en-202010111400-_th...
  The Story of Another World on the Amiga | MVG: https://www.youtube.com/watch?v=0iz9PJbs5rE
  Port de Another World para Nintendo 64: https://github.com/jnmartin84/aw64
  Port de Another World para PlayStation 1: https://github.com/fgsfdsfgs/rawpsx
• Se HDL parece confuso, isto é uma linguagem customizada do autor: https://github.com/sylefeb/Silice/tree/master
  Ela fornece um compilador que compila para Verilog, e o resultado pode ser inserido no fluxo de projeto existente
• A introdução era fantástica. Mesmo tendo apenas o alto-falante do PC, sem placa de som
  Ter que nadar para fugir logo na primeira ação, e em seguida escapar de uma criatura parecida com um leão, é uma das experiências de jogo mais brutais de todos os tempos. Basta jogar esse jogo por 1 minuto para ele ficar na memória pelo resto da vida
  • Acho que joguei por mais de alguns minutos, no máximo algumas horas, e quase não avancei, mas aquela introdução e a primeira fuga continuam gravadas na minha memória até hoje
    Para os padrões da época, os efeitos dramáticos de câmera desse jogo realmente pareciam, como o título diz, outro mundo
  • Nunca joguei esse jogo pessoalmente, mas só uma cena de 2 minutos em uma fita VHS promocional que veio com uma revista de videogames ficou presa na minha cabeça por 30 anos
    A arte da capa também é excelente
  • Também nunca vou esquecer a “fala” dentro do jogo que aparece logo depois de o novo amigo salvar você daquela coisa parecida com um leão
    konanaka beetzai! motsuubo! /wave
  • Além da introdução, também era chocante que o jogo inteiro coubesse em um único disquete
  • Tenho exatamente a mesma lembrança de jogar por cerca de 1 minuto e ficar travado. Voltei 25 anos depois e zerei; se você superar a barreira do tempo de reação, é um jogo excelente e memorável
• O desenvolvedor original de Another World fez uma palestra retrospectiva na GDC, e ela é muito boa mesmo entre as palestras da GDC:
  https://www.youtube.com/watch?v=JFaOYYSxSEA
  Pelo que me lembro, ele também mostra algumas das ferramentas de desenvolvimento, incluindo uma forma de editar animações diretamente linha por linha no bytecode da máquina virtual e executá-las passo a passo
• Fico curioso para saber quão comuns eram as máquinas virtuais para jogos inteiros nos anos 90. É um jogo mais antigo do que eu; naquela época, uma camada de máquina virtual em PCs não causaria uma perda grande de desempenho?
  • Era muito mais importante fazer o mesmo software rodar em Amiga, x86 (DOS), Mac e em muitas outras máquinas
    Hoje há menos tipos de máquinas do que durante a explosão de crescimento dos anos 80. Mesmo hoje, dá para dizer que a maior parte do “software” é JavaScript interpretado pelo navegador. Nos anos 80 também havia o problema da portabilidade e, na verdade, era mais difícil, porque era preciso criar o próprio interpretador
    Muitos, talvez a maioria, dos videogames parecem ter sido escritos com máquinas virtuais antes de Doom ou dos gráficos 3D de alto desempenho. Jogos de console provavelmente eram em C ou assembly por causa do desempenho

Na época, os jogos de “computador” ainda eram de antes de o IBM PC virar padrão — ou, pelo menos, antes de o PC vencer e a Microsoft dominar. Numa situação em que não se sabia o que venceria entre Amiga, PC-98, IBM PC, Mac etc., fazia sentido criar uma máquina virtual, e SCUMM vem imediatamente à mente

• Ainda assim, não se fazia algo como Elite com uma máquina virtual de propósito específico dessas
  Portabilidade também era importante, mas, naquela época em que a Lei de Moore avançava a todo vapor e a vida útil das plataformas parecia a de uma efeméride, máquinas virtuais também tinham um efeito de compressão. Um binário totalmente compilado podia consumir espaço demais em disco ou fita e RAM demais
  Já uma máquina virtual bem pequena podia criar uma linguagem sob medida para interpretar na hora, reduzindo muito o espaço quando era preciso economizar cada quilobyte. Basta pensar na diferença de tamanho entre print "Hello world!" e um binário compilado básico. Não adiantava uma aventura em texto ser rápida se não coubesse em X KB
• No auge da linguagem assembly, máquinas virtuais também eram comuns em software corporativo. Era uma época em que compiladores C compatíveis com padrões e voltados a vários sistemas ainda não existiam ou eram muito caros, então isso facilitava portar para sistemas diferentes
• O truque de máquinas virtuais iniciais como a Z-Machine da Infocom, o código Pascal interpretado de Wizardry, SCUMM, AGI e SCI da Sierra, Another World, jogos da Horrorsoft etc. estava em entender bem que os jogos que estavam sendo feitos eram, em grande parte, “dispositivos de entrega de conteúdo”
  Havia muitos recursos de texto e gráficos, e a computação era relativamente simples. As restrições de autoria se conectavam ao hardware apenas em termos de entrada/saída e compressão de dados, e o código executado pelo interpretador geralmente era uma “inicialização de cena” executada uma única vez e alguns temporizadores de animação
  A ideia oposta aparece melhor em jogos de arcade e, depois, em coisas como Doom e Quake. O que o jogo simula é muito mais intimamente ligado ao hardware, e a definição de cena é algo como “coloque um monstro aqui e um item de vida ali”, ficando mais próxima de dados de mapa do que de lógica de script
• Depende de como se encara uma “máquina virtual do jogo inteiro”. Os jogos de aventura da Infocom rodavam todo o código do jogo na máquina virtual, e as aventuras gráficas da Sierra e da LucasArts também
  Claro que essas duas últimas usavam algumas primitivas gráficas nativas
• Parece que Only Amiga makes it possible foi substituído por FPGA 30 anos depois
• O trecho “[transparência] acrescenta complexidade ao rasterizador. Para inverter apenas um bit [do valor de cor], é preciso saber o valor anterior do pixel naquela posição” está mais para uma das três vantagens de usar gráficos planares, como no Amiga
  Com bitplanes, não é preciso reler a memória de vídeo. Basta assumir que o bit mais significativo é dedicado ao efeito de transparência e despejar o span como está
  As outras duas vantagens são poder mover os planos em relação uns aos outros para criar belos efeitos de moiré, e ter boa eficiência de memória e largura de banda do barramento em profundidades de cor meio esquisitas que não se encaixam exatamente em bytes ou nibbles, como 8 cores (3 bits por pixel) ou 32 cores (5 bits por pixel)
• Graças a esta thread, acabei admitindo que nunca vou terminar esse jogo por conta própria e vi um vídeo de gameplay no YouTube. Tinha 22 minutos. Acho que tudo o que eu tinha conseguido foi passar por um leão uma vez