Eso de usar emuladores esta muy bien para el desarrollo, es mas facil usar el PC, pero a veces ocurre que no todo lo que pensamos que funciona lo hace en el casharo de verdad, y se nos queda la cara como al tio del sombrero de ahi al lado.

En una serie de emails con el amigo Dioniso sobre interrupciones, splits y otras ___ mentales, programe esto que os adjunto (espro que sepais lo que estais viendo ). Solo funciona a 50 hz y en emuladores (que yo sepa y se debe a que la colision de sprites o la regla de 5º sprite se detectan con algo de aletoriedad.. Hay por ahí un monton de ejemplos, que os animo a subir. Habría que ver como se comporta el OCM con estas cosillas.

Son sprites, no? vamos .. movimiento pixel a pixel y superpuesto al background .. pero .. algo turbio encierra esa visión!

Pues imagina que con código sincronizado con el barrido, al final de cada scan (más o menos ) cambias los atributos de un sprite X,Y y color. El resultado es ¡el super sprite!.....o el Amiga sprite.

Esto me recuerda lo extraño que siempre me ha parecido la generación de los sprites en el TMS9918, en la mayor parte de los chips gráficos de la época las restricciones de tamaño en los sprites eran siempre horizontales, nunca verticales. La altura era teóricamente indefinida. Supongo que en el TMS las restricciones que imponía una memoria de video específica obligaba a limitarlos de alguna manera.

El secretillo no es tan facil de revelar , ahi solo se ve el resultado.

@JL casi lo clavas, sprites en movimiento, variando y,x y color, sincronizado con el retrazado, pero date cuenta de 2 detalles que lo hacen un poquitin complicado: son 3 sprites sincronizados (seguramente se podría hacer con uno solo incrementando Y, para estirarlo verticalmente y seria mas facil) y si mueves pxp un sprite a 50hz inmaginate la velocidad!