Beim CPC ist es die Frame-Rate, die dem Ganzen Grenzen setzt (bei Software ist die schnellste Methode, die ich untersucht habe, die von Ocean, wie sie in Batman verwendet wird: 2 Pixel horizontal, 2 Zeilen vertikal), und das Zeichnen der Tiles dauert etwa 2 Frames. Sprites und Gameplay erhöhen dann die CPU-Zeit für ein Update zusätzlich. Der Scroll von Shinobi ist ähnlich, aber nicht so schnell; Extreme ist gut, aber ebenfalls nicht so schnell, und andere Spiele sind entweder meist langsamer und/oder verkleinern den Bildschirmausschnitt, um zu versuchen, eine gewisse FPS-Zahl zu halten.
Software-Scrolls scheinen alle Byte für Byte vorzugehen, und einige – wie Golden Axe – nutzen sogar zeichenbasiertes Scrolling.
Die Lösung von Ocean deckt oft auch mehr Bildschirmfläche ab. Die Größe des Statusfelds ist ebenfalls so gewählt, dass die Zeit zum Zeichnen der Tiles begrenzt wird und alles in 2 Frames passt 
Ich werde hier nicht erklären, wie Ocean das macht, weil die KI nicht weiß, wie es geht, und ich es nicht verraten will. Es ist cleverer menschlicher Code (aber durch ihre Methode können sie kein Statusfeld in einem anderen Modus als den Hauptspielbereich haben…). Damit meine ich Oceans eigenes Team, nicht eines, das sie als Drittanbieter beauftragt haben.
Bei Software-Scrolls kann man Sprites über die Tiles zeichnen und muss sich keine Gedanken darüber machen, den Hintergrund dahinter wiederherzustellen, wie man es bei Hardware-Scrolls tun muss.
Es sieht so aus, als würde diese Version von Gryzor Hardware-Scrolling nutzen, aber bei diesem Tempo ist es viel zu schnell für die Sprite-Bewegung, die Pixel für Pixel erfolgt. Daher wird es immer ruckeln. Wenn man dieses Ruckeln vermeiden will, macht man es wie Ghosts 'n Goblins: Wenn man sich dem Rand nähert, scrollt man einen großen Abschnitt auf einmal, um zu minimieren, wie oft der Bildschirm springt.
Die klassische KI-Antwort lautet: Beweg dich Pixel für Pixel wie hier und lass es ruckeln, das sei akzeptabel und kaum wahrnehmbar – genau wie wir es hier sehen… Auf dem MSX1 und bei kontinuierlichem Scrollen wie in Salamander ist das zwar völlig in Ordnung, weil die Sprites gut damit harmonieren, aber nicht auf diese Weise.
Bei Software-Scrolling könnte es ebenfalls ein wenig springen, da es horizontal oft Byte für Byte geht. Man könnte einen Software-Scroll Pixel für Pixel bauen, aber nur sehr wenige Spiele machen das, und ich bin mir sicher, dass es nicht schnell wäre. (Eigentlich habe ich das noch nicht ausprobiert – das kommt auf meine Liste der Dinge, die ich testen möchte).
Beim horizontalen Hardware-Scrolling liefert das CRTC-Register R3 dieselbe Rate wie Software (aber dann hat man Flackern an den Seiten), und das ist immer noch nicht flüssig genug, wenn sich Sprites Pixel für Pixel bewegen. Man kann Hardware-Scrolling zwar Pixel für Pixel und mit Double Buffering (um Flackern zu vermeiden) umsetzen, aber dafür muss man die Bildschirmgröße reduzieren, damit alle Bildschirme in den Hauptspeicher passen – es sei denn, man entwickelt exklusiv für den Plus.
Bei Gryzor haben sie sich damals also für die beste Option entschieden, um eine passable FPS-Zahl, pixelgenaue Bewegung und ein spielenswertes Spiel zu erreichen.
(Ja, ich habe viele verschiedene Scrolling-Methoden ausprobiert, sowohl per Software als auch per Hardware. Wenn die Bewegung der Figur der Hardware-Scrolling-Rate entspricht [inklusive R3], gibt es keine Sprünge und der Scroll verläuft kontinuierlich und nicht wie bei Ghosts 'n Goblins. Sobald man die Figur jedoch langsamer als die Hardware-Scrolling-Rate macht, muss man Kompromisse eingehen, genau wie G&G es tut).
