Demorou mas finalmente terminei de digitar a segunda carta enviada pelo Tadeu Curinga da Silva sobre o Em Busca dos Tesouros, que veio junto com o caderno com o código fonte do jogo.
A carta é enorme: 25 páginas manuscritas. Tem inúmeras coisas que eu vou comentar mais detalhadamente no futuro, mas gostaria de já falar de algumas:
muriloq
Natal, setembro de 2006.
Caro Murilo,
Rapaz, você é um cara de sorte! Não é que o caderno original com o código fonte do jogo que eu tinhe lhe falado realmente conseguiu sobreviver ao longo de mais de duas décadas e incontáveis mudanças de endereço ? Conforme eu havia lhe dito no último e-mail, depois da prova eu iria pra Natal. Pois bem, já cheguei por aqui e já procurei em tudo quanto é canto da casa pra ver se ainda achava mais alguma coisa relacionada ao jogo (papéis, rascunhos, etc), mas infelizmente não achei mais nada não. Tudo (com exceção do caderno) se perdeu. Ele foi o único sobrevivente. Mas pelo menos podemos considerá-lo como o sobrevivente mais importante, já que é nele que estão os códigos que dão vida ao jogo.
E agora que eu sei que existe um clube com cerca de 160 pessoas que mantém viva a memória do nosso adorável, saudosista, romântico, pioneiro e inesquecível ZX-81, eu me sentirei bem mais tranqüilo saendo que o caderno estará em boas mãos; por isso estou entregando-o aos seus cuidados. Sei que ele estará bem mais seguro em suas mãos do que se estivesse aqui em Natal, correndo o risco de perder-se para sempre, coo aconteceu com a fita K-7 do jogo, o computador, os blocos de papéis milimetrados com os personagens e as telas do jogo, o gravador, etc. Tudo se perdeu com o passar do tempo. Além do mais, é uma ótima chance de mostrá-lo a todas as outras pessoas do clube e também a quem quiser ver.
Você tem a minha autorização para disponibilizá-lo no clube e também na internet, se desejar. Só lhe pediria duas coisas, levando em conta o enrome valor sentimental que esse cadernos representa para mim. Como eu já le falei antes, na primeira carta, esse caderno faz parte de um momento mágico da minha vida. Ele evoca sensa¿ões e sentimentos profundos, e de uma época em que a fantasia e a realidadede se misturavam de uma forma ímpar.
Por um lado, a realidade da falta de recursos, onde a aquisição de um "simples" computador como o TK-82C era motivo de muito sacrifício financeiro e euforia. Ouvi muitas vezes a frase: "Pra que você quer uma calculadora tão cara ?", tanto dentro quanto fora de casa. E era aí que entrava a fantasia, a mágica, o encanto. As pessoas não poderiam imaginar o que era sentar na frente de uma máquina como o magnífico ZX-81 e ser transportado a um outro mundo, um mundo dentro de uma tela de televisão, o nde o usuário é o rei e o seu reino está lá dentro da TV, um reino que pode ser construído, explorado, criado, modificado, vivido. Um reino de comandos, instruções, confusões, charadas, enigmas, diversões, enfim, um "reino encantado". O reino da fantasia.
Quando comecei a programar o EM BUSCA DOS TESOUROS e vi o reino encantadao da TERRA T. NEBROSA tomando forma pouco a pouco, a sensação foi indescritível. Para um adolescente de família pobre como eu, com escassos recursos e poucas opções, criar o EBdT foi como viver o ppel do Mickey Mouse no filme FANTASIA: um aprendiz de feiticeiro. As vassouras do filme eram os códigos assembly, difíceis de domar e sempre tentando fugir ao meu controle. E eu perdido no meio delas (ou deles), solitário, confuso, mas também fascinado. Quanto mais elas (eles) se multiplicavam, mais perdido, mais confuso e mais fascinado ficava. Uma mistura de erros e acertos, de tentativas, fracassos, sucessos, decepções, atropelos, descobertas, tudo com muito encanto, curiosidade, paixão e persistência. Se hoje eu tivesse somente 10% da paixão por programação que eu tinha naquela época eu me daria por satisfeito (quem sabe ela esteja apenas adormecida).
As duas coisas que eu falei que iria lhe pedir, por favor, com relação ao caderno são:
Com relação ao código fonte, do jogo, eu posso fazer alguns comentários simples no momento. Para uma análise mais profunda, eu teria de dispor de mais tempo atualmente. Já fiz o concurso que eu lhe falei, a prova foi no dia 17 desse mês, e o resultado sairá no dia 20 do próximo. O concurso era para exercer a Marinha, uma profissão que não tem nada a ver com computadores e programação, mas que é muito bem remunerada.
Como o jogo foi feito há mais de 20 anos, muita coisa sobre ele eu já me esqueci, afinal de contas 20 anos não são 20 dias. Mas como o passar do tempo, poderemos debater melhor os códigos, dependendo da disponibilidade do tempo de cada um (já tirei uma xérox do caderno para uma análise melhor futuramente). Também com a divulgação do caderno no clube TKCP / internet, várias pessoas poderão ter acesso aos códigos e poderão comentá-los / modificá-los. Poderão inclusive fazer novas telas para o jogo, ou talvez novos personagens (no caderno eu os chamo de CRIATURAS). Será divertido ver os "MODs" (as famosas MODIFICATIONS) que surgirão, e que são tão comuns nos jogos de PC.
Posso começar mencionando alguns tópicos que ainda me lembro mais ou menos.
Cada tela do jogo coupa 10 bytes para ser construída. O jogo possui 313 telas, logo são 3.130 bytes somente para a confecção das telas. Esses bytes ficaram arquivados na memória RAM numa área que começa a partir de um endereço designado por mim como ENDEREÇO DO 1o. BYTE DA LINHA DE DADOS DAS TELAS, e que eu apelidei de ELDT. Esse endereço é o 28.050 (ver página 80 do caderno, na 2a. linha) e corresponde ao 1o. byte da 1a. tela - a tela 001. Como cada tela requer 10 bytes para sua confecção, é só ir somando 10 bytes a esse endereço - o 28.050 - para obter-se o endereço do 1o. byte que forma cada tela seguinte. Ex: 28050 + 10 = 28060 = endereço do 1o. byte (de uma cadeia de 10) que forma a tela 002. E assim por diante. São 313 telas (sem contar a tela 000). Resolvi parar na 313a. tela porque na época esse número tinha um significado especial para mim, mas lembro que ainda dava para empurrar umas dezenas de telas no jogo, ainda havia memória para isso. Tanto é que a minha intenção inicial era fazer 333 telas, mas depois acabei mudando de idéia e parei na 313a.
Para determinar a última tela do jogo, é só usar o 5o. byte (da cadeia de 10 para cada tela) com o seu valor igual a 07 (0000 0111). Ver pág. 70 do caderno, 18a. linha. Dessa forma, pode-se determinar o fim do jogo (tela da caveira) no momento que se desejar, em qualquer tela que se queira, tendo apenas o cuidado para que o Kid K. Sador esteja na parte de cima da tela, e não na parte de baixo, quando ele for passar para a tela da caveira.
Existe uma variável chamada (LINHA DE DADOS DAS TELAS), entre parênteses, qu eestá sempre mudando ao longo do jogo e que serve para reservar (salvar) o endereço do 1o. byte da tela atual, i.e., a tela em que se está no jogo, e é arquivada nos endereços 18.936 e 18.937 (ou F8 49 e F9 49 em hexadecimal), que fica na pág. 79, na 7a. linha). O que essa variável faz é reservar (salvar) o endereço do 1o. byte (da cadeia de 10 que forma cada screen) da tela em que estamos no momento. Exemplo: se estivermos na tela 003, o CONTEÚDO dessa variável corresponderá ao endereço do 1o. byte da tela 003, que nada mais é do que ELDT+20, que é o mesmo que 28050+20, considerando: ELDT = 1o. byte da tela 001; ELDT+10 = 1o. byte da tela 002; ELDT+20 = 1o. byte da tela 003. Logo, no exemplo em questão, o CONTEÚDO da variável (LINHA DE DADOS DAS TELAS), entre parênteses, que está na pág. 79, linha 08, seria o endere¿o de número 28.070, i.e., 28050+20, correspondente à tela 003, que é a tela que estamos no momento (nesse exemplo). O número 28.070 em hexadecimal corresponde a A6 6D. Logo, no nosso exemplo, a variável (LINHA DE DADOS DAS TELAS), pág. 79, linha 7, reservaria esses números - A6 e 6D - correspondentes ao número 28.070, que por sua vez corresponde ao endere¿o do 1o byte da tela 003. Como ZX-81 não aceita "pokes" em hexadecimal, é só transformar aqueles números para decimal, i.e., A6= 1666 e 6D = 109. Portanto, se estivermos na tela 003, a variável (LINHA DE DADOS DAS TELAS) estará com os bytes 166 e 109, ou seja, o endereço de número 18.936, que corresponde ao 1o. byte dessa variável estará com o byte (ou número) 166 e o endereço seguinte, de número 18.937, que corresponde ao 2o. byte da mesma variável, estará com o byte (ou número) 109.
Portanto, sabendo onde fica o endereço do 1o. byte da tela 001, que eu denominei de ELDT - ENDEREÇO DO 1o. BYTE DA LINHA DE DADOS DAS TELAS (ver pág. 80 do caderno, 2a. linha, com explicações na pág. 142) e que corresponde ao endereço 28.050, você poderá criar sus próprias telas, sabendo que cada uma requer 10 bytes para sua confecção. Criar novas tela para o EBdT é mais simples do que tirar leite de gato, SE VOCÊ SOUBER O QUE CADA BYTE E CADA BIT FAZ. Eu tinha um bloco de papel milimetrado com tudo explicado, mas infelizmente ele se perdeu, não existe mais. Mas ao longo das páginas do caderno há vários comentários e explicações sobre o que cada byte e cada bit (da cadeia de 10 bytes usados para confeccionar cada tela) faz, de caordo com a sua posição dentro de um grupo de 10. Eu enumerei os bytes de cada grupo em ordem crescente; assim teremos: byte 1, byte 2, byte 3 (ou 1o. byte, 2o. byte, etc)... até chegar ao 10o. byte. Há também um resumo sobre as funções de cada byte e cada bit que formam as telas nas páginas.
Ao longo do caderno você verá várias vezes os termos TELA NORMAL e 2a. PÁGINA. Seria bom explicar a diferença entre eles. A razão deles existirem foi porque as primeiras tentativas de confecção das telas do jogo esbarraram num grande problema: elas não apareciam de forma instantânea na tela da TV quando eram geradas. Essas primeiras tentativas de impressão das telas foram feitas com os seguintes passos óbvios (mais óbvio do que isso, impossível):
PASSO 1) Apaga-se toda a tela atual, menos as duas últimas linhas. A ROM do ZX-81 divide a tela da TV em 24 linhas e 32 colunas, sedo que as duas últimas linhas, contando de cima pra baixo, não são acessíveis pela linguagem BASIC, somente pela ASSEMBLER. Dessas duas últimas linhas, uma eu usei para imprimir o chão da parte de baixo da tela, usando os caracteres gráficos [desenho], com metade de cima cinza e metade de baixo preta (correspondentes ao número 8A em hexadecimal), e a outra linha, logo abaixo dessa, eu usei para imprimir a pontuação do jogo, a tela em que se está e as vidas restantes. Por isso, não havia necessidade de apagar essas duas últimas linhas, já que elas fazem parte de todas as telas do jogo.
PASSO 2) Vai-se imprimindo a nova tela item por item, a medida que esses itens vão sendo testados para ver se eles fazem parte da nova tela (criaturas, lago, nuvens ou céu, paredes comuns, chão + buracos, etc).
PASSO 3) Imprime-se o Kid K. Sador em sua nova posição na tela atual.
PASSO 4) Incrementa-se ou Decrementa-se os números da última linha (embaixo), referentes à tela (unidades) e aos pontos (centenas).
PASSO 5) Sempre que se passasse de tela, todo o processo seria reiniciado, a partir do PASSO 1. Fácil, não ?
Na minha santa ingenuidade de programador iniciante eu pensava que esse "Método da Obvialidade" iria funcionar satisfatoriamente. Funcionar, até que funcionava, mas não satisfatoriamente. O problema central era a velocidade do processo todo de "TESTA SE TEM / CONSTRÓI / IMPRIME" cada item na tela atual. Apesar de os códigos Assembly serem bem velozes, como havia muita coisa envolvida nesse processo todo, a construção e impressão de cada nova tela não era instantânea, ou seja, dava para "ver" o processo em andamento. Claro que era bastante rápido, mas não era _INSTANTÂNEO_, dava para "perceber" a tela sendo construída, e ficava uma coisa feia de se ver, totalmente mal feita. Esse foi um dos muitos momentos em que eu pensei em desistir de tudo. "Esse computador não tem velocidade!", pensei. E agora ? A solução não veio fácil. Foram muitos dias quebrando a cabeça.
Até que depois de vários dias com o jogo parado, a solução me veio quando eu andava distraidamente na rua e parei numa loja de TVs com um monte delas na vitrine. Comecei a assistir um programa, e percebi que a TV ao lado, sintonizada num outro canal, continuava passando um filme, indiferente ao que eu estava vendo na TV à minha frente, ou seja, eu estava vendo uma tela e a outra tela continuava _em_andamento_. "Puta que pariu! É isso!" Gritei bem alto dentro da loja. Os vendedores se assustaram. Pedi desculpas e saí voado.
Quando cheguei em casa, mais calmo, comecei a refletir: quando for passar de uma tela para outra, é só ficar mostrando a tela atual _enquanto_que_ a nova tela está sendo confeccionada numa outra parte da memória RAM que não seja a própria tela atual que a gente está vendo. Aí, depois de tudo pronto, é só transferir o 1o. endereço onde começa essa nova tela (o do canto superior esquerdo, considerando a tela do ZX-81 com 32 colunas + 1 caractere NEW LINE vezes 24 linhas = 33 x 24 = 792 bytes!) para o par de registradores HL que contém o endereço da tela normal do ZX-81, que é 16.396 (canto superior esquerdo). Com isso, a ROM do ZX-81 iria pensar que aquele novo endereço era o da tela normal, logo tudo o que estivesse ali seria mostrado INSTANTANEAMENTE na tela, de uma só vez, sem morosidade.
Uma idéia totalmente absurda, surgida num lmpejo de insanidade mental. O que eu queria era enganar a ROM do ZX-81 dizendo a ela: "Ei, você aí! Agora eu nbão quero mais que você mostre a TELA NORMAL, que você já está acostumada a mostrar na tela da TV; agora eu quero que você mostre uma nova tela que eu criarei, a qual eu chamarei de "2a. PÁGINA", e que iniciará em um endereço de memória RAM que eu designarei para você". E assim foi. Tive que designar uma área da memória RAM com 792 bytes para ser a 2a. PÁGINA, i.e., o espaço onde iria ser construída a nova tela ANTES DE SER MOSTRADA.
Funciona assim: quando se chega na extremidade (direita ou esquerda) da tela atual e vai-se passar para uma nova tela, o programa continua mostrando a tela atual (com tudo parado, naturalmente) e passa a confeccionar a NOVA TELA na área da memória RAM que eu designei para ser a 2a. PÁGINA, sem mostrar o processo de confecção em andamento, visto que o que estamos vendo ainda é a antiga tela que fica paralizada momentaneamente na TV durante o tempo que durar o processo de confecção da 2a. PÁGINA.
Depois que toda a nova tela tiver sido construída na área da memória RAM designada como 2a. PÁGINA (sem que nós víssemos o processo de construção), aí sim, somente depois que a nova tela estiver pronta é que será feita a TRANSFERÊNCIA DE TELAS (ou de PÁGINAS) de uma para a outra, da forma como foi descrito anteriormente, i.e., transferindo o endereço do 1o. byte onde começa a 2a. PÁGINA (que corresponderá ao canto superior esquerdo) para o par de registradores HL que contém o endereço da TELA NORMAL do ZX-81, que é 16.396 (ver rotina chamada TRANSFERE PÁGINAS, pág. 88 do careno, linha 7). Qunado essa transferência é feita, TODOS os byes que estavam na 2a. página são mostrados INSTANTANEAMENTE na TV, simplesmente porque agora a ROM do ZX-81 pensa que a TELA NORMAL que ela estava acostumada a mostrar anteriormente é a 2a. PÁGINA!
Mas para que isso aconteça sem dar pane no sistema, é preciso primeiro confeccionar a 2a. PÁGINA de maneira que ela possa ser "mostrável" na tela da TV. Como eu já mencionei antes, a tela da TV para o ZX-81 compõe-se de 24 linhas com 32 colunas cada +1 caractere NEW LINE, que corresponde à 33a. coluna e que não aparece na tela; esse caractere NEW LINE serve apenas para indicar o fim da linha atual (sinceramente, não sei porque Sir Clive Sinclair resolveu colocr esse tal caractere NEW LINE nos fins das linhas das tels, já que ele não aparece na tela e, na minha opinião, não serve pra porra nenhuma, só para atrapalhar). Se tentarmos imprimir alguma coisa (algum caractere) nessa 33a. coluna, i.e., em cima do carctere NEW LINE, o sistema não aceitará e entrará em pane (lembrando que essa 33a. coluna não faz parte da linguagem BASIC, somente da ASSEMBLER). Portanto, será preciso confeccionar a 2a. PÁGINA de forma que ela possa ser mostrável na tela da TV.
O processo de confecção da 2a. PÁGINA econtra-se nas págs. 76 e 77 do caderno. Como são necessários 792 bytes, que correspondem a 24 linhas x (32 colunas + 1 caractere NEW LINE) para criar a 2a. PÁGINA, e como naquela época cada byte valia o seu peso em ouro, o grande problema era achar 792 bytes disponíveis (em meio aos 16K totais) para serem usados exclusivamente na confecção da 2a. PÁGINA. A solução foi reaproveitar os bytes anteriormente usados para a apresentação do jogo. Como a apresentação do jogo só é vista uma vez, depois que ela termina, os bytes usados na sua confecção não servem mais. Assim, eu designei como 2a. PÁGINA a área da memória RAM que começa no endereço 16.514, que é mesmo endereço onde inicia-se a apresentação do jogo (ver pág. 76, linha 9).
Pra finalizar, só mais um detalhe (um detalhe bastante óbvio, mas que eu só fui perceber depois de um bom tempo, e que foi um dos responsáveis pelo BFB - Big Fucking Bug): quando se transfere a 2a. PÁGINA para a TELA NORMAL, a TELA NORMAL passa a ser a 2a. PÁGINA, e a 2a. PÁGINA passa a ser a TELA NORMAL! Óbvio, não ? Só que para o ZX-81 não existe esse delírio de 2a. PÁGINA; para ele TODAS as telas são TELAS NORMAIS, logo se estivermos numa TELA NORMAL e passarmos para uma nova tela, essa nova tela será a 2a. PÁGINA somente durante o tempo em que estiver sendo CONSTRUÍDA (o tempo que o personagem "espera" nas extremidades da tela, com tudo congelado, antes de entrar na outra tela). Depois que a 2a. PÁGINA foi toda construída, faz-se a TRANSFERÊNCIA DE PÁGINAS, logo a antiga 2a. PÁGINA é agora a TELA NORMAL, e a antiga TELA NORMAL passará a ser a 2a. PÁGINA.
E quando passarmos para uma nova tela mais uma vez ? Tudo se inverterá. E assim por diante. Mas, como eu já disse, o grande problema é que o ZX-81 não sabe quem é a TELA NORMAL e quem é a 2a. PÁGINA (o que a rotina de TRANSFERÊNCIA DE PÁGINAS faz é apenas enganá-lo, ludibriá-lo e profaná-lo)! Para ele, TODAS as telas são TELAS NORMAIS! Logo, para solucionar o BUG que surgiu por causa disso (porque o ZX-81 sentiu-se enganado, ludibriado e profanado em seus mais íntimos recônditos, de forma que ele se vingou me mandando o Big Fucking Bug, que quase pôs tudo a perder), eu tive que criar duas variáveis, que eu denominei de VARIÁVEIS DE DUPLA PAGINAÇÃO, chamadas de UM e DOIS (ver pág. 79, em cima). O que essas variáveis fazem é reservar os endereços da TELA NORMAL e da 2a. PÁGINA para que o ZX-81 não confunda uma com a outra (ver pág. 76, em cima). E então, só então, foi que o ZX-81 conseguiu se acalmar e, conseqüentemente, O BFB se dissipou!
Na pág. 59, você verá a ROTINA DE IMPRESSÃO DAS NUVENS (ou CÉU), e logo abaixo desse título você verá entre parênteses (SÓ TEM TESTE COM 2a. PÁGINA). A outra rotina que só tem teste com 2a. PÁGINA é a ROTINA DE IMPRESSÃO DOS BURACOS/CHÃO, na pág. 72 (embaixo). A razão disso é óbvia: elas são rotinas que só precisam ser testadas e usdas uma única vez, para IMPRIMIR as NUVENS (ou CÉU) em cima e os BURACOS/CHÃO no meio da tela. Uma vez impressas, elas não mais precisam ficar sendo reimpressas novamente, basta uma vez. Sendo assim, elas só são chamadas quando a 2a. PÁGINA está sendo confeccionada (cada vez que se muda de tela). Da mesma forma, as rotinas de ROTAÇÃO DAS NUVENS/CÉU (pág. 58) e de ROTAÇÃO DOS BURACOS/CHÃO (pág. 50) só têm TESTE COM TELA NORMAL, porque elas servem apenas para rotacionar (para direita ou esquerda) as NUVENS/CÉU e os BURACOS/CHÃO que já foram impressos durante a confecção da 2a. PÁGINA. Por isso, elas só precisam ser testadas e usadas na TELA NORMAL.
Todas as outras rotinas do jogo precisam de dois testes: o TESTE COM 2a. PÁGINA, que ocorre ANTES da nova tela ser mostrada, e que consiste na impressão iminical do que se deseja (paredes esmagadoras, ondas do lago, nuvens/céu, chão/buracos, criaturas, aranhas, tesouros, etc), e o TESTE COM TELA NORMAL, que ocorre DEPOIS que a nova tela foi impressa e depois que houve a TRANSFERÊNCIA DE TELAS, e que consiste na MOVIMENTAÇÃO propriamente dita do jogo. O TESTE COM 2a. PÁGINA ocorrerá, pois, somente uma vez em cada nova tela, no momento de sua confecção, enquanto o TESTE COM TELA NORMAL ocorrerá várias vezes, ininterruptamente, durante o tempo em que estivermos na TELA NORMAL.
As NUVENS/CÉU (pág. 59) usam as 5 primeiras linhas da tela para serem formadas. Como cada linha possui 32 colunas (a 33a. coluna, ou caractere NEW LINE, não conta), seriam necessários 5x32=160 caracteres (bytes) para cada NUVEM/CÉU. Como eu desenhei 32 tipos diferentes de nuvens/céu, teríamos 160x32 = 5.120 bytes somente para a confecção das nuvens/céu, ou seja, praticamente um terço de toda a memória disponível (16K) somente para imprimir a parte de cima das telas do jogo! Claro que essa quantidade "absurda" de bytes era totalmente impossível de ser usada, eu teria que pensar em alguma solução para esse problema.
Depois de cogitar algumas reduções na quantidade de nuvens/céu, de 32 para 16 ou 8, eu decidi que o melhor mesmo seria fracionar os bytes, transformando-os em bits e fazendo cada 2 bits = 1 caractere. Dessa forma, teria 1 byte == 4 caracteres (ver pág. 59). Agora, seriam 5 linhas x 8 bytes (32 caracteres) = 40 bytes para confeccionar cada nuvem/céu. Logo, 40 x 32 tipos diferentes de nuvens/céu = 1.280 bytes, um número mais aceitável.
Claro que, depois disso, eu tive que fazer algumas adaptações nos desenhos, porque agora eu só dispunha de 4 tipos de caracteres diferentes para serem usados. Para formar as nuvens/céu é só seguir o exemplo mostrado na pág. 59 do caderno, sabendo que cada uma requer 40 bytes para ser formada: 5 linhas x 8 bytes (32 caracteres). O byte da (cadeia de 10 que forma cada tela) responsável pela criação das nuvens/céu é o 5o. byte (pág. 59). O endereço onde iniciam-se os bytes que formam todos os 32 tios diferentes de nuvens é o 26.251 (ver pág. 59, penúltima linha).
Para formar o CHÃO do meio da tela (com ou sem os buracos), eu usei um método semelhante ao das nuvens / céu para fracionar os bytes e ganhar memória, sendo que, agora, o milagre da multiplicação dos bytes foi muito mais intenso: cada BIT eu considerei um caractere, logo 1 BYTE = 8 BITS = 8 CARACTERES. Como são 32 colunas, ou 32 caracteres, teremos agora 4 BYTES = 32 CARACTERES. Só que agora só existem duas opções de caracteres: TODO CHEIO [X] (cinza ou preto), correspondente ao BIT 1, ou TODO VAZIO: [_], correspondente ao BIT 0. O byte (da cadeia de 10 que forma cada tela) responsável pela criação do CHÃO+BURACOS é o 7o. byte (ver pág. 73). O BIT 7 desse byte é quem define a "cor" do chão, i.e., se ele será cinza (BIT 7=0) ou preto (BIT 7=1). Os outros BITS (de 0 a 6) é quem determinam 1 dos 127 tipos diferentes de CHÃO/BURACOS, sendo que, se forem iguais a zero (X000 0000), é porque na referida tela haverá o buraco se abrindo.
Como exemplo da confecção de um CHÃO com 3 buracos, menciono o seguinte (considerando as 32 colunas da tela do ZX-81):
Portanto, para confecionar o CHÃO acima (com 3 buracos), seriam necessários os bytes F8, 7F, 07 e 8F. Como são duas linhas para o chão do meio da tela, o que a rotina faz é repetir a 2a. linha do mesmo jeito da 1a. Os bytes que formam o CHÃO começam no end. 27.531.
O jogo possui ao todo 15 tipos de personagens (no caderno, eu os chamo de criaturas). Eles são confeccionados com os caracteres que estão nas págs. 89, 90 e 91. O byte $C8 (em hexadecimal) serve para indicar a mudança da criatura, i.e., significa que o próximo byte será o início da próxima criatura (ver pág. 28, linha 18). O byte $C9 indica o fim dos bytes que compõem a criatura, mas não muda de criatura, ele apenas indica que a sub-rotina deverá voltar para retornar ao endereço inicial da criatura em questão (ver pág. 32, linha 28), que será reservado nas variáveis A1, B1, C1 ou D1, dependendo se for a 1a., 2a., 3a. ou 4a. criatura (ver pág. 26).
Os dois primeiros bytes de cada criatura correspondem ao número de colunas (o primeiro) e ao número de linhas (o segundo) que a respectiva criatura usa para ser impressa. Elas são impressas da esquerda para a direita, e de baixo para cima. Futuramente farei uma análise melhor sobre como são impressas e movimentadas, tem algumas coisas que eu não me lembro no momento, precisaria estudar os códigos melhor. Existem também 15 tipos de movimentos para as criaturas (ver págs. 91 e 92). A rotina que imprime e movimenta as criaturas começa na pág. 26 e vai até a pág. 33. Para imprimir/movimentar as criaturas são usados os bytes 1, 2, 3, 9 e 10 da cadeia de 10 bytes usados para confeccionar cada tela. Ver explicações nas págs. 27 e 27 do caderno.
Como eu já mencionei, tem muita coisa sobre o jogo que eu não lembro mais, eu teria de fazer um estudo minucioso sobre cada rotina para poder lembrar de como funcionam em seus promenores, algumas delas irão requerer bastante paciência para serem entendidas, porque servem para várias coiss ao mesmo tempo, já que a economia de bytes era essencial naquela época, e eu tinha que aproveitar uma mesma rotina de programação e usá-la para diersas coisas (empurar 313 telas com um monte de personagens e cenários variados em apenas 16K foi um grande desafio).
É o caso da sub-rotina de TESTE MORTE, APAGAR E IMPREIME CARA, nas págs. 11, 12 e 13. É a meesma sub-rotina, porém serve para 3 coisas diferentes: TESTAR SE O CARA MORREU, APAGAR ou IMPRIMIR o KID K. SADOR. Da mesma forma, temos a sub-rotina das págs. 17 e 18 , que também é uma só , mas serve para 3 coisas diferentes: TESTAR TESOUROS (ara ver se eles foram pegos), APAGAR CARACTERES e IMPRIMIR CARACTERES (das criaturas, jacarés, aranhas, peixes carapeba, caveira, etc).
Olhando para trás, para os códigos do jogo, eu percebo como o tempo voa. Lembro-me das suas palavras, quando você disse que era uma época mais romântica, podíamos nos dar ao luxo de fazer programas inteiros sozinhos. Concordo plenamente. Era uma época mágica. Eu tinha que desmembrar os BYTES em BITS para pdoer ganhar memória, usava unidades contadas nos dedos e frações dessas unidades. Hoe em dia se usam milhões e bilhões delas (MEGAS E GIGAS). Atualmente 16K mal dá para escrever um e-mail e talvez não sejam suficientes para formar uma gota de suor no rosto de um personagem do jogo TABLE TENNIS, da ROCKSTAR, lançado para o XBOX 360. Vivemos numa época em que para se fazer um jogo de ponta são necessários centenas de pessoas e dezenas de milhões de dólares.
Mas como já dizia Cazuza: "O tempo não pára". A vida vida continua. Sou completamente a favor da evolução, e na minha opinião os videogames estão apenas começando. Ainda estamos jogando de fora para dentro, e acho que a verdadeira revolução acontecerá quando começarmos a jogar de dentro para fora, quando realmente conseguirmos "entrar"no jogo, com cpaactes e sensores que nos levarão a mundos virtuais incríveis. Mas isso ainda vai demorar um bocado.
Recebi o seu e-mail com a apresentação do Professor Ricardo Bittencourt sobre a evolução dos videogames, e eu me senti honrado quando vi o meu jogo lá. Obrigado pela notícia, foi muito gratificante.
Aproveitando a ocasião, eu gostaria de lhe pedir um 3o. favor. Já lhe pedi 2 favores com relação ao caderno; agora eu gostaria de lhe pedir um 3o. favor, só que esse é com relação ao jogo: eu gostaria que você soltasse o PEIXE RASTEJANTE, que está preso na tela 089, embaixo, entre as duas paredes. Ele já está preso há mais de 20 anos, querendo sair, sem poder. Rasteja para um lado, esbarra na parede, aí rasteja para o outro lado, aí esbarra na outra parede, e assim por diante, tentando deseperadamente sair daquela prisão, sem poder. A razãp de eu tê-lo aprisionado ali foi devido a um sonho bastante estranho que eu tive quando estava fazendo o jogo. Na verdade, eu tive vários sonhos estranhos durante o processo de confecção do jogo, mas esse que eu vou contar agora foi um dos mais loucos.
Uma vez eu li uma entrevista com John Carmack (o criador de DOOM e QUAKE) na revista CGW - Computer Gaming World, na qual ele falou que quando estava programando DOOM, costumava sonhar com os personagens do jogo, muitos deles vinham para conversar com ele dar dicas de programação que solucionaram BUGs surgidos, al;em de dicas para tornar as fases do jogo mais interessantes... Loucura ? Talvez, mas eu sei que acontecia coisa parecida comigo quando eu estava programando o EBdT. Na época, não contava pra ninguém simplesmente porque ninguém ia acreditar mesmo... Mas acho que agora é um bom momento para contar esse sonho (nunca falei dele pra ninguém).
A questão foi o seguinte: quando eu desenhei o PEIXE RASTEJANTE, ele ainda não tinha esse nome escroto, e nem rastejava, a minha intenção era colocá-lo nadando nas telas que tinham lagos e mares do jogo. Quando o criei, o chamei de BOCÃO DESBRAVADOR DOS MARES BRAVIOS DA TERRA T. NEBROSA, um título bem nobre. E aí comecei a fazer algumas telas colocando-o para nadar pra lá e pra cá nos lagos e mares do jogo, até que depois de algumas semanas, eu resolvi desenhar um outro peixe, o CARAPEBA, para diversificar mais a quantidade de peixes que nadariam nos mares e lagos da TERRA T. NEBROSA. E assim foi. Comecei a fazer telas que tinham lagos com o BOCÃO DESBRAVADOR nadando e outras que tinham o CARAPEBA nadando, até que uma bela noite eu programei até tarde, estava muito cansado, deixei tudo desarrumado na mesa, blocos, cadernos, lápis, e fui dormir.
Aí tive o sonho: os dois peixes estavam brigando no meu quarto, quebrando tudo. "O que é isso ?", gritei assustado. O BOCÃO DESBRAVADOR respondeu: "Não quero que esse otário nade nos meus lagos e mares, pois eles já têm dono, e esse dono sou eu!". Pego totalmente de surpresa, perguntei: "Como assim, têm dono ? Do que você está falando ?". O BOCÃO gritou: "Já nadava nesses mares muito antes desse otário chegar, não admitirei um intruso em meus domínios!". E aí começou a atacar o CARAPEBA, que só se defendia, sem entender nada. "Páre com isso!", gritei. "Que negócio é esse de ser DONO dos mares, que loucura é essa ?". Aí corri e apartei a briga dos dois. Revoltado, falei pro BOCÃO: "Pois agora, só de sacanagem, vou lhe tirar dos mares, nunca mais você nadará neles!". O BOCÃO não acreditou no que estava ouvindo. "O quê ? Me tirar dos mares e lagos por causa desse otário ?", esbravejou.
Aí correu para o quarto onde eu programava e começou a devorar tudo que encontrava pela frente: caderno, papéis, rascunhos, lápis, tudo! E ao mesmo tempo gritava: "Pois agora não vai ter mais nem mares, nem jogo, nem nada! Tudo acabou, tudo!". Fui atrás dele presenciei a cena: tudo estava sendo picotado pelos dentes do BOCÃO, que devorava tudo num acesso de fúria! "Páre! Páre! Meu jogo! Socorro! Socorro!". Acordei gritando e suando frio. "Meu Deus! O que foi isso ?". Acendi as luzes e corri para o quarto de programação. Acredite se quiser, mas quando cheguei lá havia um bloco de papel milimetrado no chão (claro que ele caiu porque escorregou devido ao fato de tê-lo deixado muito na ponta da mesa). Mas por incrível que pareça ele havia caído aberto justamente na página que eu tinha desenhado os dois peixes, um ao lado do outro, e um de frente para o outro! "Meu Deus! Acho que estou ficando louco com esse jogo!", pensei. Por via das dúvidas, arranquei essa página do bloco, rasguei-a e joguei fora.
Como punição, resolvi rebaixar o título de BOCÃO DESBRAVADOR DOS MARES BRAVIOS DA TERRA T. NEBROSA. Falei pra ele: "Agora tu não mais nadarás nos mares do jogo! Isso é para aprenderes a não ser tão ciumento, arrogante e brigão! Agora ficarás rastejando pelas telas do jogo, e daqui pra frente eu te chamarei apenas de de PEIXE RASTEJANTE pois perdeste o direito de nadar nos lagos e mares da TERRA T. NEBROSA! E ainda vou te aprisionar para que nunca mais tu queiras iniciar uma briga com o CARAPEBA!". E assim foi. Desde esse dia, nunca mais o PEIXE RASTEJANTE nadou. E eu cumpri o prometido: criei uma prisão na tela 089 com duas paredes de tijolos e um chão por cima, com alguns buraquinhospara entrar um pouco de ar, projetada especialmente para aprisionar o dito cujo, aquele que apareceu no meu sonho e que causou toda aquela confusão. É ele mesmo - o do sonho - que está lá preso, não tenho dúvidas, é fácil reconhecê-lo: está sempre mal-humorado, tem um cacoete na boca e nunca pára de resmungar. Nunca admitiu ficar preso, está sempre tentando fugir pra lá e pra cá, sempre tentando achar uma saída. Nunca desiste.
Quando o vi pela última vez, eu estava jogando o jogo que tinha acabado de baixar do site BAÚ DE JOGOS com um emulador encontrado no GOOGLE. Quando cheguei na tela da prisão, a 089, parei um pouco e me lembrei do sonho que eu lhe contei. Olhei para o PEIXE RASTEJANTE lá preso, ainda tentando fugir, e senti um remorso intenso ao rever o coitado lá, aprisionado por tantos anos. "Como pude ser tão cruel ?", refleti, sentindo-me culpado por ter feito o que fiz. Por isso é que eu estou lhe pedindo o 3o. favor: que você solte o PEIXE RASTEJANTE da prisão da tela 089. Ele já está lá preso há mais de 20 anos, tentando fugir sem poder. Acho que já ficou preso por tempo suficiente, já basta de tanta punição. Agora que você já sabe como é que as telas são feitas, será fácil soltá-lo, basta retirá-lo de lá. Ficarei bastante aliviado, acho que só assim o sentimento de culpa se dissipará. Mas uma vez, obrigado.
Daqui a alguns dias eu retornarei ao Rio de Janeiro para reiniciar a maratona de estudos para o próximo concurso, no ano que vem. Chegando lá eu lhe darei notícias. A idéia de fazer um emulador para o PSP foi excelente. Acho que o EBdT na tela do PSP fica muito legal.
Mais algumas considerações sobre o jogo que eu gostaria de comentar: os bytes que compõem a apresentação do jogo já estão codificados nas págs. 163 a 171. Os que aparecem nas págs. 153 a 162 são só a versão TESTE da apresentação, e os que aparecem nas págs. 143 a 151 correspondem ao 1o. rascunho dela. Nas págs. 95 a 117 temos o 2o. rascunho da apresentação. Sinceramente, não lembro se esse é o rascunho final, ou se ele foi feito num outro caderno.
A partir da pág. 118 até a pág. 141 você verá vários RASCUNHOS de várias rotinas do jogo, que eram confeccionadas, testadas, e depois corrigidas, se necessário, até chegar-se à versão definitiva.
Os bytes que compõem as 313 telas do jogo, os 32 tipos diferentes de nuvens/céu e os 127 tipos de CHÃO+BURACOS não estão no caderno. Todos esses bytes estavam listados nos blocos de papéis milimetrados, com todos os desenhos correspondentes. Infelizmente os blocos se perderam.
Não lembro se 100% das rotinas do jogo estão nesse caderno, mas se não for 100%, é um número bem próximo disso, já que eu o considerava como a matriz do jogo, o caderno principal. Se faltr alguma coisa é muito pouco.
Se não fosse esse período bastante tumultuado de estudos que eu estou atravessando agora, até que eu cogitaria a possibilidade de fazer um EBdT II, como hobby, com mais telas mais personagens, mais tudo. Poderia até mesmo usar a expansão do ZX-81 de 48K e, quem sabe, aumentar o número de personagens de 15 para 64 ou mesmo 128! Aumentaria também o número de movimentos deles e também o número de telas do jogo. Daria uma nova chance ao PEIXE RASTEJANTE e permitiria que ele voltasse a nadar! Seria legal. Mas no momento a situação e o tempo não são favoráveis, quem sabe futuramente...
Acho que já tá na hora de encerrar esse jornal, senão vou continuar escrevendo sem parar e acabo não enviando mais o caderno. Sei que todos vocês do clube estão ansiosos por ele. Então tá, vou ficando por aqui; quando chegar no Rio eu te dou um alô. Há uma possibilidade, ainda que remota, de a gente se encontrar em BH, já que não é tão distante assim do Rio de Janeiro. Dependendo da situação, eu te comunico com antecedência. A gente poderia conversar melhor sobre o jogo ao vivo, aí em Belo Horizonte, e daria um pulo aí, rapidamente pra gente bater um papo, ia ser muito bom lhe conhecer pessoalmente. Mas isso é apenas uma possibilidade, não uma certeza. De qualquer forma, valeu por tudo. Um abração a você e a todos os mebros do clube e até o próximo contato.
Tadeu
Voltar para a página principal