Este é um documento que escrevi em 1995, quando estava trabalhando no primeiro jogo do estúdio Neversoft: Skeleton Warriors. Este foi o primeiro jogo em que eu não usei a linguagem assembly de 68K.
Foto tirada o tempo todo. O kit de desenvolvimento ("Small Box" e ICE) está à minha direita.
Estado do jogo
O documento abaixo descreve brevemente o status do código dos Skeleton Warriors para a Sega Saturn e também menciona alguns dos muitos aspectos que ainda precisavam ser feitos.
O documento era necessário para acelerar a familiaridade de Dan, Ken e James com o código pronto, para explicar a eles o objetivo de cada módulo e a interação entre eles. Ele também me permitiu apreciar o triste estado desse código e, esperançosamente, me fez pensar.
Também falo um pouco sobre a incorporação de dados (arquivos .GOV e .GOB) no programa e sobre o que faremos no futuro.
Equipamento de desenvolvimento
Nossa plataforma de destino é a Sega Saturn, que possui dois microprocessadores SH2 Risc e um 68000. Enquanto usarmos apenas o processador principal Master SH2, o escravo auxiliar SH2 será usado quando descobrirmos como fazer isso. 68000 é usado para controlar o chip de som, não precisamos escrever código para ele, porque ele usará a biblioteca de sons fornecida pela Sega.
O programa é quase todo escrito em C. puro. Usamos o compilador GNU SH2 para obter o assembler de saída SH2. Existem vários módulos SH2 no código, que contêm principalmente dados exclusivamente. Até agora não escrevi nada significativo no SH2.
Como sistema de desenvolvimento, usamos o PsyQ. Este não é um sistema de desenvolvimento padrão da Sega, mas todos que trabalharam com ele consideram o melhor. Uma alternativa a ele é o SNASM, criado pela Cross Products, de propriedade da Sega. A maioria dos exemplos de código fornecidos pela Sega deve funcionar no sistema de desenvolvimento SNASM, mas pode ser facilmente convertido em PsyQ.
O sistema PsyQ consiste em uma placa de interface SCSI, instalada no PC, um cartucho que se conecta ao Saturn e conecta o cabo. As fontes são compiladas em um PC e baixadas para Saturn, onde o programa é iniciado. O código pode ser depurado do PC.
Sistema de Desenvolvimento PsyQA comunicação é controlada por um programa residente (PSYBIOS), que processa a comunicação entre máquinas. Isso permite que o console do Saturn baixe arquivos de um PC da mesma maneira que os baixaria de um CD. Usamos essa função para baixar arquivos de cada nível.
Tenho duas gavetas grandes e barulhentas no meu quarto e mais dois computadores. A menor das duas caixas é o E7000PC, que é um emulador SH2 embutido. Ajuda a descobrir onde o programa falha se o depurador PsyQ não o parar. Também é útil para rastrear gravações na memória, mas até agora quase não usei esse recurso.
A segunda das gavetas barulhentas é chamada de "Caixa Pequena" (a primeira "Caixa Grande" era do tamanho de uma geladeira pequena). Em essência, é Saturno com interfaces adicionais para o E7000 e o emulador de CD. No painel frontal, possui opções de identificação de país e uma opção entre PAL e NTSC.
Dentro do segundo computador, há um emulador de CD - uma placa grande, graças à qual o disco rígido do computador finge ser uma unidade de CD. Você pode coletar uma imagem de CD e emular em tempo real para ver como o jogo ficará quando chegar a um CD real. O emulador funciona mais ou menos, embora tenha alguns problemas nos quais estamos trabalhando junto com a Sega.
O próprio kit de desenvolvimento da SegaCompilando e vinculando
A montagem geral do programa concluído é controlada por um makefile: MAKEFILE.MAK. Ele contém dependências e destinos para todo o projeto, incluindo a compilação de arquivos .GOB e .GOV.
Módulos de código-fonte C individuais (arquivos .C) são compilados pelo CCSH nos módulos de objeto SH2 (.OBJ). Primeiro, chama o pré-processador GNU C chamado CPPSH (localizado em C: \ GNUSH2 \ BIN), depois chama CC1SH para criar o código do assembler SH2 e, finalmente, chama ASSH (em C: \ PSYQ) para construí-lo. no formato de objeto finalizado.
Não usamos C ++ porque me disseram que ele cria enormes arquivos de objetos. No entanto, eu não trabalhei com ele, você pode experimentar.
Vários arquivos na linguagem assembler do SH2 (com a extensão .S) são simplesmente coletados usando o ASMSH diretamente nos arquivos .OBJ (não é o mesmo que ASSH, mas um assembler de macros mais complexo). Atualmente, eles são usados apenas para incorporar dados e não contêm código dependente da máquina.
A RAM Saturn, na qual o código pode ser carregado, é dividida em dois blocos de 1 MB. Um começa em US $ 06.000.000 e o outro em US $ 002.000.000. O bloco de US $ 00.200.000 é usado exclusivamente para armazenar gráficos do personagem principal. O código do programa é gravado em US $ 06010000 (os primeiros US $ 10.000 bytes são usados para espaço do sistema, pilha e similares).
O código depende da posição e compilado para ser executado neste endereço específico ($ 06010000) e nada mais.
Os arquivos .OBJ são vinculados usando o programa PSYLINK para criar o arquivo MAIN.CPE, um programa executável com um cabeçalho pequeno que pode ser baixado no Saturn com o comando RUN. PSYLINK usa o arquivo TEST.LNK para indicar quais arquivos .OBJ incluir e onde colocá-los.
Dados
O jogo é dividido em vários níveis, muitos níveis usam os mesmos dados, mas basicamente são diferentes para cada nível. Todos os dados para cada nível são coletados em dois enormes arquivos .GOV e .GOB. (no caso de uma mina, são MINE.GOV e MINE.GOB). O arquivo GOV contém um cabeçalho curto e, em seguida, vem todos os dados que devem estar na memória de vídeo. O arquivo .GOB contém todos os dados que devem estar na RAM.
O nível consiste em uma parte dos arquivos de dados mostrados abaixo.
.SSQ - arquivo sequenciador de sprite
.SBM - arquivo de bitmap usado para fundos de bit
.MAP - ambos os mapas para fundos preenchidos por símbolos.
.TIL - tilesets e paletas para planos de fundo cheios de símbolos.
.PTH - dados de pontos e gatilhos da estrada.
.TEX - texturas para a estrada.
Os arquivos .SSQ e .SBM foram criados pelo meu sequenciador SEQ, cada vez mais desconfortável. Os arquivos .MAP, .TIL, .PTH e .TEX foram criados por Dan, um editor de mapas TULE cada vez mais incrível.
Esses arquivos são montados usando o assembler ASMSH nos arquivos .GOV e .GOB correspondentes. Para ver como isso é feito, consulte os arquivos LEVEL.S e LEVEL1.S Um arquivo .GOV também inclui alguns dos dados em um nível específico.
Módulos
TEST.S - nada de especial, define alguns rótulos.
MAIN.C é o nível superior do programa. Ele contém a inicialização do equipamento, configurações de nível, um código para a passagem de níveis e vários outros pequenos elementos que realmente devem ser colocados em módulos mais adequados. Há muito lixo nele, porque é mais fácil adicionar algo novo a este módulo para testes rápidos. Contém o código de inicialização de um CD ou servidor de arquivos em um PC. Contém um sinalizador para ativar ou desativar as barras de cores TIMING.
GFXLIB.C - vários procedimentos para acessar equipamentos e executar várias funções gráficas. Quase todos eles são escritos do zero por Dan e geralmente são muito ineficientes. Se você costuma usar o procedimento a partir daqui, seria bom dar uma olhada no que ele faz e escrever uma versão mais rápida no seu código.
No entanto, todas as funções funcionam e fornecem uma excelente estrutura para implementação e teste aproximados. Graças a Dan, não teria sido possível sem ele.
SMP_PAD.C - vários procedimentos para leitura do joystick Saturn, muito dependentes do equipamento.
GLOBALS.C - todas as variáveis globais e várias funções comuns. Usar variáveis globais é uma prática de programação aceitável. No entanto, por várias razões, a implementação de variáveis globais no SH2 é bastante lenta, portanto, com o tempo, provavelmente converterei a peça em estruturas globais, se necessário. Contém variáveis que descrevem o estado de
MAN e
PATH .
MAN.C - controla o movimento e a exibição de uma pessoa (Príncipe Lightstar, Talyn, Guardian ou Grimskull - o personagem controlado pelo jogador). Até agora, essa é principalmente a lógica do movimento e das colisões com a estrada. Além disso, fornece a animação apropriada para cada ação. Ainda há muito trabalho a fazer.
OB.C - controla o movimento e a exibição de objetos no jogo, especialmente objetos de inimigos, por exemplo, guerreiros esqueletos e pequenos alienígenas. A parte principal da jogabilidade é programada aqui: IA inimiga, movimentos básicos e disparo de gatilhos. A estrutura de dados ainda não está pronta; em particular, problemas com colisões e animações não são completamente resolvidos. Ainda há muito trabalho a fazer.
DATA.S - várias tabelas, atualmente principalmente animações dos personagens principais do jogador.
LAYER.C - rolagem de fundos com paralaxe. Atualiza os planos de fundo dos símbolos e os bitmaps de rolagem. Também rolando linhas (efeito de onda) na camada de neblina. Até o momento, as tabelas para as camadas do mapa de símbolos são armazenadas sem compactação. Eles precisam ser compactados para o formato RLE que eu usei para a versão Genesis. Essa tarefa pode ser enviada para Ken se obtivermos um sistema de desenvolvimento para Saturno mais cedo do que para a Sony.
PAL.C - paleta. Você pode escolher entre 2048 cores. Qualquer pixel na tela pode ser uma dessas cores. Eu logicamente dividi a paleta em oito paletas de 256 cores. O PAL.C contém código para sua inicialização, preparação e código para suas alterações cíclicas. Eles também precisarão de escurecimento e uma mudança cíclica mais complexa, além de flashes de brilho etc.
O BUL.C é um sistema primitivo para processar cartuchos (atirar uma espada, socar uma mão, foguetes lançados das mãos etc.) como objetos separados. Ainda é necessário muito trabalho para o uso mais complexo de conchas. Você também precisa do código de colisão e animação correto.
O PAD.C é um módulo simples para armazenar o estado do joystick em um formato mais conveniente. Memoriza se o botão foi recentemente pressionado e se agora está pressionado.
START.C - uma linha que informa qual nível será o primeiro, para facilitar a alteração no arquivo em lote.
PANEL.C - procedimentos simples para retirar uma faixa de força.
PATH.C - procedimentos monstruosos para desenhar a estrada, bem como lidar com colisões com a estrada.
MATH.C - seno simples, cosseno e rotação de um ponto por um ângulo.
[Update] Aqui está um código de exemplo do MAN.C. Tudo está rigidamente escrito no código e refere-se à estrutura de dados global Man. Um monte de números escritos no código.
Man_JumpTrigger() { if ( Man.JumpFudge ) { Man.JumpFudge--; } if ( Man.Mode != M_Crouch || Man_StandingRoom() )
O OB.C tornou-se um arquivo monstruoso de 9.000 linhas, que inclui todos os padrões de comportamento de objetos individuais no jogo. Também há um grande número de números escritos no código, por exemplo, como:
Drop_Arac(S_Ob *pOb) { int t; if (pOb->Jump==1) { pOb->yv.f+=0x7fff; pOb->y.f+=pOb->yv.f; t=Path_GetYZ(pOb->xi,pOb->yi,pOb)-15; if ((t>pOb->yi)&&(t<pOb->y.i+20)) { pOb->Jump=0; pOb->y.i+=15; Turn_Around(pOb); pOb->SeqFile=Sprites[SpriteMap[34]]; Object_TriggerSeq(Arac_JumpLand,pOb); } } else { if (pOb->Frame==16) pOb->Jump=1; if (pOb->AnimStat==AnimDone) { pOb->t1=0; pOb->Mode=&Pattern_Arac; } } Command_Arac(pOb); }
Uma visão desagradável. Esse estilo de código surgiu em uma época em que os jogos eram muito pequenos e eu o desenvolvi ao trabalhar com 68K.