En la CPC, la tasa de fotogramas sería lo que la limite (si es por software, la más rápida que he investigado es el método de Ocean utilizado en Batman: 2 píxeles horizontalmente y 2 líneas verticalmente), y eso tarda unos 2 fotogramas en dibujar las casillas (tiles). Los sprites y la jugabilidad añaden tiempo de CPU para cada actualización. El scroll de Shinobi es similar pero no tan rápido; Extreme es bueno pero tampoco tan rápido, y otros juegos suelen ser más lentos y/o eligen reducir la superficie para intentar mantener los FPS.
Los scrolls por software parecen hacerse todos byte por byte y algunos, como Golden Axe, incluso hacen un scroll basado en caracteres.
El de Ocean a menudo abarca más pantalla. El tamaño del panel también es el que es para limitar el tiempo de dibujado de las casillas y hacer que quepa dentro de 2 fotogramas 
No voy a explicar aquí cómo lo hace Ocean porque la IA no sabe cómo se hace y no lo voy a revelar; es código humano ingenioso (aunque con la forma en que lo hacen no pueden tener un panel en un modo diferente al del área principal del juego…). Me refiero al propio equipo de Ocean, no a uno de terceros que contrataran.
Con el software puedes dibujar sprites sobre las casillas y no tienes que preocuparte por restaurar el fondo como sí ocurre con el scroll por hardware.
Parece que esta versión de Gryzor está usando scroll por hardware, pero a esa velocidad es demasiado rápido para el movimiento del sprite, que es píxel por píxel, así que siempre va a dar tirones/oscilar. Si no quieres que oscile así, puedes hacer como Ghosts and Goblins: cuando te acercas al lateral, hace un scroll de una sección grande para minimizar la frecuencia con la que la pantalla da saltos.
La respuesta clásica de la IA es «mueve píxel por píxel así y deja que oscile», y dice que es aceptable y no se nota, justo como tenemos aquí… En MSX1 y con scroll continuo como en Salamander, sí, está bien porque los sprites funcionan bien así, pero no de esta manera.
Con el scroll por software también podría dar pequeños saltos, porque a menudo es byte por byte en horizontal. Podrías hacer un scroll por software píxel por píxel, pero muy pocos juegos hacen eso y estoy seguro de que no sería rápido (la verdad es que no lo he intentado todavía, me lo aponto en la lista de cosas por probar).
Con el scroll horizontal por hardware, el registro R3 del CRTC te da la misma velocidad que por software (pero ahora tienes parpadeo en los laterales), y eso sigue sin ser lo suficientemente fluido cuando los sprites se mueven píxel por píxel. Puedes hacerlo píxel por píxel por hardware y con doble búfer (para evitar el parpadeo), pero necesitas reducir el tamaño de la pantalla para que quepan todas las pantallas en la memoria principal… a menos que lo hagas solo para la gama Plus.
Así que con Gryzor eligieron la mejor opción de la época para conseguir unos FPS razonables, movimiento píxel por píxel y un juego divertido.
(Sí, he probado muchísimas formas distintas de hacer scroll, tanto por software como por hardware. Si el movimiento del personaje va a la velocidad del scroll por hardware —incluido el R3—, no hay saltos y el scroll puede ser continuo sin ser como el de Ghosts and Goblins; pero en cuanto frena el personaje a una velocidad inferior a la del scroll por hardware, no queda otra que asumir sacrificios como hace el G&G).
