Una de las características que nos pueden llamar la atención a la hora de probar la Atari 2600 es que algunos juegos sufren de un parpadeos (flickering) en los gráficos, que en algunos casos puede llegar a ser excesivo.
Lógicamente se debe hardware de la consola ya que sólo puede manejar 2 sprites a la vez. Los diseñadores tenían por tanto el continuo reto de superar el límite de las capacidades de la 2600 para dar cabida a los juegos que planteaban.
Sprites, parpadeos y el hardware de Atari 2600
La Atari 2600 permitía realmente el manejo de varios tipos de sprites: 2 Players, 2 Missiles, 1 Ball y 1 Playfield. Con esos nombres se demostraba que estaba perfectamente diseñada para poder llevar a casa juegos comparables a los éxitos de recreativa disponibles en ese momento, como Pong o el más reciente Tank.
Pero la repentina llegada desde Japón de la recreativa Space Invaders generó una revolución sin precedentes. Se puede decir que además de su éxito consiguió dejar obsoletos los juegos que ya estaban en el mercado.
Esto se trasladó también a la consola de Atari, la mecánica de juego del Space Invaders era tan nueva que simplemente VCS no estaba preparada para poder replicarla. La consola se quedaría ya anticuada frente a éste y la nueva generación de juegos que empezarían a llegar detrás.
¿Cómo lograron entonces realizar la conversión de Space Invaders para Atari?
Bien, el problema estaba en que la consola sólo podía mostrar 2 sprites en una misma línea horizontal a la vez.
Verticalmente no había problema porque ya se conocía una técnica en el que se podía reutilizar un sprite colocándolo en otra posición, ya se había probado y demostrado en juegos como Air Sea Battle.
Pero horizontalmente hablando, dos enemigos por fila quedaban insuficientes. Por suerte los diseñadores encontraron una técnica que permitía clonar cada sprite dos veces en horizontal, consiguiendo un total de tres. Si esto lo repetíamos con el segundo sprite disponible, conseguíamos seis sprites en una misma línea.
Seguía siendo inferior a los once enemigos por fila del arcade original, pero gracias a la combinación de ambas técnicas se consiguió tener una versión muy digna en nuestra Atari VCS.
A partir de aquí el resto de elementos del juego parecía que estaban diseñados para encajar perfectamente en la VCS: la nave nodriza no se solapaba con los invasores, ni tampoco los escudos barrera ni nuestro cañón. Cada uno tenía su propio espacio horizontal independiente que evitó mayores quebraderos de cabeza. Los escudos barrera también se clonaron horizontalmente y así se obtuvieron tres.
La conversión finalmente fue todo un éxito, todo un ‘killer-app’ para la consola y sentó un precedente que se usó durante la década de los ochenta y la primera mitad de los 90: el uso de licencias y vender el concepto de poder jugar la recreativa del momento en tu propia casa.
El caso Pac-man: el problema de sprites independientes
La recreativa del Pac-man contaba con cuatro fantasmas enemigos que se movían de forma independiente, aparte de nuestro querido Comecocos. Esto era totalmente opuesto a la mecánica del Space Invaders, donde los enemigos se movían como si realmente fueran uno solo.
Como consecuencia la conversión sufriría de un constante parpadeo de enemigos, al no poder dibujar todos los sprites a la vez. Pero en este caso el factor tiempo resultó más influyente, con la presión de tenerlo listo para su lanzamiento se evitó poder buscar alguna solución.
En versiones posteriores como Ms.Pac-man redujeron este problema mediante la técnica de reusar sprites verticalmente y por tanto los sprites sólo parpadean cuando coinciden dos o más fantasmas.
Simulando sprites independientes sin Flickering
Sin embargo, hay juegos que contaban con numerosos enemigos independientes y no tenían los molestos parpadeos del Comecocos, podemos comprobarlo en títulos como Berzerk o River Raid.
Si nos fijamos ocurría lo mismo que con Space Invaders, reusaban los sprites verticalmente pero sin que nunca coincidan horizontalmente. Realmente esto limita su capacidad de movimiento, ya que dependerá del resto de enemigos que estén pululando por la pantalla en ese momento.
En el caso del Berzerk es una diferencia frente al arcade original, que afecta a su mecánica de juego pero apenas llegas a notarlo mientras juegas. Sin embargo en otros juegos sí se habría notado mucho más. Por ejemplo esta decisión de diseño en Wizard of Wor no habría funcionado. Limitar aquí el comportamiento enemigo de esa forma habría hecho un juego demasiado fácil y aburrido. Decidieron entonces dejar la acción del original pero a costa de dejar ese contínuo baile de sprites que sufre el juego.
En Defender tampoco se impuso esta limitación, y por eso se producen parpadeos cuando coinciden enemigos horizontalmente. Mencionar aparte un fallo curioso y casi imperdonable, y es que al disparar desaparece nuestra nave. La consola no logra dibujar la nave y el disparo a la vez, así que si disparamos continuamente … es casi imposible que nos maten las balas enemigas!!
Seaquest de Activision, como en Space Invaders, es otro ejemplo de intentar simular mayor número de enemigos usando ambas técnicas. Coloca los enemigos en posiciones verticales distintas y los clona horizontalmente para simular que hay más enemigos. Esto dota de mayor acción al juego, pero resta la sensación en la independencia del movimiento de los enemigos, éstos sólo se mueven en horizontal y la única variedad consiste en que se desplacen desde la izquierda o desde la derecha. Por tanto tiene un patrón más mecánico que por ejemplo Berzerk, que sí lograba dar una sensación de que los enemigos tuvieran mayor independencia de movimiento.
Lo mismo ocurre con Cosmic Commuter, nuevamente de Activision, si tras la primera buena impresión de te acabas aburriendo enseguida, lo más seguro es que sea por el mismo motivo que Seaquest, y al compararlo con Defender de repente éste te parecerá más interesante aun con sus parpadeos.
Superando los límites de la Atari 2600.
Está claro que la calidad de un sistema se debe a susa juegos, y sobretodo gracias a los diseñadores y desarrolladores que lograron desafiar sus límites. Resulta increíble que se pudieran llegar a ver juegos como Pitfall, Robot Tank o Solaris en nuestra Atari VCS, superando con creces los límites de una consola que aspiraba como mucho a imitar lo que había disponible en los años 70.
Artículo muy interesante, últimamente no para de sorprenderme esta maquinita, entre algunos vídeos de juegos, las últimas demos y escritos como este. Con el talento suficiente se puede sacar oro de cualquier sistema por limitado que sea, y este es un buen ejemplo.
Por cierto, ¿tenéis Twitter?
Buenas Paco muchas gracias por el comentario!
Efectivamente la clave está en el talento, en Atari aprenderían la lección cuando sus mejores desarrolladores se largaron para fundar sus propias empresas …
En cuanto Twitter, de momento no, sólo tengo una cuenta personal en esa teletienda llamada Facebook (pásame tu nombre o contacto a info@retrolaser.es y te busco). En un futuro sí terminaré abriendo cuentas de Retrolaser.
Un saludo y gracias de nuevo.
Hay que decir que, mientras que se puede programar que un sprite se duplique o triplique en la misma línea gracias al registro NUSIZx, esto no serviría para este juego, ya que queremos que desaparezca un solo alien cuando le damos con el misil, no las tres copias clonadas.
El descubrimiento del programador Rick Maurer -el autor del juego- es más sorprendente. Resulta que mientras se está dibujando una línea de pantalla, si reinicias el registro HMOVE -especializado en cambiar las coordenadas horizontales de los sprites-, provocas que el chip TIA comience a dibujar de nuevo los sprites. De esa manera se podía ofrecer más sprites que los dos básicos, en cada línea de pantalla.
Esto está un poco más detallado en el libro «Racing the Beam. The Atari Video Computer System», de Nick Montfort e Ian Bogost, 2009, The MIT Press, página 73.
Buenas Joaquín, muchas gracias por el interés.
Independientemente del uso HMOVE, Space Invaders sí usa también clonado de sprites, tal como se puede observar en la triple captura del inicio del artículo, donde se muestra activando por separado P0 y P1, y que permite además su reposicionamiento variando la distancia entre ellos.
Por lo que sugieren en este enlace, parece que no es así:
https://retrocomputing.stackexchange.com/questions/7502/how-does-space-invaders-on-the-atari-2600-display-all-the-aliens
En este hilo mencionan que la técnica que indicas no se utilizó hasta Galaxian, que se lanzó en 1983:
«The Space Invader sprites are simply displayed using 3 copies of each of the two sprites. The RESPx trick was first shown in Galaxian three years later.»
Y dejo el extracto de lo que mencionan respecto a Space Invaders:
«El libro «Racing the beam» menciona lo siguiente en una sección sobre sprites:
«Rick Maurer, el programador del port de Space Invaders para VCS, descubrió que al activar HMOVE mientras se dibujaba una línea, los objetos se reposicionaban inmediatamente.»
Esto sugiere que esta técnica se usó en Space Invaders. Sin embargo, los únicos triggers de HMOVE que aparecen en el código de Space Invaders ocurren directamente después de un WSYNC, así que definitivamente no varias veces por scan line.
Los alienígenas se dibujan usando los sprites de dos jugadores. Tanto NUSIZ0 como NUSIZ1 están configurados en $06, lo que significa una resolución de un solo píxel y tres copias cada una con un espacio medio. Las copias de ambos sprites se entrelazan para formar una fila de seis en un patrón «A B A B A B». La apariencia de cada «copia» se cambia cargando diferentes patrones de sprites en los registros GRP0 y GRP1 mediante un código cuidadosamente cronometrado.»
Muy interesante. La de tardes que pasé con mi familia jugando al Combat y al Dodge´em. Y el Solaris -para la consola de la que se trata- era impresionante. 1.500 ptas que me costó en 1990 ^^.