En el Green Beret lo que soliamos hacer era saltar desde lo alto de alguna estructura y mantener presionada la tecla 1, que congelaba al personaje en ese lugar hasta que se soltara la tecla, era muy util para tomarse una pausa para pensar como seguir. Funcionaba en cualquier parte, pero era util hacerlo en una posicion donde no nos alcanzaran enemigos o balas.
No se si ese truco existe en el original, porque por aqui todo lo que se recibia era pirata, y por lo general estaba crackeado.

Te confirmo que ese bug estaba presente en el cassette original. Yo lo descubrí de casualidad y lo utilizaba estratégicamente. Por ejemplo, cuando al final de la fase 2 te atacan los perros, si saltas y pulsas 1 en lo más alto, te detienes en el aire y pasan todos por debajo

Muy bueno!

Alguno rápido:

- En el The Last Ninja, cuando pasas a un enemigo con espada y vas a irte de la pantalla, se hace el harakiri (me encanta).
- En el Barbarian, pulsando unas teclas salían un mensaje "why did you press me?"
- En el Army Moves, en la memoria del juego debe haber un texto del programador donde incluso pone su tfno o algo así  para que le llamen chicas

Los 144 sprites me imagino que es la parte de las letras en toda la pantalla, tremendo.

Los 9 sprites en linea no me doy cuenta en que parte, estas intros hacen tantas cosas increibles que 1 sprite más ni me doy cuenta.

Wow! Esto no lo conocía!

Por lo que leo, se puede hacer el truco con el sprite 0 y sólo en una de cada dos rasterlines. Es el "3" de las letras de abajo

Es muy complejo pero efectivamente garantiza ausencia total de flicker. Podéis comprobar lo mismo en Double Dragon 3 o Altered Beast.

En el Green Beret, que usa un multiplexer "clásico" pero muy efectivo, prácticamente no hay glitches. Pero si os fijáis, cuando disparas el lanzallamas o hay balas y varios enemigos a la vez (muchos sprites a la misma altura) entonces si se nota.

Están rippeadas directamente de la memoria del juego

Creo que la confusión es por un detalle importante que se me ha olvidado. Si cambias la posición Y de un sprite mientras se está pintando, ésto no tiene efecto hasta que se ha pintado entero. Pero sí se puede cambiar el "frame" del sprite a mitad.

Si te fijas es coherente con mi "intento de explicación":

El sprite A son las orejas de Usagi.

El sprite A/C tiene la mitad inferior igual que el A, y la mitad superior es "nueva".

Imagina que cuando se ha pintado la mitad del sprite A, cambio al frame A/C y actualizo su posición 21 pixels para abajo. El raster sigue pintando el sprite (faltan 10 líneas de la posición Y original) y durante 10 líneas pinta los datos de A/C, que son lo mismo (esas líneas son iguales que A).

Cuando ya se ha pintado el primer sprite (21 líneas mezcla entre A y A/C) el VIC pinta de nuevo el sprite en su nueva posición Y que es justo la siguiente línea. Durante las 10 primeras líneas, pinta el frame actual (A/C) que tiene la mitad de la cabeza de Usagi.

¿Me sigues?

Añado imágenes que espero valgan más que 1000 palabras!

A mi me lo explicó una persona que lo desensambló.. pero creo que no se trata exactamente de cronometrar con los timers de las CIAs sino de generar interrupciones con dichos timers (en un momento determinado). La multiplexación de sprites se sigue haciendo mediante interrupciones pero en vez de éstas ser generadas por el VIC (raster) son generadas por los timers de las CIAs.

Desconozco que ventajas o inconvenientes puede tener este sistema, así a priori y sin conocerlo me parece más cómodo manejar interrupciones raster.

He visto un post antiguo que menciona este asunto. He visto que se quedó este tema en el tintero y creo que puedo arrojar algo de luz

