Comment ont-ils fait bouger l'écran dans Dangerous Dave?

J'ai fait des jeux en BASIC quand j'étais enfant, et j'étais curieux de savoir comment les graphiques étaient faits dans la version 1988 de Dangerous Dave faite en C ++; surtout parce qu'ils n'avaient pas de paquets graphiques valables ces jours-ci. Rappelez-vous comment lorsque Dave a atteint le bord de l'écran, le graphique de l'écran entier utilisé pour se déplacer vers la gauche dans un mouvement de balayage? Je me souviens avoir lu que Romero avait utilisé une technique spéciale pour ce faire. Je voulais créer quelque chose comme Dave et je me demandais

1. quel package / méthode graphique ils ont utilisé pour Dave?
2. et comment faire bouger tout le graphique de l'écran comme ils l'ont fait?

Ma version 1988 de Dangerous Dave était la version Apple II. Le défilement a été effectué en déplaçant tous les octets d'écran, puis en dessinant une nouvelle tuile sur le bord de l'écran - répétez 20 fois pour un décalage d'écran complet. La version Apple II a été écrite entièrement en langage assembleur 6502.

Sur le PC, la version 1990, j'ai écrit du code graphique en langage assembleur 80x86 pour tous les modes vidéo de l'époque: CGA, EGA, VGA. Dangerous Dave PC est le seul jeu que je connaisse qui possède les 3 modes vidéo et commutable à tout moment (F2), même au milieu d'un saut!

Pour faire défiler l'écran rapidement, tout était en langage assembleur et j'ai utilisé une technique similaire à celle utilisée avec la version Apple II - déplacer rapidement les octets dans la mémoire vidéo et dessiner une tuile sur le côté droit. En EGA, c'était plus délicat car pour faire quoi que ce soit rapidement en mode EGA, il fallait utiliser le mode Latch pour les déplacements de mémoire. Je me souviens avoir enseigné à Todd Replogle comment faire pour que Duke Nukem 1 soit un jeu amusant (un Duke Nukem lent n'aurait pas été cool).

Le code du jeu pour Dangerous Dave PC a été écrit en C, dans l'IDE Borland C 3.0. La plupart du débogage a été effectué dans Turbo Debugger sur un moniteur 12 "orange branché sur une carte Hercules.

Ah je me souviens de ces techniques de mes jours DOS. Déplacer la RAM vidéo avec blitting pour effectuer un défilement aurait entraîné un défilement saccadé. EGA a introduit les registres de panoramique vertical et horizontal des pixels qui pouvaient être utilisés pour définir l'origine de l'écran (où dans la mémoire vidéo la carte vidéo a commencé à afficher des données). Parce qu'il n'y a pas de copie de mémoire en cours, cela est presque instantané et peut être utilisé pour un défilement pixel par pixel très fluide et rapide sur EGA et VGA si vous avez un accès direct aux registres matériels. La plupart des scrollers sous DOS l'auraient utilisé, et cette partie du code aurait probablement été écrite en langage assembleur pour accéder directement aux registres matériels. Cependant, ces méthodes ne sont plus vraiment valides. Pour obtenir un effet similaire maintenant, Je pense que sur du matériel graphique moderne, vous pourriez probablement le faire assez rapidement en redessinant tout l'écran à chaque image. L'autre méthode à laquelle je pense est d'utiliser OpenGL ou DirectX et de rendre une texture à un quadruple deux fois la largeur de l'écran et de la déplacer. D'une certaine manière, cela ne semble pas aussi amusant que de manipuler des registres matériels :)

Edit: Voici un lien vers un article du Dr Dobbs qui traite du défilement latéral. Ce peut être la méthode utilisée pour cet effet.

http://www.drdobbs.com/184408045

Il est difficile de juger exactement comment cela a été fait, mais considérez que ce jeu a été écrit pour une spécification matérielle très spécifique - DOS avec une carte vidéo EGA (640x480 pixels). Le code fait probablement quelques manipulations de bas niveau de la mémoire vidéo pour que le défilement se fasse en douceur.

Voici un site Web qui parle de la programmation de graphiques DOS qui pourraient vous donner une idée de ce que ce serait ...

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

Metagun (jeu développé par Markus aka Notch aka MineCraft guy) a la même sensation de défilement que vous recherchez.

Le jeu est Open-Source et écrit en Java.

• Jeu: http://www.mojang.com/compo/metagun/
• Source: http://www.mojang.com/compo/metagun/metagun-source.zip

J'espère que vous apprendrez en regardant le code.

Je peux penser à deux façons de procéder:

1. Force brute: il suffit de dessiner la scène
2. Registres Mode-X et panoramique. Dessinez le bit à faire défiler et ajustez les registres de panoramique pour faire défiler la scène. Vous auriez besoin de redessiner la zone d'affichage supérieure à chaque image, mais c'est moins de travail à faire que de dessiner la zone de lecture principale. Vous n'auriez pas besoin de redessiner la zone inférieure car il y avait un registre dans le matériel qui obligerait les DAC vidéo à lire à partir de l'adresse 0 sur une ligne de balayage donnée (donc la zone inférieure serait à l'adresse 0 dans le ram vidéo et en haut) commencerait après la zone inférieure) ^* .

J'irais probablement avec 1) car il n'y a pas grand-chose graphiquement, il peut y avoir du code auto-généré pour blit et couper les images sur les bords. Une technique possible sur laquelle un de mes collègues travaillait à l'époque était les sprites auto-écrits, c'est-à-dire que les données de sprite n'étaient pas des données, c'était du code. Cela signifiait qu'il n'y avait pas de vérification de transparence et que les données lues du blit étaient effectivement libres (c'était sur un 386 où chaque instruction était lue puis décodée donc au lieu de lire le code-> lire les données-> écrire les données c'était juste lire le code- > écrire des données). Cela a fonctionné incroyablement bien - nous avons eu beaucoup de sprites énormes sur plusieurs couches de parallaxe fonctionnant à 25fps +.

Mais nous parlons de Romero ici et il y a probablement un peu d'exagération à propos des techniques.

• J'ai effectivement fait cela dans mon premier jeu DOS majeur, et il y a un bug dans certains matériels où la réinitialisation de l'adresse s'est produite trop tôt sur une ligne de balayage afin que vous ayez un pixel à mi-hauteur entre les deux sections.