Como eles fizeram a tela se mover no Dangerous Dave?

14

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?
Nav
fonte
1
Seu um jogo em que eu me lembro como um presente da minha infância
Vishnu
Para um vídeo deste jogo em ação, para ver o efeito de rolagem que Nav está falando, consulte dosgamesarchive.com/download/dangerous-dave
Tim Holt

Respostas:

18

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.

user42604
fonte
Uau! É bom obter informações de alguém que realmente trabalhou nesses modos de vídeo em montagem!
Nav
@Nav ehm ... você está realmente falando sozinho Romero :-)
Gianluca Ghettini
@GianlucaGhettini Bem, é um usuário com a foto de Romero que está disponível na internet. John Romero criaria uma conta apenas para responder a uma pergunta? Não posso ter certeza absoluta :-) É muito estranho, porém, que você tenha comentado apenas um dia depois que eu interpretei o Dangerous Dave depois de um tempo muito longo.
Nav
@Nav de acordo com seu tweet aqui: twitter.com/romero/status/679769135681826817 ele realmente disse a Todd Replogle como fazer rolagem suave EGA para Duken Nukem, que é exatamente o que ele está afirmando nesta resposta. Eu duvido que alguém fingindo ser ele sabe sobre ele .. :-)
Gianluca Ghettini
Este artigo confirma que user42604 é de fato Romero gamasutra.com/blogs/DavidLightbown/20170223/289955/…
mastazi
13

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 :)

madeyes
fonte
3
"De alguma forma, não parece tão divertido quanto manipular os registros de hardware :)" - Verdadeiro :)
14/10
4

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

Tim Holt
fonte
Este jogo usaria o modo de vídeo de 320x240.
Skizz
Skizz Também estava pensando nisso, mas encontrei algumas capturas de tela do jogo que eram 640x400 - uma resolução EGA. Havia versões diferentes do jogo, e acho que as primeiras eram de 320x200.
Tim Holt
4

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.

Espero que você aprenda olhando o código.

は る と
fonte
1
E caso você queira ver um timelapse dele fazendo o jogo: youtube.com/watch?v=ZV-AFnCkRLY
は る と
1
-1, embora pareça o mesmo, claramente não está usando o mesmo método.
2
Estou ciente de que esse não é o método exato que John Romero usou em 1988. Mas como o @Nav queria criar algo semelhante, não o fiz para programá-lo usando o Applesoft BASIC em um computador Apple II. O código ao qual vinculei claramente faz o mesmo trabalho que você apontou.
はると
Obrigado Joe, mas a Eibx está certa de que eu também estava procurando maneiras alternativas.
Nav
2

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.
Skizz
fonte