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

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.

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.

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)