Seis shooters de NES y el manual que demuestra que el parpadeo se elegía

El PPU de la NES dibuja ocho sprites por línea de barrido. El noveno no se dibuja: la wiki de NESdev lo escribe sin adornos —el chip «elige los primeros ocho que encuentra»— y de ahí sale el parpadeo que cualquiera recuerda de un shooter con la pantalla llena. Ese número no se negocia. Todo lo demás sí. Tres de los seis juegos de esta lista corren sobre el mismo mapper, con los mismos 128 KB de programa y los mismos 8 KB de gráficos, y se comportan de tres maneras distintas. Uno trae la decisión impresa en el manual de la caja.

El criterio, antes del primer juego

Entra el shooter cuyo comportamiento técnico se puede comprobar contra una pieza física: la placa del cartucho, el chip que lleva soldado, el manual. No entra el «se siente lento», que no se mide. La vara es dura a propósito, porque la frase que esta lista somete a prueba —«es difícil por el hardware»— casi nunca viene acompañada de un número. El detalle de cómo se dibuja un personaje en esta máquina está en nuestra pieza sobre el palette swap.

La vara se cobra a su primera víctima antes del primer elemento, y es el candidato obvio. Silver Surfer (Software Creations para Arcadia, noviembre de 1990) encabeza toda lista de juegos imposibles de NES: se muere de un toque, incluido el roce con el decorado. Pero su cartucho es un NES-TSROM con MMC3: mapper 4, 128 KB de programa, 256 KB de gráficos y 8 KB de RAM extra. Es el mejor hardware de los siete títulos de este texto, cuatro veces los gráficos de cualquier otro, y es el más difícil. Su dificultad vive en la caja de colisión y en el contador de vidas, no en el PPU. Queda fuera porque no hay nada que separar.

El orden no es cronológico ni por dificultad. Van de la coartada más sólida a la más floja: primero el juego donde el hardware explica de verdad lo que pasa, al final aquel donde la decisión aparece escrita, en inglés, en el manual.

Seis juegos, de la coartada más sólida a la más floja

