Sur CPC, c’est le taux d’rafraîchissement (frame rate) qui le limite (en logiciel, la méthode la plus rapide que j’ai étudiée est celle d’Ocean, utilisée dans Batman : 2 pixels horizontalement, 2 lignes verticalement), et cela prend environ 2 images pour dessiner les tuiles. Les sprites et le gameplay s’ajoutent ensuite au temps processeur pour chaque mise à jour. Le défilement de Shinobi est similaire mais pas aussi rapide, Extreme est bon mais pas aussi rapide non plus, et d’autres jeux sont soit souvent plus lents, soit choisissent de réduire la zone pour essayer de maintenir un certain nombre d’IPS.
Les défilements logiciels semblent tous se faire octet par octet, et certains comme Golden Axe font même du défilement basé sur des caractères (caractères texte/motifs).
Celui d’Ocean couvre aussi souvent une plus grande partie de l’écran. La taille du panneau est d’ailleurs conçue pour limiter le temps de dessin des tuiles et tout faire tenir dans un intervalle de 2 images 
Je ne vais pas expliquer ici comment Ocean s’y prend parce que l’IA ne sait pas comment c’est fait et je ne veux pas gâcher le secret ; c’est du code humain très ingénieux (mais avec leur méthode, ils ne peuvent pas avoir un panneau dans un mode différent de la zone de jeu principale…). Et je parle bien ici de l’équipe interne d’Ocean, pas d’un studio tiers à qui ils auraient confié le travail.
Avec le défilement logiciel, on peut dessiner les sprites par-dessus les tuiles sans avoir à se soucier de restaurer l’arrière-plan derrière, contrairement à ce qu’impose le défilement matériel.
On dirait que cette version de Gryzor utilise le défilement matériel, mais à ce rythme, c’est beaucoup trop rapide pour le mouvement du sprite qui se fait pixel par pixel. Du coup, ça va forcément trembler ou, si l’on veut éviter cette saccade, il faut faire comme Ghosts 'n Goblins : quand on s’approche du bord, on fait défiler une grande section d’un coup pour minimiser la fréquence des sauts d’écran.
La réponse classique d’une IA, c’est de déplacer pixel par pixel comme ceci et de laisser trembler, en affirmant que c’est acceptable et que ça ne se voit presque pas, exactement comme ce qu’on a là… Sur MSX1 avec un défilement continu comme dans Salamander, oui ça passe parce que les sprites s’y prêtent bien, mais pas comme ça.
Avec un défilement logiciel, ça pourrait aussi sauter un peu parce que ça se fait souvent octet par octet horizontalement. On pourrait créer un défilement logiciel pixel par pixel, mais très peu de jeux le font et je suis sûr que ce ne serait pas rapide. (En fait, je n’ai pas encore essayé, c’est une chose à ajouter à ma liste de tests).
Avec le défilement matériel horizontal, le registre R3 du CRTC donne le même rythme que le logiciel (mais avec du scintillement sur les côtés), et ce n’est toujours pas assez fluide quand les sprites bougent pixel par pixel. On peut faire du pixel par pixel en matériel avec du double buffering (pour éviter le scintillement), mais il faut réduire la taille de l’écran pour faire tenir toutes les pages mémoire dans la mémoire principale — à moins de le faire exclusivement pour le Plus.
Pour Gryzor, ils ont donc choisi la meilleure solution à l’époque pour obtenir un nombre d’IPS raisonnable, un déplacement pixel par pixel et un jeu amusant.
(Oui, j’ai essayé plein de méthodes différentes pour le défilement, en logiciel comme en matériel. Si le déplacement du personnage se fait au rythme du défilement matériel (R3 compris), on n’a pas de sauts et le défilement peut être continu sans faire comme Ghosts 'n Goblins. Mais dès qu’on ralentit le personnage en dessous du rythme du défilement matériel, il faut faire des compromis, comme G&G).
