Vamos compilar como se fosse 1992 (2014)

 (fabiensanglard.net)
3 pontos por GN⁺ 2024-02-27 | 1 comentários | Compartilhar no WhatsApp
  • O código-fonte original de Wolfenstein 3D de 1992 não se encaixa diretamente em sistemas modernos, mas pode ser compilado novamente ao recriar o ambiente com DosBox e Borland C++ 3.1
  • Os componentes necessários se resumem ao código-fonte de Wolfenstein 3D, DosBox, Borland C++ 3.1 e os assets shareware para execução
  • No processo de build, além das configurações do projeto no Borland C++, é preciso corrigir manualmente PATH e os caminhos de SIGNON.OBJ e GAMEPAL.OBJ
  • O motivo de os gráficos aparecerem corrompidos na primeira execução é que o índice gráfico compilado no engine não corresponde às posições internas dos arquivos de assets
  • Ao copiar os assets VGA regenerados e ativar a aspect correction do DosBox, é possível executar o jogo com uma aparência próxima da proporção de tela CRT de 1992

Recriando o ambiente de build de 1992

  • O código-fonte original de Wolfenstein 3D de 1992 é difícil de usar diretamente em sistemas modernos, mais de 20 anos depois, mas pode ser compilado se você alinhar as ferramentas e o ambiente de execução da época
  • São necessários os quatro componentes a seguir
    • código-fonte de Wolfenstein 3D
    • DosBox
    • Borland C++ 3.1
    • assets shareware de Wolfenstein 3D

Preparando diretórios para usar como unidades DOS

  • Crie localmente 2 diretórios para usar como unidades DOS
    • system/c
    • system/a
  • Em system/a, baixe o arquivo compactado do Borland C++ 3.1
  • Em system/c, baixe o código-fonte de Wolfenstein 3D e os arquivos VGA
  • Após descompactar, a disposição dos arquivos fica assim
    • system/a: BCPP31.zip
    • system/c: wolfsrc.zip, vgafiles.zip

Instalando o compilador e o código-fonte no DosBox

  • Execute o DosBox e monte as pastas locais como unidades DOS
    • monte ~/system/c como C:
    • monte ~/system/a como A:
  • Em A:\BCPP31, execute install para instalar o Borland C++ 3.1
    • mantenha as configurações padrão e inicie a instalação
    • o aviso de que não foi possível encontrar a pasta do Microsoft Windows não é necessário; pressione Enter para continuar
  • Em C:\, execute o instalador do código-fonte de Wolfenstein 3D e use o caminho padrão \WOLFSRC

Fazendo o build do projeto no Borland C++

  • Execute o Borland C++ 3.1 em C:\BORLANDC\BIN\BC.EXE
  • Abra o projeto ..\..\WOLFSRC\WOLF3D.PRJ e configure os diretórios da seguinte forma
    • Include Directories: C:\BORLANDC\INCLUDE
    • Library Directories: C:\BORLANDC\LIB
    • Output Directories: OBJ
    • Source Directories: C:\WOLFSRC
  • No primeiro build, ocorre o erro Cannot find executable TASM
    • feche o Borland C++ e defina PATH=C:\BORLANDC\BIN, depois execute-o novamente
  • No build seguinte, ocorre o erro Unable to find OBJ file na etapa de linkedição
    • SIGNON.OBJ e GAMEPAL.OBJ estão apontando incorretamente para o caminho C:\SOURCE\WOLF\ no projeto
    • remova os dois itens do projeto e adicione-os novamente como WOLFSRC\OBJ\SIGNON.OBJ e WOLFSRC\OBJ\GAMEPAL.OBJ
  • Depois disso, execute Compile -> Build All e o build será concluído com sucesso

Assets de execução e a causa dos gráficos corrompidos

  • Para executar o binário compilado, são necessários os assets shareware ou da versão completa de Wolfenstein 3D
  • Após instalar a versão shareware, se você copiar o .EXE compilado para a pasta do jogo e executá-lo, a tela será exibida de forma incorreta
  • A causa está no pipeline de produção que gera os arquivos gráficos e na forma como o engine acessa os assets
    • Adrian Carmack e Kevin Cloud criavam os arquivos gráficos e depois os empacotavam com a ferramenta IGRABed
    • a saída é composta por 3 arquivos, VGAHEAD.WL1, VGAGRAPH.WL1, VGADICT.WL1, e 2 arquivos, GRE.H, GRE.EQU
  • VGAHEAD.WL1 é um índice que aponta para as posições dos dados dentro de VGAGRAPH.WL1
    • em VGAGRAPH.WL1 ficam armazenados os dados comprimidos com Huffman
    • em VGADICT.WL1 está o dicionário Huffman usado para descompressão
  • GRE.H e GRE.EQU são arquivos que permitem ao engine acessar os assets por nome
    • por exemplo, um nome lógico como L_GUYPIC é associado ao valor real do índice
    • o engine é compilado com os índices de imagem hardcoded
  • Depois do lançamento shareware de Wolfenstein 3D, os assets e a base de código evoluíram junto com Spear of Destiny, fazendo com que os índices do jogo recém-compilado não coincidam com as posições dos arquivos de assets existentes

