¿Qué es el "hack de desplazamiento lateral" de juegos antiguos?

Question

He oído que los antiguos juegos de desplazamiento lateral de arcade usaban un hack específico de programación para permitir el desplazamiento lateral.

Entiendo que hace años las máquinas no eran lo suficientemente potentes como para volver a pintar toda la pantalla en cada fotograma como se hace hoy en día. Existen técnicas, como rectángulos sucios, que permiten minimizar el área de la pantalla necesaria para volver a pintar cuando el fondo está estacionario y solo se mueven los sprites.

El enfoque anterior solo funciona cuando el fondo no cambia (y, por lo tanto, la mayoría de los píxeles de la pantalla permanecen estacionarios).

Los juegos de desplazamiento vertical, como los shoot'em ups de la vieja escuela, tienen la cosa un poco más difícil con el fondo cambiando cada cuadro debido al desplazamiento. Sin embargo, se podría aprovechar la forma en que se alimentan los píxeles a la pantalla (línea por línea). Me imagino que uno podría usar un búfer más grande y desplazar el puntero de datos algunas líneas "hacia abajo" en cada cuadro, por lo que se volverá a dibujar a partir de otra posición, dando así la impresión de un desplazamiento suave. Sin embargo, solo los sprites (y un poco del fondo en el borde de la pantalla) tendrían que volver a dibujarse, lo cual es una optimización seria.

Sin embargo, para los juegos de desplazamiento lateral , la cosa no es tan simple y obvia. Aún así, soy consciente de que alguien, en algún momento del pasado, tuvo una optimización que (con algunas limitaciones) permitió a las máquinas antiguas desplazar el fondo horizontalmente sin volver a dibujarlo en cada fotograma.

IIRC fue utilizado en muchos juegos antiguos, la mayoría de los 80 planos beat'em, así como en producciones demoscene

Puede describir esta técnica y el nombre de su autor?

Answer 1

He escrito juegos para el viejo C64 haciendo exactamente esto. Y hay básicamente dos cosas a tener en cuenta:

1. estos juegos no estaban usando gráficos de mapas de bits, pero en su lugar usó "reasignar" fuentes de caracteres, lo que significa que los trozos de 8x8 píxeles en realidad estaban hurdled su alrededor como un solo byte .

2. Lo siguiente a tener en cuenta es que había soporte de hardware para desplazar toda la pantalla a siete píxeles. Tenga en cuenta que esto no afectó de ninguna manera a ningún gráfico; simplemente hizo que todo lo que se enviaba al televisor se desplazara un poco.

Por lo tanto, 2) hizo posible deslizar realmente suave a 7 píxeles de distancia. Luego, movió a cada personaje, que para una pantalla completa tenía exactamente 1000 bytes, con los que la computadora podría lidiar, mientras que al mismo tiempo, movía el registro de desplazamiento 7 píxeles hacia atrás. 8 - 7 = 1 significa que parecía que se desplazó otro píxel más ... y luego continuó de esa manera. ¡Así que 1) y 2) combinados hicieron la ilusión de un verdadero desplazamiento suave!

Después de eso, una tercera cosa entró en juego: interrupciones de trama. Esto significa que la CPU recibe una interrupción cuando el televisor/monitor estaba a punto de comenzar a dibujar una línea de exploración en una ubicación específica. Esa técnica hizo posible crear una pantalla dividida para que no se requiriera desplazar la pantalla entera en lugar de mi primera descripción.

Y para estar aún más en los detalles: incluso si no deseaba una pantalla dividida, la interrupción de ráster era muy importante de todos modos: porque era tan importante como lo es hoy (pero hoy el marco oculta esto de usted) para actualizar la pantalla en el momento adecuado. La modificación del "registro de desplazamiento" cuando el televisor/monitor se estaba actualizando en cualquier parte del área visible provocaría un efecto llamado "rasgado", donde se observa claramente que las dos partes de la pantalla tienen un píxel de sincronización sincronizada entre sí.

