Teoria e implementações de jogos vetoriais (Wireframe, tipo Elite)?


7

Eu sou interessante em saber mais sobre como jogos de vetor como Elite e Star Wars Atari foram construídos do zero. A questão não é como implementar gráficos vetoriais com APIs 3D modernas, como OpenGL e DirectX, pois isso é bastante fácil e não requer a construção de um sistema de vetores / matrizes do zero, como fizeram esses jogos.

Algumas coisas que presumo sobre esses jogos:

  • Eles trabalham em um nível extremamente baixo e são escritos em ASM
  • Eles são jogos 3D reais e não fingem como o After Burner. Também não é como o Wolfenstein 3D. O Afterburner usou efeitos rotozoom / raster e o Wolfenstein 3D usou raycasting e escala 2D e não é realmente 3D, já que você não pode subir. Mesmo que você possa gostar do Build Engine que o Duke Nukem 3D usou, tudo, exceto as paredes, é apenas um sprite. A Star Fox está mais próxima, já que usa modelos 3D reais, mas a implementação usa o chip Super-FX do SNES e provavelmente emprega truques de scanline. Sei que o Elite provavelmente também usa esses truques (pelo menos em algumas implementações como o Elite NES), mas não tenho certeza sobre o SWA, pois ele usava uma máquina de fliperama personalizada; de qualquer maneira, eu gostaria de saber mais sobre isso.
  • Seus modelos 3D são modelos 3D reais. Eles são definidos como vetores e transformados de acordo com a posição da câmera.

Eu sei que a melhor coisa a fazer seria desmontar a fonte do Elite e ver como as coisas foram feitas por mim, mas antes de fazer isso, quero saber mais sobre como elas foram feitas e se existem projetos modernos de código aberto que mostram técnicas semelhantes . Não me refiro a Elite remakes como Oolite (que usa OpenGL e Obj-C), mas projetos que usam técnicas semelhantes e evitam usar APIs como OpenGL diretamente - não necessariamente projetos de baixo nível, porém, usando biblioteca 2D como SDL (sem OGL) deve ser suficiente, pelo menos por enquanto.

Eu sei que o código fonte do MESA3D provavelmente contém muitas das rotinas que jogos como Elite e SWA implementaram - eu só quero vê-los no contexto de um jogo. Eu sei que o que a Elite e a SWA basicamente fizeram foi implementar a rasterização, criar seu formato para modelos e um carregador (tenho certeza de que pelo menos a SWA tinha modelos construídos a partir de modeladores usando ferramentas, embora não seja impossível codificar os TIE-Fighters é difícil fazê-lo com precisão) e muitas outras coisas das quais posso desconhecer. Mas é realmente demorado entrar e eu não me importo com muitas das coisas que estão nele. Lembre-se de que jogos como o Elite eram muito leves devido à baixa ROM e RAM que os computadores e consoles tinham na época.

Eu sou novo em gráficos 3D e todas as minhas suposições são baseadas no meu conhecimento limitado de geometria 3D e matemática no nível da escola, desculpe se eu disse alguma besteira. Mas eu realmente gostaria de saber mais sobre como esses jogos funcionam em todos os detalhes, e possivelmente não apenas "comprar um livro X", já que estou sem dinheiro. Embora eu comprasse um livro sobre o desenvolvimento do Elite ou um jogo similar, se ele existisse. Algumas sugestões gerais seriam suficientes.


Vale ressaltar que Elite e Star Wars funcionaram de maneiras muito diferentes. A Elite usou a rasterização de software de modelos 3D em pixels, enquanto Star Wars rodava em uma exibição vetorial, que nem tinha pixels; em vez disso, o feixe de exibição desenharia diretamente linhas coloridas arbitrárias na tela, mas não poderia preenchê-las.
Trevor Powell

Eles não desenharam linhas de Bresenham (ou linhas DDA) para pontos projetados (podem ser derivados em triângulos semelhantes)?
user712092

Respostas:


3

A questão não é como implementar gráficos vetoriais com APIs 3D modernas, como OpenGL e DirectX, pois isso é bastante fácil e não requer a construção de um sistema de vetores / matrizes do zero, como fizeram esses jogos.

Os vetores são literalmente apenas uma lista de números. Matrizes são apenas uma grade de números. A parte interessante é a matemática que você usa nelas, mas essas coisas também são triviais - basta pegar um livro de matemática de nível escolar onde esse tipo de coisa é explicado. São apenas 50 a 100 linhas de código, portanto, não superestime o esforço aqui.

Eles são jogos 3D reais e não fingem como o After Burner. Também não é como o Wolfenstein 3D.

O Wolfenstein 3D é basicamente 3D real, porque a transmissão de raios é indiscutivelmente mais 'real' do que a abordagem geométrica usual que adotamos. Ainda assim, você está certo ao identificar que é um modelo diferente e não um modelo em que você está interessado aqui.

