Quelques petits trucs mais j'ai pas de recette magique, je dirai veiller à bien aligner tes données sur les pages de 256 octets , entrelacer tes octets de pixels et de masque , travailler sur des sprites plus petits de taille fixe histoire d'optimiser au max tes routines, tu peux même songer à entrelacer tes données sauvegardées et tes données à afficher ensemble histoire de faire ta sauvegarde et ton affichage dans la même passe.Dans le genre captain obvious , je dirai avoir 2 sprites (en mode 0) décalés pour le mouvement d'un pixel.
Un truc qui peut te faire gagner est d'avoir tes données en zig zag pour éviter de recalculer l'adresse de ton sprite à chaque ligne.
Genre au lieu de faire

0-1-2-3
4-5-6-7

et devoir revenir en arrière à chaque ligne , stocker :

0-1-2-3
7-6-5-4

ça t'éviter de recalculer ton retour à la ligne à l'écran (et du coup de n'avoir qu'à t'occuper que des bits qui changent).Enfin , tout ça ça vaut si tu n'a pas de clipping à gérer.
Un truc qui est pas mal aussi est de dérouler ta routine pour savoir quand tu aura un saut de ligne de caractère et de brancher ta routine en fonction de la position du sprite.Après ça ne vaut que pour les sprites de taille fixe et de préférence sans clipping car évidemment là faut prévoir plusieurs routines.

Enfin , voilà quelques pistes de réflexion que j'ai déjà explorées mais il doit y avoir encore d'autres méthodes, bon brainstorming

_________________
"NOP" tel est le programme parfait ! court, rapide, lisible et sans bugs (connus)

pas con le coup du zig zag, merci pour ces precieux conseils !

bon, j'ai appris pas mal niveau optimisation Là ça commence à être pas mal, je vous soumettrai mon code
pour analyse par les pros

Est-ce qu'il y a un bon tuto pour gérer les animations avec le double buffering (page 0 en 0x8000 et page 1 en 0xc000 par exemple) ?

en fait, c'est simple comme tuto :

frame 1 :
affichage page 1 en &c000 (par exemple) avec des outs au CRTC
écriture de la nouvelle animation du sprite en page 2 en &8000
frame 2 :
affichage page 2 en &8000 avec des outs au CRTC
écriture de la nouvelle animation du sprite en page 1 en &c000
etc...

merci, c'est ce que j'ai implémenté. Ca m'a permis d'avoir des sprites sans avoir à me
soucier du retour de balayage.

Pour les routines de sprites, j'utilise maintenant la pile pour les adresses écran.
C'est plus optimal, mais ca nécessite de couper temporairement les interruptions.

Du coup, lorsqu'il y a trop de sprites à l'écran (environ 8 sprites de 8 pixels/32 lignes),
c'est fluide, mais ca fait déconner ma rupture d'écran (les 8 premières lignes sont
en mode 1, le reste en mode 0).

Si tu as une idée je suis preneur. Sinon, je vais me rabattre sur un seul mode, tant pis

pour améliorer la partie pile, avant de te répondre, j'aurai besoin d'avoir un complément d'info :

la pile récupère l'adresse écran où placer le sprite ou toutes les adresses de changement de ligne pour afficher le sprite (ou autre) ?

dans l'idée, ma table contient l'adresse de chaque ligne de l'écran.
Je fais pointer la pile sur l'adresse de la première ligne. Ensuite,
dans l'idée ca ressemble à quelque chose comme ça,

pop de
ld a,e
add #00
ld e,a
...
ld a,(hl)
ld (de),a

où la valeur ajoutée à E est patchée en dehors de la boucle pour éviter d'utiliser un
registre juste pour X.