Como eles fizeram a tela se mover no Dangerous Dave?

Eu fiz jogos no BASIC quando era criança e fiquei curioso sobre como os gráficos foram feitos na versão de 1988 do Dangerous Dave, feita em C ++; especialmente porque eles não tinham nenhum pacote gráfico interessante naquele tempo. Lembra como quando Dave alcançou a borda da tela, todo o gráfico da tela costumava se mover para a esquerda em um movimento de varredura? Lembro-me de ler que Romero havia usado uma técnica especial para fazer isso. Eu estava querendo criar algo como Dave, e queria saber

1. que pacote / método gráfico eles usaram para Dave?
2. e como fazer com que todo o gráfico da tela se mova como eles?

Minha versão de 1988 do Dangerous Dave foi a versão do Apple II. A rolagem foi feita movendo todos os bytes da tela e desenhando um novo bloco na borda da tela - repita 20 vezes para uma mudança de tela cheia. A versão do Apple II foi escrita em linguagem assembly 6502.

No PC, versão de 1990, escrevi código gráfico em linguagem assembly 80x86 para todos os modos de vídeo da época: CGA, EGA, VGA. Dangerous Dave PC é o único jogo que conheço que possui todos os 3 modos de vídeo e selecionável a qualquer momento (F2), mesmo no meio de um salto!

Para rolar a tela rapidamente, era tudo em linguagem assembly e eu usei uma técnica semelhante à da versão Apple II - mova rapidamente os bytes na memória de vídeo e desenhe um bloco no lado direito. No EGA, era mais complicado, porque para fazer qualquer coisa rapidamente no modo EGA, era necessário o uso do Modo de Trava para movimentação de memória. Lembro-me de ensinar Todd Replogle a fazer isso para que o Duke Nukem 1 fosse um jogo divertido (um lento Duke Nukem não seria legal).

O código do jogo para Dangerous Dave PC foi escrito em C, no Borland C 3.0 IDE. A maioria das depurações foi feita no Turbo Debugger em um monitor âmbar de 12 "conectado a uma placa Hercules.

Ah, eu lembro dessas técnicas dos meus dias no DOS. Mover a RAM do vídeo com blitting para executar a rolagem resultaria em rolagem brusca. A EGA introduziu os registros de panning de pixels verticais e horizontais que poderiam ser usados ​​para definir a origem da tela (de onde na memória de vídeo a placa de vídeo começou a exibir dados). Como não há cópia de memória, isso é quase instantâneo e pode ser usado para pixel muito suave e rápido, rolando pixel em EGA e VGA, se você tiver acesso direto aos registros de hardware. A maioria dos scrollers no DOS usaria isso, e essa parte do código provavelmente teria sido escrita em linguagem assembly para acessar diretamente os registros de hardware. Esses métodos não são realmente mais válidos. Para alcançar um efeito semelhante agora, Eu acho que no hardware gráfico moderno você provavelmente poderia fazê-lo rápido o suficiente apenas redesenhando a tela inteira a cada quadro. O outro método em que posso pensar é usar o OpenGL ou o DirectX e renderizar uma textura em um quad com o dobro da largura da tela e movê-la. De alguma forma, não parece tão divertido quanto manipular registros de hardware :)

Edit: Aqui está um link para um artigo do Dr. Dobbs que discute a rolagem lateral. Pode ser o método usado para esse efeito.

http://www.drdobbs.com/184408045

É difícil julgar exatamente como isso foi feito, mas considere que este jogo foi escrito para uma especificação de hardware muito específica - DOS com uma placa de vídeo EGA (640x480 pixels). O código provavelmente está fazendo algumas manipulações de nível de memória de vídeo bastante baixas para fazer a rolagem acontecer sem problemas.

Aqui está um site que fala sobre a programação de gráficos do DOS que podem lhe dar uma idéia de como seria ...

http://www.phatcode.net/res/224/files/html/index.html

Metagun (jogo desenvolvido por Markus, também conhecido como Notch ou MineCraft) tem a mesma sensação de rolagem que você está procurando.

O jogo é de código aberto e escrito em Java.

• Jogo: http://www.mojang.com/compo/metagun/
• Fonte: http://www.mojang.com/compo/metagun/metagun-source.zip

Espero que você aprenda olhando o código.

Posso pensar em duas maneiras de fazer isso:

1. Força bruta: basta desenhar a cena
2. Registros de modo X e panorâmica. Desenhe o bit a ser rolado para exibição e ajuste os registros de panorâmica para rolar a cena. Você precisaria redesenhar a área de exibição superior a cada quadro, mas isso é menos trabalhoso do que desenhar a área de reprodução principal. Você não precisaria redesenhar a área inferior, pois havia um registro no hardware que faria com que os DACs de vídeo lessem do endereço 0 em uma determinada linha de digitalização (para que a área inferior estivesse no endereço 0 na ram de vídeo e na parte superior). inicia após a área inferior) ^* .

Eu provavelmente iria com 1) como não há muita coisa acontecendo graficamente, pode haver algum código auto-gerado para misturar e recortar imagens nas bordas. Uma técnica possível em que um colega meu estava trabalhando na época era sprites de auto-gravação, ou seja, os dados do sprite não eram dados, eram códigos. Isso significava que não havia verificações de transparência e que os dados lidos da citação eram efetivamente livres (isso era em um 386 em que cada instrução era lida e decodificada, em vez de ler o código-> ler dados-> escrever dados, era apenas ler o código- > escrever dados). Funcionou incrivelmente bem - temos muitos sprites enormes em várias camadas de paralaxe rodando a 25fps +.

Mas estamos falando de Romero aqui e provavelmente há um pouco de exagero em relação às técnicas.

• Na verdade, eu fiz isso no meu primeiro grande jogo DOS, e há um bug em algum hardware em que a redefinição de endereço ocorreu uma linha de verificação muito cedo, para que você tenha um pixel de meia altura entre as duas seções.