Sul CPC sarebbe il frame rate a fare da limite (se parliamo di via software, il metodo più veloce che ho analizzato è quello di Ocean usato in Batman, 2 pixel in orizzontale, 2 righe in verticale), e ci vogliono circa 2 frame per disegnare le tile. Sprite e gameplay vanno poi ad aggiungersi al tempo CPU per ogni aggiornamento. Lo scroll di Shinobi è simile ma non così veloce, Extreme è buono ma anche questo non è veloce uguale, mentre altri giochi spesso sono più lenti e/o scelgono di ridurre l’area per cercare di mantenere un minimo di fps.
Gli scroll via software sembrano fare tutti byte per byte e alcuni, come Golden Axe, usano persino uno scroll basato sui caratteri.
Quello di Ocean spesso copre anche una porzione maggiore di schermo. La dimensione del riquadro è pensata proprio per limitare il tempo di rendering delle tile e farlo rientrare in 2 frame 
Non spiegherò qui come fa Ocean perché l’IA non sa come sia stato realizzato e non voglio regalarlo in giro; si tratta di codice umano davvero intelligente (ma per via del modo in cui lo fanno, non possono avere un riquadro in una modalità grafica diversa rispetto all’area di gioco principale…). Con questo mi riferisco al team interno di Ocean, non a uno studio terzo a cui hanno appaltato il lavoro.
Con lo scroll via software puoi disegnare gli sprite sopra le tile e non devi preoccuparti di ripristinare lo sfondo sottostante, come invece serve fare con lo scroll hardware.
Sembra che questa versione di Gryzor usi lo scroll hardware, ma a quella velocità è decisamente troppo rapido per il movimento degli sprite che avviene pixel per pixel, quindi ci sarà sempre dell’oscillazione; oppure, se vuoi evitare quel tipo di effetto, puoi fare come Ghosts and Goblins: quando ti avvicini al bordo, fai scorrere un’ampia sezione per ridurre al minimo la frequenza dei salti della schermata.
La risposta classica dell’IA è: «muovi pixel per pixel in questo modo e lascia pure che oscilli, è accettabile e non si nota», proprio come vediamo qui… Su MSX1 e con uno scroll continuo come in Salamander sì, ci può stare perché gli sprite si integrano bene, ma non in questo modo.
Anche con lo scroll software ci potrebbe essere qualche piccolo scatto, perché spesso lavora byte per byte in orizzontale. Si potrebbe realizzare uno scroll software pixel per pixel, ma pochissimi giochi lo fanno e sono sicuro che non sarebbe veloce. (A dire il vero non ci ho ancora provato, è una cosa da aggiungere alla mia lista di esperimenti).
Con lo scroll hardware orizzontale, il registro CRTC R3 ti dà la stessa velocità del software (ma a quel punto ti ritrovi con il sfarfallamento ai lati), e comunque non è abbastanza fluido quando gli sprite si muovono pixel per pixel; potresti fare pixel per pixel via hardware e con il double buffering (per evitare il flickering), ma dovresti ridurre la dimensione dello schermo per far rientrare tutte le schermate nella memoria principale — a meno che non lo sviluppi solo per il Plus.
Quindi per Gryzor all’epoca hanno scelto la soluzione migliore per ottenere un fps ragionevole, un movimento pixel per pixel e un gioco divertente.
(Sì, ho provato un sacco di metodi diversi per lo scrolling, sia software che hardware. Se il movimento del personaggio segue la velocità dello scroll hardware — incluso R3 — allora non hai scatti e lo scroll può essere continuo e non a scatti come Ghosts and Goblins; ma non appena rallenti il personaggio al di sotto della velocità dello scroll hardware, devi scendere a compromessi proprio come fa G&G).