1. 1942 (Capcom, noviembre de 1986). Está porque es el único de la lista donde «el hardware» es casi literal. El cartucho estadounidense es un NES-NROM-256: iNES mapper 0, sin conmutación de bancos de ninguna clase, 32 KB de programa y 8 KB de gráficos. Cuarenta kilobytes en total para un juego de salón. La base de BootGod añade un dato que la portada no lleva: el port está acreditado a Micronics/Khaos, un estudio externo. Y aquí llega lo que descoloca. Sobre la placa más pobre que existía, el parpadeo y la ralentización son —según la reseña de Classic-Games.net— mínimos. El port no pagó su presupuesto en cuadros perdidos: lo pagó en música, que fuera de una fanfarria de fin de fase sencillamente no está. El presupuesto se gastó igual. Lo que cambió fue en qué.
2. Gradius (Konami, diciembre de 1986). Está porque los dos efectos tiran en direcciones opuestas dentro del mismo juego. El cartucho es un NES-CNROM, mapper 3: 32 KB de programa y 32 KB de gráficos, sin un solo banco de programa que conmutar. Konami metió un Gradius entero ahí, poco más de un año antes de firmar el Contra de NES. El parpadeo quita información —un proyectil que no se dibuja es un proyectil que no se esquiva— y por tanto sube la dificultad. La ralentización hace lo contrario. Aparece, según se explica en el foro de NESdev, cuando el motor no termina el cuadro a tiempo y la consola repite el anterior; en la fase cinco, con más de un tentáculo en pantalla, el juego se arrastra, y el jugador que documentó su partida a un crédito en 1CC Log lo apunta como ventaja, porque da tiempo a esquivarlos. Mismo chip, misma fase, dos consecuencias contrarias que no se pueden sumar.
3. Life Force (Konami, agosto de 1988). Está por la placa. Konami fabricó la suya, la 351258, con su propio logo estampado, y aun así la base de datos la clasifica como KONAMI-UNROM: iNES mapper 2, 128 KB de programa y 8 KB de RAM de caracteres. Sin conmutación de gráficos y sin interrupción por línea de barrido. Es el mismo mapper que llevaba Ikari Warriors. Con eso Konami sacó un Salamander que se arrastra en las fases verticales y contra los jefes, y que quienes lo terminan de una sentada describen como bastante más benigno que el mueble original. La ralentización no lo estropeó: lo hizo alcanzable. Aviso de región, que aquí importa: hubo edición europea y edición española, ambas PAL-B, a 50 Hz sobre una CPU de 1,662 MHz en lugar de 1,789. En esas máquinas todo va todavía más despacio.
4. Ikari Warriors (SNK, mayo de 1987). Está porque aquí el hardware ya es coartada, y la placa lo demuestra. El cartucho estadounidense es un NES-UN-ROM: mapper 2, 128 KB de programa, 8 KB de RAM de caracteres. El mismo board NES-UN-ROM que Zanac, en revisiones contiguas. Sobre él, el port corre a un cuadro de juego por cada cuatro de pantalla —quince por segundo— según el desmenuzado de Set Side B, que además señala rutinas de multiplicación donde bastaba una tabla de consulta. La ficha de BootGod acredita ese port a Micronics/Khaos; la caja sólo dice SNK. La edición europea llegó el 10 de agosto de 1989, dos años más tarde, en PAL-B: si conserva ese uno de cada cuatro, allí son doce y medio. La consola no impuso nada de esto. Alguien escribió ese código.
5. Zanac (Compile, octubre de 1987). Está porque es la contraprueba, y corre sobre la placa del juego anterior: NES-UN-ROM, mapper 2, 128 KB de programa, 8 KB de RAM de caracteres. Compile lo programó, y el cartucho estadounidense acredita como editor a FCI, no a Pony Canyon, que es lo que suele repetirse. Sobre ese hardware idéntico, Zanac llena la pantalla y aguanta. Y remata: pone la dificultad donde se puede leer. Su ALC —el «Automatic Level Control» que ya aparecía en la versión de MSX, con su indicador en hexadecimal en pantalla— mide cómo juegas y ajusta la agresividad de los enemigos. Hardcore Gaming 101 lo sitúa entre los primeros conceptos de rank. Si un juego de 1987 sabía subirte la dificultad a propósito, atribuírsela al PPU es una comodidad.
6. Gun-Nac (Compile, septiembre de 1991). Está porque cierra la discusión con un documento. Su menú de opciones se llama CONFIG.SYS y la quinta entrada, según el manual estadounidense, dice: «To prevent the characters from flickering while playing the game, you may choose SPRITE HAS PRIORITY; however, this may slow down the normal speed of characters on the screen». Es decir: para que no parpadeen, elige prioridad de sprite; a cambio, todo puede ir más despacio. Compile no sólo sabía que el parpadeo y la ralentización son las dos caras del mismo presupuesto: le entregó la decisión al jugador y la imprimió. El cartucho es un NES-TLROM con MMC3, mapper 4, y su editor estadounidense figura como Nexoft, no ASCII, que es la atribución que circula.

Lo que el número sí demuestra

Los ocho sprites por línea no se discuten: viven en el PPU, que está dentro de la consola y no dentro del cartucho, así que ningún mapper los toca. El MMC3 conmuta bancos de gráficos y cuenta líneas de barrido; no dibuja un noveno sprite. Lo que cambia de un juego a otro es qué se hace con ese tope. En el foro de NESdev, el desarrollador que firma como tepples lo cuenta al revés de como lo cuenta la prensa: hay juegos que hacen parpadear todo a propósito para meter el doble en pantalla, y rotar el orden del OAM en cada cuadro convierte una desaparición fija en un parpadeo repartido. Ahí el parpadeo no es la avería. Es la solución.

Queda un cabo suelto que conviene decir: nada de esto son declaraciones de los programadores. Son placas, manuales y cuadros contados. Ningún estudio de los seis explicó su decisión, salvo Compile, en un manual de instrucciones. La generación siguiente movió el problema de sitio con otros trucos —el modo 7 es el más recordado—, pero el tope de ocho seguía siendo ocho, y seguía sin ser el culpable.