Recomendação de leitura – Game Engine Black Book: Wolfenstein 3D

Jerzy Cha?upski Blocked Unblock Seguir Seguindo 9 de dezembro Não ande, corra e compre este livro!

Um dos livros mais interessantes e divertidos que li no ano passado foi o “Game Engine Black Book: Wolfenstein 3D” de Fabien Sanglard . Parte do meu prazer vem das vibrações nostálgicas que recebi enquanto lia este livro: meu primeiro PC era um 386SX e um disquete com a versão de shareware do Wolfenstein 3D estava frequentemente em uso. Alguns foi uma pura alegria de ler e examinar os detalhes de algumas listagens de código de montagem. De qualquer forma, eu me diverti lendo isso.

O livro começa com um pano de fundo sobre o hardware disponível no momento em que Wolfenstein 3D foi criado e destaca os desafios técnicos da criação de um jogo de tiro em primeira pessoa que seria executado nele. Há um pequeno capítulo sobre a equipe da id Software (se você estiver interessado neste tópico, eu recomendo outro grande livro, "Masters of Doom" ), e depois há a parte carnuda: mergulhar fundo no motor de Wolfenstein.

A pergunta que recebo quando conto às pessoas sobre esse livro é se obtenho alguma informação útil a partir dele. Enquanto eu estava lendo principalmente por diversão, isso me fez pensar. O que um desenvolvedor de software pode aprender em 2018 lendo o livro sobre um jogo desenvolvido no início dos anos 90? Aqui estão meus tópicos.

Representação de ponto flutuante

O livro oferece a explicação mais intuitiva de como funcionam os números de ponto flutuante que já li. O livro vale a pena ler apenas para este único take-away.

Otimizações de desempenho menores são importantes

Estamos vivendo em um mundo estranho.

Estamos cercados pelo hardware incrível e interagimos diariamente com software igualmente incrível que faz coisas quase mágicas. Mas, da mesma forma, nosso incrível hardware é invadido por softwares não tão incríveis e somos forçados a esperar pelo que parece uma eternidade para realizar a tarefa simples.

Este é um tópico interessante que merece um post inteiro por conta própria. Eu só farei dois pontos aqui: do ponto de vista de negócios, um desempenho ok e mais alguns recursos são geralmente preferíveis a um desempenho surpreendente com apenas recursos básicos; e os programadores iriam se esforçar mais para a otimização do desempenho se vissem grandes vitórias – reduzindo pela metade a pegada de memória ou fazendo algo funcionar numa ordem de grandeza mais rápida.

Isso significa que toda a otimização secundária é deixada desfeita. Mas esse tipo de otimização é o que possibilitou o Wolfenstein 3D! Provavelmente, houve um ou dois grandes truques que fizeram o pessoal da id Software achar que esse projeto pode ser feito, mas o restante estava reduzindo 10% aqui e 5% para obter o framerate decente.

Não subestime o poder de composição.

Metaprogramação

As placas gráficas VGA não tinham suporte de hardware para dimensionamento de texturas, portanto, elas precisavam ser feitas por software. Para um melhor desempenho, você não poderia fazer todos os cálculos na mosca. O que era necessário era o conjunto de simples rotinas de montagem "desenhe a n-ésima coluna de uma textura dimensionada para 40 pixels".

Eles não foram escritos à mão. Em vez disso, havia uma função que gerava todos os "escaladores" necessários no tempo de execução. Foi um exemplo de metaprogramação: um programa escrevendo outra parte de si mesmo.

No mundo do Android, temos alguns tipos de metaprogramação: processamento de anotações, reflexão, tecelagem de código e, recentemente, plugins de compilador do Kotlin. O problema com eles é que eles se sentem bastante alienígenas, têm limitações severas ou não interagem com código regular. Eles ajudam muito, mas eu gostaria que houvesse uma opção melhor, que fosse mais natural.

Transforme seus ativos para que eles estejam prontos para usar

Os sprites em Wolfenstein 3D – inimigos, loot, elementos do ambiente – não foram armazenados ou manipulados como bitmaps regulares. Para lidar com escalonamento e transparência, eles foram convertidos em pequenos meta-programas que modificaram os scalers de textura regulares.

Esse também é o formato no qual eles foram armazenados em disco nos arquivos de recursos do jogo! A conversão dos ativos reais entregues pelo artista para algo que o jogo poderia usar em tempo de execução foi feita como parte do processo de construção. É definitivamente uma técnica que pode ser útil agora ou até mesmo no futuro distante.

Não polir o código não crítico

Depois de ler o livro, dei uma olhada no código-fonte do Wolfenstein 3D e li o módulo gerenciador de memória. É feio e bastante frágil, pois depende de algumas suposições não documentadas e detalhes de implementação aparentemente não relacionados. Em resumo, é um tipo de código que não passaria na revisão de código.

Isso importa? Nem um pouco. É feio, mas faz o seu trabalho. É frágil, mas não havia risco de quebrá-lo porque não havia razão para mudá-lo. Ele se baseia em suposições não documentadas, mas se essas suposições fossem profundamente enraizadas em toda a base de código, elas nunca seriam alteradas.

Isso é algo que vou tentar ter em mente na próxima vez que eu tiver uma reação instintiva a alguns hacks feios.

Fizzlefade

Quando seu personagem morre em Wolfenstein 3D, a tela é gradualmente coberta com pixels vermelhos. Uma maneira de conseguir isso é alocar a lista de todas as possíveis coordenadas de tela e embaralhá-la, mas seria terrivelmente ineficiente e inviável para o hardware do início dos anos 90.

Os desenvolvedores do id Software descobriram outra maneira bem obscura de obter o mesmo efeito: uma técnica chamada Linear Feedback Shift Register . Isso permitiu que eles gerassem uma sequência de todas as coordenadas de pixel com apenas um monte de operações XOR e sem qualquer sobrecarga de memória. Verdadeiramente uma solução brilhante para um problema em mãos.

As partes ruins

O livro foi incrível, mas nem todos os unicórnios e arco-íris. O conteúdo é excelente, mas o layout do livro é, francamente, um pouco amadorístico. Também notei meia dúzia de erros de digitação e pequenos erros, o que amplifica essa impressão.

Eu também acho que o livro está faltando um tutorial rudimentar de assembler x86. Eu escrevi alguns programas x86 muito simples há algum tempo, então eu pude entender os trechos de código no livro, mas para alguém completamente não iniciado isso representaria um obstáculo desnecessário.

Mas espere, tem mais …

Esta manhã recebi uma notificação no Twitter de que o “Livro negro de motor de jogo: Doom” está disponível para compra . Eu não hesitei por um único momento e pedi uma cópia. Encorajo-vos a fazer o mesmo.

Texto original em inglês.