Buenas,

Entiendo que si consideras un malgasto mover la tabla de colores de sprites cada vez es porque los sprites que mostrarás no cambiarán de color, sólo el patrón y su posición. ¿Es así?
Se me ocurre que repitiendo dos veces los colores de los sprites en la tabla de colores, y luego cambiando en cada "frame" el plano donde muestras los sprites.
Como esta explicación no es demasiado clara , pongo un ejemplo (ejemplo extremo):

Imagina que quieres mostrar 16 sprites (será el máximo posible).
Primero rellenas la tabla de colores de sprites: rellenas los colores para los 16 primeros planos, y repite los mismos colores en los siguientes 16 planos.
El plano 0 y 16 utilizarán el mismo color (cuando digo color me refiero a poner los mismos 16 valores en la tabla de colores), el plano 1 y 17 los mismos, etc.


En el ejemplo he puesto que cada plano utiliza un color diferente, es sólo un ejemplo exagerado.
Ahora en cada frame del juego/animación cambias el plano en el que muestras cada sprite.
Cuando pongo -- es que no se muestra ningún sprite en ese plano, creo que se hace poniendo 216 en la posición Y.
(esto último lo digo de memoria, no recuerdo bien que valor hay que poner. En MSX1 para no mostrar el sprite se pone Y=209 pero en MSX2 es otro valor)

En el primer frame muestras los sprites en los 16 primeros planos:

En el siguiente frame muestras el primer sprites del frame anterior como el último:
(ahora el primer sprite pasa a ser el último aunque con el mismo color)

En el siguiente frame volvemos a repetir el procedimiento anterior:


Vamos repitiendo este procedimiento hasta que todos los sprites se muestran en los planos 16-31, entonces vuelves a empezar como en el frame1 utilizando los planos 0-15.

Este "procedimiento" tiene la limitación de poder utilizar sólo 16 planos de sprites como máximo.
Además de que estás muy "enconsertado" a la hora de repartir los sprites. Porque siempre deberás utilizar los mismos planos.
Por ejemplo: el prota siempre en el plano 0, el enemigo 1 en el plano 1, enemigo 2 en plano 2, etc.
Si por ejemplo matas al enemigo 3 ... ese plano tendrás que deshabilitarlo, y en el momento de rotar planos tendrás que saltarlo.

Ejemplo: imagina que esta es la configuración del frame actual.


El enemigo 3 está en el plano 3, y lo matán ... por tanto habría que "eliminarlo", por tanto lo deshabilitamos.
si en el siguiente frame el enemigo 3 sigue muerto, cuando rotemos tendríamos que saltarnos el plano 3 e ir a por el 4:


¿No se si me explico bien, o te he liado?

Por supuesto si utilizas menos sprites (por ejemplo 12) la estructura quedaría así (los planos 24-31 no los utilizarías):

Seguro que debe existir alguna manera más eficiente de hacer todo esto, además no creo que se corresponda perfectamente a lo que estás haciendo.
Pero espero que la explicación te pueda dar ideas para que encuentres una mejor solución que se adapte mejor a tu proyecto.

Saludos,

Veo que está complicado el tema. El problema es que mi juego es casi horizontal y ocurre a menudo que haya más de ocho sprites en linia. Intenté usar el vdp status#0 que indica el sprite "sobrante" (mi idea era no pintarlo en el siguiente frame) pero no sé porque no acabo de leer bien el sprite problematico.

Pues sería cuestión de saber como son tus sprites, es decir como son los 16 bytes de colores que usan cada uno ¿todos usan el mismo color?, ¿la mayoría usan un color?, ¿todos de color diferente?, ¿usas doble o triple sprite por monigote?

He estado pensando en una técnica que te serviría muy bien sin importar el tipo de juego. El asunto es como sigue:

1. Tienes DOS tablas de sprites y DOS tablas de colores en zonas diferentes de la VRAM.
2. En un frame llenas UNA tabla de sprites con los sprites en orden (0-31), y en el otro frame llenas la OTRA tabla de sprites con los sprites en orden inverso (31-0)
3. Lo mismo para las tablas de colores.
4. En cada frame switcheas entre ambas tablas de sprites y de colores (modificando los registros base)

De esta forma consigues hasta 16 sprites en línea.

Si te sirve de referencia, yo ahora mismo estoy volcado 10 patrones de sprites (320 bytes), atributos para 12/14 (48 bytes) y luego toda la tabla de nombres (768 bytes). En total unos 1200 bytes. Todo esto sin la BIOS, sino usando una versión adaptada de FLDIRVM de SapphiRe que anda por los snippets, creo.
La primera parte, la de los sprites, la hago sin NOPs. La segunda, la de la tabla de nombre, con NOPs. Y a 60Hz (que es el peor de los casos) todo esto acaba a medio frame.
Como en tu caso se trata de MSX2, creo que no hacen falta los NOPs (alguien que controle más del tema que me corrija si no es cierto). He probado a quitarlos y a 60Hz acaba cuando lleva 1/3 de frame.
Además, mis volcados no son directos y además hay fragmentos que no tengo optimizados. Vamos, que tengo algún cálculo que otro en medio de los volcados. Así que seguramente en un caso más cercano al ideal (por ejemplo, que la NAMTBL y la SPRATR se vuelquen tal cual de algún buffer en RAM) puedas rebajarlo un poco...

De todos modos, lo mejor es que pruebes. Mete el volcado de la NAMTBL dos veces (que serían más bytes de los que realmente quieres volcar) y, si eso no se te va de frame, cualquier cosa de menos bytes tampoco se te va a ir