Eu sei que a melhor coisa a fazer seria desmontar a fonte da Elite e ver como as coisas foram feitas por mim

Não se preocupe muito com o Elite, em particular. Não está usando nada de especial - a rasterização de software é praticamente a mesma, independentemente de qual parte do software o fez. Você pega cada objeto e transforma todas as suas coordenadas no espaço do mundo, depois transforma todas essas coordenadas do espaço do mundo em relação ao visualizador para que elas fiquem no espaço de visualização e, em seguida, as projeta para 2D para que fiquem no espaço da tela. Cada transformação é basicamente apenas uma rotação e uma tradução, e a projeção geralmente é pouco mais que uma divisão, se você fizer as suposições corretas.

Existem outros bits complicados dos quais não me lembro imediatamente, como remover as faces invisíveis, mas acho que isso pode ser feito apenas com a ordem dos vértices - crie uma linha entre dois vértices conectados, se estiverem na tela no sentido horário espaço, e não se não forem. (Por exemplo.)

não é impossível codificar os caças TIE, é difícil fazê-lo com precisão

A maioria desses modelos tinha apenas 20 ou 30 vértices - facilmente dentro do campo da codificação. Espero que os autores originais desenhem os modelos em papel milimetrado e depois copiem os valores dos vértices no código.


Então, meu palpite para rasterização estava certo? Se entendi direito o que você disse, não é diferente da programação 3D padrão usando, digamos, OpenGL. Multiplicações de matrizes e gostos, certo? Mas vou ter que descobrir a seleção de backface e o buffer Z. Você conhece alguma boa implementação de código aberto de rasterização? Eu acho que o algoritmo não é tão difícil, mas eu gosto de brincar com o código para entender as coisas, não quero copiar nada (também porque estou usando um Z80 ASM modificado, que é muito específico), mas ainda é bom ter algum tipo de referência.
EliteIsAwesome

Certamente, toda renderização de software de gráficos vetoriais é rasterizada por definição. Não conheço nenhum exemplo de código fonte, mas depois de ter os vértices no espaço da tela, é possível desenhar as linhas usando o algoritmo de Bresenham. Quanto ao abate de backface e buffer Z, o Elite não tem 'faces', apenas arestas, e certamente não estava usando nenhum tipo de buffer de profundidade - simplesmente não havia memória suficiente para isso, e somente essa técnica realmente começou a ser usado para jogos em meados dos anos 90.
Kylotan

Sim, eu sabia que o Z-Buffering veio relativamente mais tarde, deveria ter dito "Z-culling". Acho que vou ter que usar um dos algoritmos mais simples. Obrigado por me indicar o algoritmo de Bresenham, parece bastante barato.
EliteIsAwesome

2

Você está procurando 3D baseado em vértice que suporta geometrias arbitrárias (irrestritas) no espaço 3D. O traçado de raios no sentido original é 3D real, pois pode suportar graus de liberdade ilimitados (DoF). Raycasting (no sentido do desenvolvimento do jogo, em vez do sentido original, que é semelhante ao raytracing, exceto na direção dos raios), no entanto, restringe os graus de liberdade, por exemplo. mapas baseados em altura, como o encontrado no voxel raycaster de Comanche, ou Wolfenstein, que na verdade faz o jogador se mover em um espaço 2D puro. Qualquer mecanismo 3D que suporte geometrias arbitrárias sem restrição de eixo é apenas uma representação no espaço da tela de algum tipo do modelo de um mundo 3D, independentemente dessa representação.

Eles trabalham em um nível extremamente baixo e são escritos em ASM

No caso da Elite, como você provavelmente sabe, sim, foi. Partes de outros jogos semelhantes foram certamente escritas em instruções ASM ou de código de máquina em todos os casos, considerando o processamento matemático exigente sem nada como as ALUs que temos hoje. Como existem apenas pequenas partes de qualquer base de código que são realmente críticas para o desempenho, é possível que algumas partes menos críticas de algumas delas (como o 3D Construction Kit e os jogos que ele criou, por exemplo) tenham sido escritas em C ++. No entanto, novamente, considerando os recursos limitados, particularmente nas máquinas da era anterior a 16 bits, é mais parecido com uma mistura de código de montador e de máquina bruta (você pode realmente inserir grandes sequências de zeros e zeros e armazená-las em disco como um programa - que Deus o ajude se cometer um erro).

Seus modelos 3D são modelos 3D reais

Notas adicionais sobre o processo de construção desses jogos a partir do zero:

