Sony PlayStation
A história do PlayStation começou em 1988, quando a Nintendo e a Sony começaram a trabalhar juntas em um leitor de CD-ROM opcional para o console SNES. Sob os termos do contrato, a Sony conseguiu desenvolver de forma independente jogos para esta plataforma e manteve o controle do formato Super Disc - duas concessões incomuns da Nintendo.O projeto foi desenvolvido antes da exposição da CES '91, na qual a Sony anunciou uma colaboração no Play Station. No dia seguinte, na mesma exposição, a Nintendo, para surpresa da Sony, anunciou que havia firmado um acordo de parceria com a Philips (em termos muito mais favoráveis). A Sony, leal e humilhada publicamente, tentou apelar para o conselho de administração da Sega, que imediatamente rejeitou a idéia. Em uma entrevista com 2013, o CEO da SEGA, Tom Kalinske, lembrou a decisão do conselho.“Essa é uma ideia estúpida, a Sony não sabe como desenvolver equipamentos. Eles não sabem escrever software. Por que mexemos com eles? - Conselho de Administração da SEGA
E eles não estavam enganados, a Sony realmente tinha pouca experiência em trabalhar com jogos. Ela quase não demonstrou interesse neles, com exceção da iniciativa de uma pessoa - Ken Kutaragi. Desde o momento em que viu sua filha jogar no Nintendo Famicom, Ken convence a Sony de que precisa entrar nesse mercado. Apesar das recomendações dos vice-presidentes da Sony, ele até desenvolveu para a Nintendo o chip de áudio (SPC700) usado no SNES.A maioria dos executivos da Sony considerou isso uma aposta arriscada, mas Kutaragi encontrou apoio na pessoa do CEO da Sony, Norio Oga. Em junho de 1992, Ken foi autorizado a começar a criar um sistema de jogos a partir do zero. Para acalmar o conselho de administração, o "pai do PlayStation", como mais tarde o chamaram, foi transferido para a empresa controladora independente Sony Music, e ele começou a trabalhar no que acabaria se tornando o "PlayStation" (já sem um espaço no nome).Inicialmente, os desenvolvedores não podiam decidir se a arquitetura deveria se concentrar em gráficos 2D de sprite ou gráficos 3D de polígonos. No entanto, o sucesso do jogo Virtua Fighter lançado em outubro de 1993 pela Sega nas máquinas de arcade japonesas destruiu todas as dúvidas: o PSX seguirá o caminho 3D.O culminar do projeto ocorreu dois anos depois, quando a Sony Computer Entertainment foi criada em 3 de dezembro de 1994 e o console foi lançado no Japão. Ele obteve sucesso instantâneo e foi vendido no primeiro dia com uma circulação de 100 mil dispositivos, 2 milhões de dispositivos após seis meses e 102 milhões de dispositivos ao longo da vida.Sony PSX (PS1, PlayStation). Foto: WikipediaArquitetura
O coração da máquina é o processador MIPS RISC R3000A de 32 bits com uma frequência de 33,8688 MHz [3] em combinação com 2 MB de DRAM. Vale ressaltar que este chip também possui um decodificador de movimento (MDEC), que fornece reprodução de vídeo com uma resolução de 320x240 a uma frequência de 30 fps. Ao lado do MDEC, vemos o coprocessador Geometry Transform Engine (GTE), usado para executar operações matemáticas de ponto fixo rápidas em vetores e matrizes. O sistema como um todo não pode trabalhar com números de ponto flutuante.A GPU é uma "caixa preta" controlada pelo processador central usando "comandos". Possui 1 MB de VRAM, indisponível para a CPU. De muitas maneiras, seu trabalho se parece com o maravilhoso modo imediato OpenGL: ele desenha polígonos texturizados que podem ser "sombreados" usando cores de vértice. O pipeline gráfico é fixo e não pode ser programado. Não há buffer Z (buffer de profundidade).A unidade de processamento de som (SPU), como a GPU, é uma caixa preta. Ele pode processar 24 canais, possui 512 KB de SRAM para armazenar áudio (no formato ADPCM) e é capaz de misturar faixas de áudio de CD-ROM com seus canais de áudio. A abreviação SRAM não significa "RAM estática", mas "RAM de som".A decisão mais ousada dos engenheiros da Sony foi a escolha do suporte de dados. Eles escolheram não os cartuchos, mas um módulo de CD-ROM de velocidade dupla, que reduziu o custo dos jogos e aumentou significativamente o volume disponível (até 650 MB). As desvantagens são a baixa taxa de transferência (300 KB / s) e o tempo de instalação da cabeça monstruosamente grande (300 ms).Não há blitter no console. O modelo de programação da máquina era que os desenvolvedores não tocavam no ferro "vazio". No entanto, existe um controlador DMA para transmitir dados do CD / DRAM para VRAM / SRAM.Sistema de vídeo
Apesar do fato do sistema de vídeo suportar cores de 24 bits, poucos jogos o utilizaram (com exceção dos fundos do Heart Of Darkness [4] ). Na prática, pode-se dizer com boa consciência que a maioria dos jogos usava cores de 16 bits com uma máscara de 1 bit.Espaço de cores PSX com profundidade de 15 bits por pixelUm recurso impressionante do sistema de vídeo é a organização da VRAM, que é completamente dependente do desenvolvedor. A VRAM de 1 MB é considerada uma matriz de 1024 x 512 x 16 bits que pode ser usada livremente. A aplicação do buffer duplo ou triplo é realizada de maneira trivial, porque a área é simplesmente suficiente para reservar, desenhar e transferir para o sistema de saída. As texturas também estão em VRAM, ao lado dos buffers de quadro. Para gravar no buffer do quadro, são iniciados comandos da GPU para renderizar triângulos / quadrângulos texturizados.As texturas podem ter vários formatos. Existem duas fontes diretas de cores de 16 e 24 bits, bem como fontes baseadas em uma paleta chamada Tabela de pesquisa de cores (CLUT). CLUTs de 8 e 4 bits são suportados.Em termos de resolução, o console estava limitado aos padrões de televisão NTSC e PAL. Para os mercados dos EUA e do Japão, o desenvolvedor pode escolher uma resolução horizontal de 256, 320, 384, 512 ou 640 pixels. A resolução vertical era de 240 pixels (ao pular cada segunda linha de varredura) ou 480 pixels ao alternar. Ambos os modos verticais operavam a uma frequência de 60 Hz. A única diferença entre NTSC e PAL foi uma resolução vertical aumentada (256/512 em vez de 240/480) e uma taxa de atualização mais baixa (50 Hz).Modo NTSC (60Hz) PAL (50Hz) Nota
===================================================== ========
0 256 x 240 256 x 256 Não entrelaçado
1 320 x 240 320 x 256 Não entrelaçado
2 512 x 240 512 x 256 Não entrelaçado
3 640 x 240 640 x 256 Não entrelaçado
4 256 x 480 256 x 512 intercalados
5 320 x 480 320 x 512 intercalados
6 512 x 480 512 x 512 intercalados
7 640 x 480 640 x 512 intercalados
8 384 x 240 384 x 256 Não entrelaçado
9 384 x 480 384 x 512 intercalados
Preste atenção aos modos com uma resolução horizontal de 384 pixels (8 e 9), que, a julgar pelo ID, foram adicionados mais tarde.DOOM no PSX
DOOM foi portado para a PSX pela Williams Entertainment com suporte da id Software. Uma equipe de cinco pessoas levou um pouco menos de um ano [5] [6] para portar o mecanismo, alterar recursos e modificar o jogo para que tudo funcionasse “apenas” em 3,5 MB de RAM.“Os gráficos foram degradados: as texturas são reduzidas em tamanho, sprites, monstros e armas também. [...] às vezes cortamos quadros de animação ". - Harry Tisley
O resultado final foi lançado em 16 de novembro de 1995. É considerada a melhor porta de console do jogo, e alguns aspectos até superam a versão para PC devido a tops coloridos e música com qualidade de CD."Até agora, esta é a melhor desgraça!" - John Romero
Plano de estudo
Devido à natureza do desenvolvimento, a estrutura DOOM é baseada em um kernel que usa seis subsistemas para E / S. Na maioria das vezes, estudei as três partes que achei mais interessantes, a saber, o sistema de arquivos baseado em CD-ROM, o áudio baseado em SPU e o vídeo baseado em GPU, porque são exclusivos da arquitetura PSX.O código fonte DOOM para o PSX nunca foi publicado, mas acabou não sendo problema. A informação disponível é suficiente.A primeira fonte é o incrível PSY-Q SDK, que era a ferramenta "oficial" usada pelos desenvolvedores de PSX da época. Há muita documentação, apresentada como um conjunto de arquivos PDF. Essa abundância de informações apenas confirma todo o bem que ouvi sobre a simpatia do PSX pelos desenvolvedores. A biblioteca (isto é, libcd, libds) desenvolvida pela Psygnosis também está bem documentada. Foi muito bom ver explicações claras, especialmente em comparação com a quase completa falta de informações sobre outros consoles (sim, estou falando do SNES).Outra fonte de informação são as muitas ferramentas externas disponíveis hoje. O ISOBuster me permitiu abrir o conteúdo do CD. PSound ajudou a verificar arquivos LCD. A impressionante capacidade do emulador no $ PSX de rastrear comandos de GPU e SPU tornou-se ouro real.Mas talvez eu tenha ficado mais impressionado com o enorme amor de DOOM pelo PSX da comunidade de fãs. Uma engenharia reversa completa do jogo foi realizada. O PSXDOOM-RE se destaca especialmente porque é uma base de código C que pode ser compilada usando o PSY-Q SDK em um jogo completo de PSX. O código é altamente confiável porque foi obtido reescrevendo cada função do código de máquina em C.O incrível mundo dos CDs
Antes de começar a estudar a implementação do sistema de arquivos, fiz uma pequena excursão para entender melhor o maravilhoso mundo dos CDs.Por 20 anos, de 1980 a 2000, foram lançados vários volumes de especificações que revelam esse tópico. Juntos, eles são chamados de "Rainbow Books". O primeiro livro da série, "Red Book", contém especificações para um CD (CD). O "Livro Amarelo" é um complemento ao "Livro Vermelho", que adiciona especificações de dados para CD-ROM e ISO-9600. O Orange Book adicionou especificações para CD-DA, CD-R (gravável) e CR-WR (regravável). O Livro Branco é dedicado ao CD de vídeo (VCD). O Livro Verde fala sobre CD-Interactive (CD-I). O Blue Book apresenta dados de CD avançado (ECD) para suporte multimídia. O Scarlet Book é dedicado ao Super Audio (SACD), que adiciona áudio de alta definição. O Purple Book lista a especificação de CD de densidade dupla (DDCD), que aumentou a capacidade do disco de 650 MB para 1,3 GB. Finalmente,O livro ciano detalha as especificações do sistema de arquivos 9660[7] .Rainbow Books contém tudo o que sabemos sobre o CD.Como um mínimo absoluto, precisamos entender que os CDs PSX geralmente consistem em setores, cada um deles contendo 2048 bytes de dados. Os setores são agrupados em faixas (que podem ser dados ou som). As faixas são agrupadas em sessão. As informações das trilhas de dados podem ser organizadas usando o sistema de arquivos ISO-9660 padrão; no entanto, o jogo também pode ter endereços de setor codificados.Dentro do CD do jogo DOOM
Se você olhar dentro do CD-ROM usando ISOBuster, poderá ver que o DOOM consiste em uma sessão contendo oito faixas [8] . Sete deles são trilhas sonoras com qualidade de CD reproduzidas entre missões e na cena final. A faixa final (# 7) ainda usa vozes demoníacas digitalizadas. A faixa número 6 é especialmente digna de nota porque parece ter sido tirada diretamente da festa rave. Acontece que esta é a música tocada no cartão super-secreto 59 “Club DOOM” (um cartão secreto acessível apenas a partir de um cartão secreto) [9] . Deixe-me deixar você apreciar a insanidade dela. Antes de começar, verifique o volume do som.A pista restante (número 1) é ISO-9660, que contém o mecanismo do jogo e a maioria dos recursos. Depois de explorar as muitas portas DOOM, eu esperava ingenuamente um mecanismo chamado DOOM.EXE, um arquivo de recurso PSXDOOM.WAD e, possivelmente, um manifesto. Eu estava muito enganado. Foram encontrados 287 arquivos [10] [11] na pista , incluindo 60 .WAD, 120 .IMG e inúmeros .LCD.Os dados são ordenados por nível (cinco arquivos por cartão).Nome do arquivo Descrição
===================================================== =====
Geometria padrão MAPDIR0 / MAP01.WAD (BSP / Reject / ...)
MAPDIR0 / MAPTEX01.IMG Texturas de planos / paredes
MAPDIR0 / MAPSPR01.IMG Todos os sprites criados por THINGS
Música reproduzível MUSIC / MUSLEV1.LCD
SNDMAPS1 / MAP01.LCD Todos os sons emitidos por THINGS
Quando perguntado por que tudo foi organizado de uma nova maneira, o desenvolvedor do Crash Bandicoot, Andy Gavin, respondeu parcialmente em uma entrevista à Ars Technica. [ tradução em Habré]"Leva cerca de 1/3 de segundo para mover a cabeça para qualquer ponto do CD."
Devido ao fato de a velocidade de posicionamento da cabeça estar próxima a 300 ms (o que é confirmado pela documentação do PSY-Q [12] ), os desenvolvedores da Williams Entertainment não puderam salvar a arquitetura clara do mecanismo DOOM, que armazenava todos os recursos em um arquivo (por exemplo, DOOM.WAD) e baixou-os a pedido. No PSX, isso levaria a uma taxa de quadros terrível.Os desenvolvedores resolveram o problema lançando uma quantidade aparentemente interminável de bytes no CD. Todos os recursos necessários para o nível foram armazenados em cinco arquivos contendo a geometria do mapa, textura. sprites, efeitos sonoros e música. Isso é muito caro, mas eliminou a necessidade de acessar o CD durante o processo do jogo.Fato interessante:na lista de arquivos na faixa de dados, existe um arquivo chamado PSXDOOM.WAD (4 806 088 bytes), mas é usado apenas para carregar paletas e várias imagens de menu. Provavelmente usado mais ativamente no processo de desenvolvimento.Tome o primeiro mapa como exemplo: a quantidade total de dados baixados foi reduzida de 4 MB para 900 KB.Tamanho do nome do arquivo (em bytes)
=======================================
MAPDIR0 / MAP01.WAD 28 196
MAPDIR0 / MAPTEX01.IMG 90 744
MAPDIR0 / MAPSPR01.IMG 590 344
MUSIC / MUSLEV1.LCD 61 232
SNDMAPS1 / MAP01.LCD 143 632
=======================================
Total: 914.148
Sabendo que os recursos ocupam 914 KB, você pode pensar que havia muita DRAM não utilizada restante. Mas você precisa se lembrar de que também era necessário ajustar um arquivo executável de 428 KB, além de uma pilha que muda no tempo de execução. De fato, apenas cerca de 1 MB de DRAM estava disponível em tempo de execução.Um fato interessante: ao examinar o código fonte do PSXDOOM-RE, descobri a função P_LoadBlocks, que tenta ler o CD até quatro vezes [13] , após o que ele se rende. Esse é um dos prazeres de trabalhar com mídias facilmente riscadas.Eu não esperava que o tempo de instalação do cabeçote do CD-ROM afetasse tanto a arquitetura do jogo. Alguns jogos, como o Crash Bandicoot, foram criados do zero com um sistema de páginas para transmitir dados de um CD em tempo de execução. No caso de DOOM, o mecanismo não era capaz disso. O CD não é usado durante o jogo, com exceção de uma música específica (sim, do nível Club DOOM).O pessoal da id Software nunca foi fã da troca entre capacidade e velocidade que os CD-ROMs ofereciam.« - . , CD. - , Crash 'n Burn — ? . , CD , 3DO . - CD- DOOM, „ DOOM“. , . .
, CD. ». — (ATARI EXPLORER ONLINE, 22 1994 )
Um fato interessante: eventos dentro do jogo DOOM foram acionados usando "estrias". Ao cruzar uma linha com uma propriedade especial, uma função especial era chamada. Na versão "herdada" do mecanismo, não havia nenhuma propriedade que permitisse a você tocar músicas. Para jogar no Club DOOM, uma ação especial de alinhamento foi criada (número 142) [14] . É incrível quanto esforço extra foi necessário para criar esse nível. Provavelmente, os desenvolvedores realmente gostaram de se divertir nas raves.O Caso do Archvile Desaparecido
Realizando pesquisas para o meu Game Engine Black Book, não consegui entender completamente essa frase do designer Harry Teesley:“O Archvile tinha o dobro de quadros de animação do que qualquer outro monstro, e não conseguimos colocá-lo no PSX. Nem seu ataque nem o efeito da ressurreição puderam ser perdidos. Ele era grande demais. " - Harry Tisley (designer) em entrevista ao doomworld.com
Era óbvio que o problema não era a capacidade de 650 megabytes do CD, mas eu não entendia qual era o fator limitante - DRAM ou VRAM.Tendo compreendido as limitações do CD-ROM, percebi que o problema não era armazenar o sprite em um CD ou mesmo transferi-lo da DRAM para a VRAM. O problema é encaixar tudo na DRAM.Fato interessante: o ArchVile é completamente removido do código fonte do PSXDOOM-RE. Até o seu # DEFINE é comentado [15] .#define CC_ZOMBIE "Zombieman"
#define CC_SHOTGUN "Shotgun Guy"
#define CC_HEAVY "Heavy Weapon Dude"
...
#define CC_HELL "Hell Knight"
#define CC_SPIDER "The Spider Mastermind"
#define CC_CYBER "The Cyberdemon"
#define CC_HERO "Our Hero"
Programação SPU
O chip SPU entende apenas um formato, ou seja, ADPCM. É capaz de misturar até 24 canais (incluindo a faixa de áudio do CD) e possui poderosas funções de manipulação de áudio.Para domar essa fera, o DOOM PSX usa a biblioteca libWESS (Williams Entertainment Sound System), escrita pelo engenheiro de som Scott Patterson. A biblioteca é bastante poderosa, é capaz de recriar o sistema MiDI, no qual um pesado banco de notas (chamado fonte de som) é controlado por uma partitura musical que ocupa pouco espaço. Também pode manipular atributos de som em tempo real, como volume, tom, velocidade da nota e funções ADSR (Attack, Decay, Sustain e Release). Todas as músicas tocadas durante o jogo são geradas usando o libWESS. Com uma exceção, você adivinhou, este é o Club DOOM, que é reproduzido a partir da faixa 6 do CD.O WESS usa dois formatos de arquivo proprietários. Esses são arquivos .WMD que contêm partituras e efeitos sonoros e arquivos .LCD, que são do formato PSX VAG (sem título) e contêm amostras do ADPCM. Quando o DOOM é iniciado, a biblioteca libWESS carrega todos os efeitos sonoros (SFX, 89 peças) e partituras musicais (19 peças) armazenados em um pequeno arquivo (55 KB) chamado DOOMSND.WMD. Ela também carrega nas amostras "sempre usadas" da SRAM publicadas pelo personagem, portas etc.MUSIC / DOOMSFX.LCD -> SRAM
MÚSICA / DOOMSND.WMD -> DRAM
Após carregar o mapa, o libWESS abre MUSIC / MUSLEV% .LCD, que contém as amostras ADPCM usadas na música deste cartão, e SNDMAPS% / MAP %%. LCD, que contém as amostras ADPCM necessárias para inimigos nesse nível. Todas as amostras do ADPCM são carregadas diretamente na SRAM e não ocupam espaço na DRAM.DOOM no PSX: GPU
Na área de geração de vídeo, a Williams Entertainment precisava resolver dois problemas: uma pequena quantidade de VRAM (voltaremos a isso mais tarde) e a falta de mapeamento de textura correto, levando em consideração a perspectiva.“Aaron Siler e eu trabalhamos em versões para o Nintendo 64 (este jogo era bem diferente) e para o Playstation. Essas foram as primeiras versões que não foram escritas no bare metal, porque a Sony e a Nintendo forçaram os desenvolvedores (pelo menos de terceiros) a escrever APIs e não forneceram documentação sobre os registros de hardware. A princípio, a cultura SGI limitou os desenvolvedores, mas gradualmente a Nintendo afrouxou seu controle.
Uma história engraçada sobre o desenvolvimento de uma versão para o Playstation: Aaron e eu começamos com uma arquitetura de mecanismo diferente, que representava triângulos mundiais, porque o console lhes proporcionava aceleração total do hardware. No caso do N64, isso funcionou perfeitamente, porque tinha renderização com perspectiva correta com precisão de subpixel (o resultado da influência do SGI), mas no Playstation o mapeamento de textura afim foi realizado com coordenadas inteiras, de modo que os grandes triângulos de parede e piso pareciam INCRÍVEIS. ” - John Carmack (Livro Negro do Game Engine: DOOM)
Para entender o quão “terrível” parecia, abaixo eu mostrei três paredes pintadas com texturas afins e prospectivamente corretas.Texturização em perspectivaAfim (PSX)Observe que não há problema com uma parede reta e, à medida que o ângulo de perspectiva aumenta, a distorção se torna mais perceptível.O mesmo problema de percepção enfrentou os desenvolvedores da Rage Software ao portar DOOM para a SEGA Saturn.« , id Software. , WAD Saturn, , 3D-. , , 3D- . , PC. , , : SH2 , PC, 68000 .
, » — ( DOOM Saturn) RetroGamer №134.
Talvez, como os desenvolvedores do PSX tivessem mais tempo, eles pudessem resolver o problema do mapeamento de textura prospectivamente correto, transformando o renderizador de polígono da GPU em renderizador de linha."Eu disse: faça backup de tudo (então ainda não havia sistemas de controle de versão!). Vamos tornar o jogo completamente diferente." Usamos equipamentos que renderizavam triângulos que representavam colunas ou linhas de um pixel de largura, exatamente como no código do montador em um PC, e funcionou muito bem. Descobriu-se que a solução mais comum no Playstation era mosaico de geometria em dois eixos, mas eu realmente gostei do Doom parecer menos "contorcido" do que a maioria dos jogos para o Playstation da época. "- John Carmack (Game Engine Black Book: DOOM)
Graças ao projeto PSXDOOM-RE [16], podemos descobrir como ele foi implementado. O pipeline de renderização foi completamente reescrito e dividido em dois estágios. Isso será discutido com mais detalhes abaixo, mas podemos ver que a função de renderização R_Render_Wall transmite comandos de desenho bem definidos com uma largura de 1 pixel.void R_Render_Wall(...) {
.
int x1 = ... ;
int x2 = ... ;
.
while(x1 < x2) {
.
setRGB0(wallpoly);
setXY3(wallpoly,
x1 , ypos1 - 1,
x1 + 1, ypos2 + 1,
x1 , ypos2 + 1);
setUV3(wallpoly,
upos, v0,
upos, v1,
upos, v1);
.
x1 += 1;
}
}
As paredes são renderizadas em colunas com um pixel de largura. Confira a API, que se assemelha ao modo Imediato no OpenGL.Fato interessante: o designer de hardware da Sony manteve o i-cache do processador MIPS, mas desativou seu d-cache para transformá-lo em um bloco de rascunho de alta velocidade de 1K. Os procedimentos de renderização de parede / plano usavam esse bloco de anotações extensivamente.Gerenciamento de GPU VRAM
Para aprender como o controle VRAM é realizado, escolhi uma maneira curiosa: usei a função de visualizar o emulador VRAM em tempo real, sem $ PSX. Esta função exibe toda a matriz de pixels 1024 x 512 x 16 bits (embora de forma distorcida). A função de exibição também mostra a lista inteira de instruções da GPU transmitidas pelo processador central em cada quadro.No $ PSX - Deus nos enviou um emulador que permite que você olhe dentro da GPU.Um estudo cuidadoso do primeiro quadro da VRAM permite que você aprenda muito.O primeiro quadro do jogo exibido com No $ PSX.As mais óbvias são duas áreas de 256 x 240 x 16 bits no canto superior esquerdo, que são os buffers de quadro (portanto, o jogo usa buffer duplo). Vale ressaltar que 256x240 é a menor resolução possível em um PSX.Sob os buffers de quadro, há um conjunto colorido de pixels - a paleta CLUT. Observe os tons de vermelho, eles significam que quando a tela fica vermelha quando o jogador sofre danos, paletas pré-calculadas são usadas.No canto superior direito, vemos texturas estranhamente compactadas horizontalmente e com cores "erradas". Isso aconteceu porque as texturas usam índices de 8 bits do CLUT descrito acima.Vamos falar sobre fogo no DOOM no PS1 novamente
Em 2018, estudei como o efeito do fogo foi realizado [17] [ tradução em Habré]. Foi ótimo voltar a ele novamente ao explorar os comandos da GPU. Observe que nenhum $ PSX marca a área de destino de cada comando em vermelho.Estágio 1: a chama é atualizada na RAM e carregada na VRAM (comando CpuToVram).Etapa 2: a textura da chama é desenhada quatro vezes ao longo da tela (comando QuadTex). A textura da chama tem uma largura de 32 texels, mas a GPU é usada para desenhá-la com uma largura de 64 pixels. A filtragem bilinear não é possível aqui, os texels mais próximos são amostrados.Etapa 3: a placa Final DOOM (comando QuadTex) é desenhada em cima de tudo.Quadro completo, equipe por equipe
Um estudo dos comandos transmitidos no quadro mostrou que o mecanismo é completamente diferente da versão para PC. Nele, o mundo circulava de uma curta distância para a distância. Primeiro, todas as paredes são renderizadas. Na segunda passagem, uma lacuna vertical é preenchida entre eles (visplane) (incluindo o céu). Na terceira (última) passagem, os sprites são renderizados, começando pelo mais distante. Tudo isso foi feito com zero pixels de redesenho.No PSX, a renderização é um pouco mais rude. Tudo é processado em uma única passagem, realizada a partir de longe. O sistema de visplane que o PC usou para preencher o vazio entre as paredes não está aqui. Graças a um novo conceito chamado "folhas", o avião e as paredes são renderizados na ordem dos subsetores. Tais operações em "3D verdadeiro" tornaram-se possíveis devido ao uso ativo das funções de projeção da matriz GPE. Os sprites também são renderizados simultaneamente com paredes / planos sem verificação de sobreposição e truncamento, o que resulta em uma pequena quantidade de redesenho.void R_RenderPlayerView(void) {
R_BSP();
R_RenderSKY();
for (all subsectors from phase 1) {
R_RenderAll(subsector)
}
R_Render_Hud_Weapons();
}
Vamos analisar cada etapa em detalhes, começando com o céu, que é renderizado pela primeira vez usando CopyRectRaw. no $ PSX mostra VRAM no momento em que o quadro é concluído, mas permite que você volte ao histórico de comandos. Os pixels do céu são visíveis apenas porque nenhum $ PSX tem problemas em perceber esse hack com colunas de largura de um pixel (outros emuladores, como o ePSXe, não conseguem lidar melhor [18] ), mas todos esses pixels serão reescritos. Observe que, sob as texturas do céu, todos os marcadores das chaves das portas estão reunidos em um atlas.Em seguida, o BSP é percorrido em ordem de longe para perto. Para cada subsetor, todas as paredes / planos / sprites são renderizadas. Se você conhece o DOOM BSP, provavelmente lembre-se de que o compilador doombsp mantinha apenas segmentos sólidos de subsetores. Para garantir a renderização dos planos, um novo conceito de "folhas" foi adicionado à versão PSX, na qual os segmentos de separação BPS (invisíveis) foram armazenados. Esses segmentos são projetados no espaço da tela para gerar limites do plano. Essa é uma abordagem muito mais "limpa", porque permite que você se livre de hacks com espaço na tela e bugs, por exemplo, da conhecida "trilha da lesma".Na próxima foto da VRAM, os aviões do mesmo subsetor da parede que vimos acima são renderizados como triângulos com 1 pixel de altura. Também preste atenção à textura das paredes / planos, todos eles têm o mesmo tamanho. Esse recurso simplifica a seleção de texturas VRAM e evita a fragmentação.Ainda estamos no mesmo subsetor. Agora, os sprites são renderizados como quadrângulos (Quad). Esses sprites incluem inimigos, conchas, paredes parcialmente transparentes.Por diversão, mostraremos conchas de plasma.Estamos chegando ao final dos comandos de renderização. Aqui, misturando o retângulo, a arma é renderizada.Última etapa: renderização da interface (HUD).Excesso de VRAM!
Trabalhar com a GPU foi um exercício para alocar espaço na VRAM. No caso de buffers de quadro, CLUT, conteúdo estático (interface) e até paredes / planos, a tarefa é elementar, porque todos têm o mesmo tamanho. Mas com sprites, as coisas são um pouco mais complicadas.Devido ao fato de os sprites terem tamanhos diferentes, eles levam à fragmentação. Além disso, as texturas podem cobrir grandes áreas da tela e repetir, e os sprites geralmente são únicos e um número imprevisivelmente grande pode ser necessário em cada quadro. Na pior das hipóteses, um quadro requer um certo número de sprites que não podem ser colocados na VRAM. Isso é chamado de estouro de cache de textura e esse problema não pode ser resolvido. Quando isso acontece, o jogo trava e exibe uma mensagem de erro enigmática [19]lembrando alguns de nós do ameaçador "Chega de visplanes".Quanto mais sprites você vê ao mesmo tempo, mais VRAM é usado.A diferença entre PAL e NTSC
Concluindo o capítulo em vídeo, decidi ver como o NTSC é convertido em PAL. Infelizmente, como em muitos outros jogos, o DOOM PSX não levou em consideração o aumento da resolução vertical. Ao jogar DOOM no PS1 na Europa, você viu uma imagem verticalmente compactada com bordas pretas visíveis.Depois de aprender sobre os princípios da VRAM, é difícil culpar os desenvolvedores. Se você observar atentamente o esquema VRAM no NTSC, perceberá que o aumento da resolução vertical do buffer de quadros viola toda a estrutura de alocação de dados. Seria impossível armazenar texturas embaixo dele. Ou você teria que mover o CLUT para outro local. Demasiado custo com relativamente pouco benefício e, apesar do fato de as bordas pretas interferirem no jogo, concordo que não valeu a pena.Agradecimentos
Agradeço a Eric Vazquez (autor do PSXDOOM-RE), Samuel Villarreal (um dos desenvolvedores do PSXDOOM-RE) e Dan Leslie (desenvolvedor profissional de jogos para PlayStation 1) por compartilharem generosamente seus conhecimentos comigo.