Trocando os assets VGA e corrigindo a proporção de tela

  • A solução é copiar para a pasta do jogo os assets VGA regenerados, compatíveis com os índices .H e .EQU incluídos no código-fonte
  • Ao usar os assets shareware, é preciso copiar os arquivos trocando a extensão de .WL6 para .WL1
    • VGADICT.WL6 → VGADICT.WL1
    • VGAGRAPH.WL6 → VGAGRAPH.WL1
    • VGAHEAD.WL6 → VGAHEAD.WL1
  • Depois da substituição, execute WOLF3D.EXE novamente e o jogo funcionará normalmente
  • A tela padrão do DosBox é diferente da tela original que as pessoas viam em 1992
    • o framebuffer VGA é 320x200
    • monitores CRT tinham proporção 4:3, então a imagem aparecia esticada verticalmente na saída
  • Nas configurações do DosBox, troque aspect=false por aspect=true em [render] para aplicar a correção de proporção
  • Com a correção de proporção aplicada, Wolfenstein 3D roda com uma aparência próxima à forma como era exibido em CRTs da época

Leituras relacionadas

1 comentários

 
GN⁺ 2024-02-27
Opiniões no Hacker News

  • Recomendo muito o livro sobre Wolfenstein 3D mencionado no fim do texto. Mesmo sendo técnico, não é rígido nem entediante, e traz muitas otimizações à moda antiga, como 64 funções desenroladas para escalonamento de texturas de parede, a forma de armazenar sprites “de lado”, lidar com placas de vídeo esquisitas e hackear modos gráficos para que, antes de tudo, aquilo parecesse um jogo

    • Valeu pela recomendação. Acabei de baixar o PDF de 431 páginas sobre o motor do jogo, e ele ainda inclui um prefácio do John Carmack
    • É este livro? https://fabiensanglard.net/Game_Engine_Black_Book/index.php
      Parece que ainda não saiu; é isso mesmo?
    • Concordo totalmente. Eu nem sabia que esses livros existiam, mas li tanto o de Wolfenstein 3D quanto o de Doom e achei os dois muito divertidos. É uma pena que ele não vá escrever o livro sobre Quake/i586
    • A continuação, o livro sobre Doom, também é uma ótima leitura

  • O bom dos sistemas retrô é que, se você juntar as ferramentas, dá para compilá-los de novo. Recentemente recompilei por diversão o velho jogo Uplink, e tudo de que precisei foi o Visual Studio 6.0; o arquivo de desenvolvimento continha todas as dependências necessárias para o build
    Levei mais ou menos uma hora para acertar as dependências, mas no fim funcionou, e o jogo rodou bem. Corrigi até alguns pequenos defeitos e fiz pequenas melhorias aqui e ali. Imaginar fazer isso com software de hoje é uma loucura

    • Isso parece se aplicar mais aos casos em que o gerenciamento de pacotes do Linux é uma bagunça. No lado comercial de embarcados/Windows que vi, normalmente as dependências eram vendorizadas em uma pasta thirdparty/, e a toolchain usada também ficava fixa, então a configuração era sempre reproduzível
    • Hoje em dia, boa parte do que é necessário é simplesmente instalar a versão certa do Unity ou do Unreal. Para a era pré-Unity, isso certamente é verdade
    • Eu não sabia que o código-fonte de Uplink estava disponível. Jogo excelente

  • Aprendi a programar com Borland Turbo C++. Uma das coisas de que sinto falta daquela época é que dava para fazer coisas aparentemente complexas com muita facilidade. Bastava chamar funções de formas geométricas para desenhar na tela e, depois de desenhar uma forma, chamar a função xor em uma forma um pouco diferente para criar animações
    Com amigos, fiz um jogo parecido com Final Fantasy usando essas técnicas, com sprites feitos à mão, mapas por tela, um mundo em que ao chegar na borda você passava para o mapa adjacente e um sistema em que, se saísse o número natural 1 a cada passo, você entrava em combate. Era trabalhoso, mas para estudantes do ensino médio era realmente divertido, e o grande ponto era que, em vez de ter que aprender SFML, ActiveX ou OpenGL logo de início como hoje, bastava chamar circle

    • Se você procurar um ambiente em que crianças possam programar formas simples, acho que ainda deve existir algo assim hoje. A diferença é que as “ferramentas profissionais” e as “ferramentas para crianças/iniciantes” se separaram muito mais, enquanto o Turbo C++, ou o Turbo Pascal da minha época, ficava perto dos dois mundos
    • Tenho um pouco de inveja de quem, quando criança, teve acesso ao Borland Turbo C++ e a materiais de estudo. Para mim, tudo se resumia a ler resenhas em revistas locais de informática e, mesmo que eu tivesse conseguido uma cópia, não saberia o que fazer sem material para ler. Com meu inglês da época, nem sei quanto eu teria entendido mesmo com material disponível
    • A computação gráfica 2D moderna não funciona desenhando pixels em um framebuffer; texturas ou surfaces são os elementos básicos do sistema, e a composição é tratada em uma etapa separada. Por isso, criar um “sprite simples” ficou até mais fácil, e dá para pensar em uma surface composta como uma forma mais geral de sprite de hardware
    • Isso me lembra os bons e velhos conio.h e o BGI graphics.h da Borland. Hoje o SDL cumpre um pouco esse papel, mas não é tão simples
    • O Borland Turbo C++ ainda é, disparado, meu IDE favorito de todos os tempos

  • Depois de ver o livro ser mencionado várias vezes aqui ao longo dos anos, finalmente li Masters of Doom alguns meses atrás, e foi um livro excelente. Os jogos que eles faziam na época eram extremamente interessantes de jogar, mas, olhando para trás, o que inspira ainda mais é ver o que alguns jovens desenvolvedores com poucos recursos conseguiram criar

    • O Romero lançou recentemente o livro de memórias Doom Guy; fico curioso para saber se alguém já leu. Queria saber se é bom

  • Sinto muita falta das UIs baseadas em texto do DOS. Lembro do confiável PS/2 que continuei usando até por volta de 1997

    • Dá pelo menos para usar o Midnight Commander no terminal

  • Instalar no drive C? Que luxo! Eu não tinha disco rígido, então ficava trocando disquetes entre os drives A e B, e o compilador vivia pedindo as partes trocadas. Mesmo assim, a gente se divertia. A garotada de hoje não acredita quando contamos essas histórias

    • Em 1992 eu tinha um disco rígido de 5,25 polegadas, double-height, de 8,9 MB, e também dois drives de disquete de 5,25 polegadas e 360 KB. Eu tinha inveja do Mac do meu amigo, com drive de disco de 720 KB e disco rígido de 30 MB, mas aquele sistema provavelmente custava umas 6 vezes mais que o meu PC
    • É 1992, não 1982

  • O Borland C++ era realmente excelente. Um IDE com compilador C++, biblioteca padrão e depurador cabia em cerca de 5 MB, além daquela paleta de cores aconchegante da Borland, com letras amarelas sobre fundo azul

    • Ele também vinha com um manual impresso que incluía um tutorial de C++. Foi com ele que aprendi C++ antigamente
    • O OWL também era bem bom
    • O Zortech era muito melhor

  • Os IDEs MS-DOS da Borland são lembranças deliciosas

    • Se você sente essa nostalgia, vale conferir o Free Pascal. É um clone open source de Pascal/Delphi e inclui um clone do editor azul do DOS Turbo Pascal, então dá para sentir a vibe que você quiser
      Usei em alguns dias do Advent of Code deste ano, mas a nostalgia passou rápido. Depois de se acostumar com ambientes modernos, as limitações do IDE e a verbosidade do Pascal não são “divertidas” para uso diário. Ainda assim, as lembranças são mesmo doces
    • O RHIDE, embora a última atualização tenha sido há 23 anos, provavelmente ainda tem o código-fonte por aí. O verdadeiro problema ao implementar esse tipo de GUI em modo terminal é que os terminais Unix/Linux ficaram presos a padrões de terminal que não oferecem todos os recursos dos programas em modo texto do MS-DOS
      Em especial, não conseguem reconhecer a tecla Alt sozinha, combinações Alt+letra nem Ctrl+Shift+setas esquerda/direita
    • Ainda guardo, no espaço da antiga estante, uma caixa com os manuais do Turbo C

  • Texto relacionado: Let’s compile like it’s 1992 (2014) - https://news.ycombinator.com/item?id=13750097 - fevereiro de 2017, 80 comentários

  • Tive problemas para abrir o arquivo. Em wolfsrc.zip, apareceu o erro End-of-central-directory signature not found, dizendo que talvez não fosse um arquivo zip ou que pudesse ser parte de um arquivo dividido em vários discos