Matemática, antes de mais nada. Para ser autêntico, você usaria matemática de ponto fixo. O que você pode implementar no final da matemática determinará que tipo de jogo você pode fazer. Período. Posso garantir que essa é a filosofia que Braben e Bell adotaram para a elite. Protótipo, otimizar, enxaguar e repetir. Veja o que é possível. Em seguida, projete seu jogo em torno do que você tornou possível. Este não será o caso nos sistemas atuais, como já sabemos (o ponto mais baixo) do que é possível. Encontre (e de preferência entenda a matemática por trás - mas isso não é 100% necessário) das implementações básicas dos blocos de construção: vetores 3D, matrizes de rotação, Quaternions (acho que eles favoreciam a rotação euleriana no passado, mas não é certo, de qualquer maneira os Quaternions são mais barato de calcular) e similares. Também é 'não subestime o impacto e a estrutura de dados eficiente no desempenho!

Em seguida, escrevendo o código. Implemente essas estruturas e operações (bem como estruturas e lógica acompanhantes para seu jogo mais amplo, como tal) em uma linguagem de nível superior, como C ++ ou até melhor (mais rápido), C. Em seguida, otimize os blocos asm a partir daí, conforme e quando necessário. Como presumo que você deseje fazer isso no x86 ou em outra arquitetura moderna, isso deve ser suficiente para seus propósitos. Se o hardware da era de 16 bits, como os sistemas baseados no Motorola 68000, use C e refatorar no ASM com frequência. Se o hardware de 8 bits, C é factível para bits limitados, eu acho, mas você provavelmente estará refatorando impiedosamente o ASM. Se estiver trabalhando em sistemas de 8 ou 16 bits, será necessário se familiarizar com as arquiteturas, os truques cada vez mais obscuros usados ​​nessas plataformas e assim por diante, para que eu não recomende essa rota, pois é literalmente uma arte escura hoje em dia (embora, surpreendentemente, ainda existam comunidades que se desenvolvam para esses sistemas, na maior parte extintos).

Sua investigação minuciosa das técnicas da velha escola é recomendável. Você certamente acabará apreciando o quanto imaginável pode ser feito com o hardware que temos hoje.


Alguns jogos semelhantes que eu lembro, além do 3DCK, para você conferir:

  • Lado escuro
  • Starglider
  • Interfase
  • Vírus (joguinho excelente)
  • Conqueror (o mesmo mecanismo do Virus, usado para tocar isso em um único teclado com um amigo, um cara como o artilheiro de tanque e outro o motorista, ótimas lembranças)
  • Mercenary (lançado apenas alguns meses após a Elite)
  • Dâmocles (e outras sequências mercenárias e discos de missão)
  • Novell NetWars para arquitetura x86 (ainda pode ser executado em algo como o Dosbox, embora executá-lo em rede exija uma configuração autêntica, eu acho)

Sobre os motores baseados em fundição de raios não serem reais em 3D, eu estava me referindo ao fato de que a maioria deles apenas representava um espaço bidimensional. A Elite permitiu movimentos de 360 ​​° e essa, para mim, é a definição de jogo em 3D. A definição de representação 3D é mais flexível, concordo plenamente! Edit: Eu queria agradecer por sua resposta completa. Se você estiver interessado, estou desenvolvendo minha pequena demo do tipo Elite no Gameboy. Boa sorte com o seu motor voxel!
EliteIsAwesome

Ei, sim, refinei e refinei essa seção, sei o que você quis dizer, posso dizer que fez uma boa pesquisa antes de fazer essa pergunta. Re seu jogo, estou muito interessado, existe algum feed ou algo que eu possa assinar?
Engenheiro de

Eu tentei o meu melhor. Eu já estava planejando aprofundar a matemática. Você pode sugerir mais assuntos que eu deva considerar além dos que você já mencionou? Não tenho medo deles!
EliteIsAwesome

Apenas reeditado - descrição do raytracing vs. raycasting. É uma distinção importante a fazer. Raycasting no sentido original era apenas uma otimização do raytracing, mas mais tarde "raycaster" passou a significar jogos implementados no estilo 3D Wolfenstein / Doom / Duke Nukem. Re matemática, o meu nunca foi impressionante. Mas você pode fazer uma quantidade notável, mesmo com os tópicos que mencionei. Além disso, consulte 3D Math para programadores de jogos e estruturas de dados para programadores de jogos. GPU Gems series e páginas da Web de Paul Bourke para geometria computacional.
Engenheiro de

OK obrigado. Embora eu ache que vou ter dificuldade em traduzir cálculos extensos para vários registros e um pouco de memória! Não tenho blogs / feeds sobre o meu projeto, já que fiz muito pouco - o material de origem é muito escasso, mas acho que é por isso que o achei tão charmoso. Se eu fizer algo com isso, acho que você ouvirá sobre isso, já que provavelmente vou ter que vir aqui por segundos! Além disso, para adicionar à sua lista de jogos vetor, veja www.everyvideogame.com/showthread.php?p=11539
EliteIsAwesome
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.