¿Qué más hay para decir? Bueno, la técnica con juegos de caracteres remapeados hizo posible hacer algunas animaciones muy fácilmente. Por ejemplo, transportadores, ruedas dentadas y otras cosas podrían animarse cambiando constantemente la apariencia de los "personajes" que los representan en la pantalla. Por lo tanto, un transportador que abarque todo el ancho de la pantalla podría verse como si estuviera girando en todas partes simplemente cambiando un solo byte en el mapa de caracteres.

Answer 2

Hice algo similar en los años 90, usando dos enfoques diferentes.

La primera implicaba "ventanas", que era compatible con el estándar VESA SVGA. Algunas tarjetas lo implementaron correctamente. Básicamente, si tiene un frame buffer/video RAM más grande que el área visualizable, puede dibujar un mapa de bits grande y dar las coordenadas del sistema para una ventana dentro de esa área que desea mostrar. Al cambiar esas coordenadas, puede desplazarse sin tener que volver a llenar el búfer de cuadros.

El otro método se basó en la manipulación del método BLT utilizado para obtener un fotograma completo en el búfer de fotogramas. Separar una página en el búfer de fotogramas que tenía el mismo tamaño que la pantalla es fácil y eficiente.

yo encontramos este antiguo código 286 ensamblador (en un funcionamiento antiguo disquete 17 años!) Que copiar una pantalla de 64000 bytes (320x200) desde una página fuera de la pantalla en el búfer de vídeo:

Procedure flip; assembler; 
    { This copies the entire screen at "source" to destination } 
    asm 
     push ds 
     mov  ax, [Dest] 
     mov  es, ax 
     mov  ax, [Source] 
     mov  ds, ax 
     xor  si, si 
     xor  di, di 
     mov  cx, 32000 
     rep  movsw 
     pop  ds 
    end; 

El rep movsw movió palabras CX (donde una palabra tiene dos bytes en este caso). Esto fue muy eficiente ya que básicamente es una instrucción única que le dice a la CPU que mueva todo lo más rápido posible.

Sin embargo, si tiene un búfer más grande (digamos, 1024 * 200 para un desplazamiento lateral), podría fácilmente utilizar un bucle anidado y copiar una sola fila de píxeles por bucle. En el búfer de ancho de 1024 píxeles, por ejemplo, puede copiar bytes:

start   count    
0+left   320 
1024+left  320 
... 
255*1024+left 320 

donde left es la coordenada x dentro de la gran imagen de fondo que desea iniciar al (lado izquierdo de la pantalla).

Por supuesto, en el modo de 16 bits, se requirió algo de magia y manipulación de punteros de segmento (ES, DS) para obtener un búfer mayor que 64KB (en realidad, múltiples búferes adyacentes de 64k), pero funcionó bastante bien.

Probablemente hubo mejores soluciones para este problema (y definitivamente mejores para usar hoy en día), pero funcionó para mí.

Answer 3

Los juegos Arcade presentaban frecuentemente chips de video personalizados o lógica discreta para permitir el desplazamiento sin que la CPU tenga que funcionar (mucho). El enfoque sería similar al que describía Danbystrom en el C-64.

Básicamente, el hardware de gráficos se encargó de los caracteres de desplazamiento fino (o mosaicos) y la CPU luego se encargó de reemplazar todas las fichas una vez que los registros de desplazamiento hayan alcanzado su límite.Actualmente estoy mirando la placa Irem m-52 que trata con fondos de desplazamiento múltiple en hardware. Los esquemas se pueden encontrar en línea.

Answer 4

Para desplazarse a la derecha en el Commodore Amiga utilizamos Cobre para desplazar hacia la derecha la pantalla hasta 16 píxeles. Cuando la pantalla cambió, añadimos 2 bytes a la dirección de inicio del búfer de pantalla, mientras que en el lado derecho usamos el Blitter para copiar los gráficos de la memoria principal al búfer de la pantalla. Ajustamos el buffer de la pantalla un poco más grande que la vista de la pantalla para que podamos copiar los gráficos sin que se vea un efecto de parpadeo en la copia del lado derecho de la ventana gráfica.