¿Cómo hicieron que la pantalla se moviera en Dangerous Dave?

Hice juegos en BASIC cuando era niño, y tenía curiosidad acerca de cómo se hicieron los gráficos en la versión 1988 de Dangerous Dave hecha en C ++; especialmente porque no tenían ningún paquete de gráficos que valiera la pena esos días. ¿Recuerdas cómo cuando Dave llegó al borde de la pantalla, todo el gráfico de la pantalla solía moverse hacia la izquierda en un movimiento de barrido? Recuerdo haber leído que Romero había usado una técnica especial para hacer eso. He estado queriendo crear algo como Dave, y me preguntaba

1. ¿Qué paquete / método de gráficos utilizaron para Dave?
2. ¿Y cómo hacer que todo el gráfico de la pantalla se mueva como lo hicieron?

Mi versión 1988 de Dangerous Dave fue la versión de Apple II. El desplazamiento se realizó moviendo todos los bytes de la pantalla y luego dibujando un nuevo mosaico en el borde de la pantalla; repita 20 veces para un cambio de pantalla completa. La versión de Apple II fue escrita en lenguaje ensamblador 6502.

En la PC, la versión de 1990, escribí un código gráfico en lenguaje ensamblador 80x86 para todos los modos de video en ese momento: CGA, EGA, VGA. Dangerous Dave PC es el único juego que conozco que tiene los 3 modos de video y se puede cambiar en cualquier momento (F2), ¡incluso en medio de un salto!

Para desplazar la pantalla rápidamente, todo estaba en lenguaje ensamblador y utilicé una técnica similar a la que utilicé con la versión Apple II: mover rápidamente los bytes en la memoria de video y dibujar un mosaico en el lado derecho. En EGA fue más complicado porque hacer algo rápidamente en modo EGA requería el uso del modo Latch para movimientos de memoria. Recuerdo haberle enseñado a Todd Replogle cómo hacerlo para que Duke Nukem 1 fuera un juego divertido (un Duke Nukem lento no hubiera sido genial).

El código del juego para Dangerous Dave PC fue escrito en C, en el Borland C 3.0 IDE. La mayor parte de la depuración se realizó en Turbo Debugger en un monitor ámbar de 12 "conectado a una tarjeta Hercules.

Ah, recuerdo estas técnicas de mis días de DOS. Mover la RAM de video con blitting para realizar el desplazamiento habría resultado en un desplazamiento desigual. EGA introdujo los registros de desplazamiento panorámico de píxeles verticales y horizontales que podrían usarse para establecer el origen de la pantalla (donde en la memoria de video la tarjeta de video comenzó a mostrar datos). Debido a que no se realiza ninguna copia de memoria, esto es casi instantáneo y puede usarse para un desplazamiento de píxel a píxel muy suave y rápido en EGA y VGA si tiene acceso directo a los registros de hardware. La mayoría de los desplazadores en DOS habrían usado esto, y esta parte del código probablemente habría sido escrita en lenguaje ensamblador para acceder directamente a los registros de hardware. Sin embargo, estos métodos ya no son realmente válidos. Para lograr un efecto similar ahora, Creo que en el hardware de gráficos moderno probablemente podría hacerlo lo suficientemente rápido simplemente redibujando la pantalla completa de cada fotograma. El otro método que se me ocurre es usar OpenGL o DirectX y renderizar una textura a un cuádruple dos veces el ancho de la pantalla y moverla. De alguna manera, no parece tan divertido como manipular registros de hardware :)

Editar: Aquí hay un enlace a un artículo del Dr. Dobbs que analiza el desplazamiento lateral. Puede ser el método utilizado para este efecto.

http://www.drdobbs.com/184408045

Es difícil juzgar exactamente cómo se hizo esto, pero tenga en cuenta que este juego fue escrito para una especificación de hardware muy específica: DOS con una tarjeta de video EGA (640x480 píxeles). El código probablemente está haciendo algunas manipulaciones de nivel bastante bajo de la memoria de video para que el desplazamiento se realice sin problemas.

Aquí hay un sitio web que habla sobre la programación de gráficos de DOS que podrían darle una idea de cómo sería ...

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

Metagun (juego desarrollado por Markus alias Notch alias MineCraft) tiene la misma sensación de desplazamiento que estás buscando.

El juego es de código abierto y está escrito en Java.

• Juego: http://www.mojang.com/compo/metagun/
• Fuente: http://www.mojang.com/compo/metagun/metagun-source.zip

Espero que aprendas mirando el código.

Puedo pensar en dos formas en que esto se ha hecho:

1. Fuerza bruta: solo dibuja la escena
2. Modo X y registros panorámicos. Dibuje el bit que se desplazará a la vista y ajuste los registros de desplazamiento para desplazar la escena. Debería volver a dibujar el área de visualización superior de cada cuadro, pero eso es menos trabajo que dibujar el área de juego principal. No necesitaría volver a dibujar el área inferior, ya que había un registro en el hardware que haría que los DAC de video leyeran desde la dirección 0 en una línea de exploración determinada (por lo que el área inferior estaría en la dirección 0 en la memoria RAM de video y la parte superior comenzaría después del área inferior) ^* .

Probablemente iría con 1) ya que no hay mucho gráfico, puede haber algún código autogenerado para borrar y recortar imágenes en los bordes. Una técnica posible en la que un colega mío estaba trabajando en ese entonces era los sprites de auto escritura, es decir, los datos del sprite no eran datos, era código. Esto significaba que no había controles de transparencia y que la lectura de datos del blit era efectivamente libre (esto era en un 386 donde cada instrucción se leía y luego se decodificaba, así que en lugar de leer código-> leer datos-> escribir datos, solo era leer código- > escribir datos). Funcionó increíblemente bien: obtuvimos muchos sprites enormes en múltiples capas de paralaje a más de 25 fps.

Pero estamos hablando de Romero aquí y probablemente hay un poco de exageración sobre las técnicas.

• Realmente hice esto en mi primer juego importante de DOS, y hay un error en algún hardware por el cual el restablecimiento de la dirección se produjo con un escaneo demasiado pronto, por lo que tendría un píxel de media altura entre las dos secciones.