La dificultad para multiplexar sprites en este tipo de juegos es que todos los sprites se concentran en "filas" contiguas. El esquema clásico de ordenarlos en el eje Y e ir asignando interrupciones de raster no funciona bien porque al estar muchos contiguos (sprite de torso -> sprite de piernas) la transición es demasiado abrupta y se produce flicker o incluso se pierden sprites. Aún así es posible hacerlo (Double Dragon 3 es el mejor ejemplo) con el truco que os voy a explicar, y añadiendo más lógica a la rutina IRQ de raster. Básicamente, cuando actualizas un sprite para multiplexarlo, tienes que comprobar si existen N sprites más en una altura similar y procesarlos de golpe.

En el caso de Usagi Yojimbo, la idea de los timers es confusa al principio pero si lo pensáis es bastante ingeniosa. Existen 4 personajes en pantalla, que tienen dos sprites de ancho y 3 de alto (6 en total). Cada personaje tiene su timer, que se programa para avisar del momento en el que hay que actuailizar la posición Y del sprite. Es totalmente equivalente a lo que se suele hacer con Raster, pero al ser 4 fuentes independientes de interrupción, no hay que preocuparse de la relación entre ellas. Es decir, cada timer actualiza a su personaje en función de su posición Y en pantalla, sin importarle de en qué posición estén los otros 3. Con interrupciones de raster como os comentaba antes, se hace mucho más lío.

Sin embargo la técnica anterior no soluciona el tema de las transiciones rápidas (la problemática es igual). Pero otra cosa grandiosa de este juego (copiado en Altered Beast y Double Dragon 3) es la "copia on the fly de sprites intermedios". Imaginad que el personaje de Usagi está compuesto por los siguientes sprites:

AB
CD
EF

Queremos asignar el Sprite hardware 0 a la columna ACE, y el 1 a la columna BDF. Para simplificar nos centramos en la parte izquierda (ACE). Tenemos que pintar el sprite 0 en la posición A, y luego actualizar su posición 21 pixels para abajo y actualizarlo a C. Luego repetir lo mismo de C a E. Para evitar la problemática de la transición tan abrupta, hace lo siguiente:

- Los sprites no están directamente alojados en el banco del VIC sino que se almacenan (por cierto, comprimidos) en otra zona de memoria. Para pintar A,C,E habría que copiar dichos sprites al banco gráfico (copiar 3*63 bytes). En el caso de Usagi, además hay que descomprimirlos... Todo ello en tiempo real, creo que a 25 fps.

- En lugar de copiar los 3 sprites A,C,E "a pelo", lo que se hace es copiar 5 sprites. 2 de ellos son transiciones generadas "on the fly" que tienen la mitad superior (10 filas) del sprite superior, y 11 filas del inferior:

A
A/C
C
C/E
E












El timer no programa 3, sino 5 interrupciones para actualizar el sprite: A->A/C->C->C/E->E

¿Qué se consigue con ésto? Cuando llegan las transiciones de un sprite a otro, al estar los personajes casi todos a la misma altura se acumulan las IRQ. TEned en cuenta que son 2 sprites por personaje y 4 timers. Perfectamente puede ocurrir que tengas que actualizar los 8 sprites a la misma altura, y que cuando vayas por el 5 el raster que pinta la pantalla ya esté bastante por debajo de la zona de transición.

Al habilitar estas transiciones, se da un margen de 10 líneas para cambiar el sprite de valor. Cuando el raster pasa de pintar A a A/C, te puedes adelantar y cambiarlo mucho antes de la transición porque el contenido de las 10 últimas filas de ambos es igual.

De este modo se puede "apilar" varias veces un mismo sprite en el eje Y sin tener el más mínimo glitch ni flicker. Por supuesto, la contrapartida es CPU (copia de sprites en tiempo real) y memoria adicional para almacenar las transiciones.

Este mismo esquema se usa en DD3 pero sin compresión.  Fijaros que al hacer copia "on the fly", solo hace falta definir los sprites en una dirección X. Si el personaje se da la vuelta, al copiar se invierten los bytes en tiempo real. De este modo ahorras mucho espacio para tener más frames.