terça-feira, 1 de dezembro de 2009

Leitura: Racing The Beam


Racing the Beam - The Atari Video Computer System
Nick Montfort and Ian Bogost
The MIT Press
ISBN-10:0-262-01257-X
ISBN-13:978-0-262-01257-7

A computação gráfica e a programação de jogos são excelentes escolas de programação. É necessário utilizar estruturas de dados complexas, sendo preciso estar sempre procurando um equilíbrio entre a complexidade das estruturas, do código necessário para percorrê-las e o espaço que utilizam. Além disso, há uma luta constante contra os limites do hardware.

Por isso, comecei a ler Racing The Beam com a expectativa de encontrar técnicas de programação, no mínimo, interessantes. O que eu achei foi deveras surpreendente. A minha expectativa inicial era a de encontrar alguma justificativa para a má-qualidade dos jogos do 2600 e acabei descobrindo que o aparelho é extremamente difícil de programar. Os criadores de jogos eram pessoas realmente dedicadas e habilidosas! A verdade é que ainda são, porque há quem escreva jogos para o 2600 ainda hoje.

No cerne do 2600 havia um processador 6507, que é um 6502 com apenas 13 linhas de endereçamento (contra as 16 originais). Com isso, o processador poderia endereçar apenas 8KB. No entanto, a interface dos cartuchos tinha ainda uma linha a menos; os jogos estavam limitados, portanto, a 4KB. Eu já começava a suspeitar que a programação seria difícil: onde seria possível guardar os bits da tela? Com 160x192 pixeis e 4 cores por linha (sendo possíveis 128 cores numa tela), seriam precisos quase 8KB para uma única tela de jogo. A tática comum de usar double-buffering (duas áreas de desenho) para evitar flickering (quando a animação pisca porque a atualização da tela não está sincronizada com a exibição) estava fora de questão desde o início. Os 1,19MHz do processador não eram uma restrição tão séria quanto a de que a máquina tinha apenas 128 bytes de RAM. E esses 128 bytes tinham que servir para as variáveis e a pilha.

A explicação para onde armazenar os gráficos está no título de livro: é preciso correr com o feixe da TV. Isto é, a cada linha, o programa deve interagir com o chip de geração de sinal de vídeo (TIA - Television Interface Adapter) para gerar os gráficos. Os gráficos simplesmente não eram armazenados em RAM, eles eram exibidos proceduralmente.

O programador tinha dois momentos para respirar: entre linhas e ao fim de uma tela. Ao desenhar uma linha, o feixe volta ao início e desce uma posição, para desenhar a próxima. E ao chegar ao fim da tela, o feixe volta para o início. O tempo que o feixe leva para voltar ao início da tela é o maior tempo que o programa tem disponível para processar as ações dos jogadores e calcular o próximo passo do jogo. Com uma velocidade de 1,19Mhz, o processador poderia, hipoteticamente, executar mais de um milhão de instruções. No entanto, a maior parte das instruções do 6507 precisa de mais de um ciclo. Muitas levam 2 ciclos e as mais complexas ocupam até 7 ciclos. As instruções ocupam de um byte até três. Apenas as mais simples, como INX (INcrement X register), ocupam apenas um byte e levam um ciclo para serem executadas. Para desenhar uma linha, havia apenas 76 ciclos do processador. Para processar as ações dos jogadores e calcular o próximo passo do jogo, 5320 ciclos. Dificilmente seria possível encaixar mais que 2000 instruções entre quadros. De qualquer forma, como o jogo estava limitado a 4KB, nem havia espaço para guardar mais instruções.

Um segundo chip, o PIA (Peripheral Interface Adapter) oferecia 3 funções: um temporizador programável, memória (os 128 bytes) e duas portas de I/O. O circuito, portanto, era muito simples. Não havia muito dentro de um 2600.

O hardware não é inteiramente malévolo e oferece uma facilidade: o programador pode usar sprites. São possíveis dois sprites de um pixel para mísseis, um sprite de um pixel para um tiro, dois sprites para jogadores e um sprite para a área de jogo. Em realidade, parece que o hardware foi desenhado para um tipo bem específico de jogo. E a verdade é justamente essa: ao projetar o hardware, um conjunto bem específico de características de jogos foi considerada. As escolhas de projeto foram influenciadas pelo jogo Pong, que existiu primeiro em bares e mais tarde foi lançado pela Atari como um jogo doméstico, para conectar na TV. O sucesso dele foi tão grande, que a Atari projetou o 2600 como a máquina mais barata possível que pudesse executar jogos do tipo Pong. O resultado, no entanto, permitiu uma gama interessante de jogos.

O livro analisa alguns jogos considerados importantes por motivos técnicos: Combat, Adventure, Pac-Man, Yar's Revenge, Pitfall! e Starwars (The Empire Strikes Back). Além disso, os autores preocuparam-se em analisar o ecosistema da plataforma e como os programadores foram compelidos a testar os limites do hardware, quando máquinas mais potentes começaram a aparecer. Surgiram maneiras de colocar mais código dentro dos cartuchos, por exemplo. Usando paginação, alguns cartuchos alcançaram 16KB.

Hoje em dia, já temos computadores que podem executar bilhões de instruções entre quadros e placas de vídeo ainda mais poderosas, porque executam muitas instruções em paralelo. O hardware já não é penoso para os programadores e o jogos são desenvolvidos em equipes. Tornou-se caro e trabalhoso porque a exigência dos compradores é muito maior. Para o 2600, os jogos eram escritos por um ou dois programadores extremamente hábeis. Era preciso conhecer o hardware intimamente e ser criativo o suficiente para escrever um jogo interessante sobre pouquíssimos recursos. Por isso, recomendo este livro para quem aprecia não apenas a história dos jogos, mas também a verdadeira habilildade em programação.

Nenhum comentário:

Postar um comentário