Στον CPC ο ρυθμός ανανέωσης πλαισίων (frame rate) είναι αυτός που βάζει το όριο (στην περίπτωση του software scroll, ο ταχύτερος τρόπος που έχω ερευνήσει είναι η μέθοδος της Ocean όπως χρησιμοποιήθηκε στο Batman, 2 εικονοστοιχεία οριζόντια, 2 γραμμές κατακόρυφα), και αυτό απαιτεί περίπου 2 frames για τη σχεδίαση των tiles. Στη συνέχεια, τα sprites και το gameplay προστίθενται στον χρόνο επεξεργαστή για κάθε ενημέρωση. Το scroll στο Shinobi είναι παρόμοιο αλλά όχι τόσο γρήγορο, το Extreme είναι καλό αλλά επίσης όχι τόσο γρήγορο, ενώ άλλα παιχνίδια είναι είτε συχνά πιο αργά είτε/και επιλέγουν να μειώσουν την περιοχή σχεδίασης για να διατηρήσουν κάποια fps.
Τα software scrolls φαίνεται να γίνονται όλα byte προς byte και ορισμένα, όπως το Golden Axe, κάνουν ακόμα και scroll βασισμένο σε χαρακτήρες (char based scroll).
Η μέθοδος της Ocean καλύπτει συχνά και μεγαλύτερο μέρος της οθόνης. Το μέγεθος του πίνακα (panel) είναι επίσης τέτοιο ώστε να περιορίζεται ο χρόνος σχεδίασης των tiles και να χωράει μέσα σε 2 frames 
Δεν πρόκειται να εξηγήσω εδώ πώς το κάνει η Ocean, επειδή η Τεχνητή Νοημοσύνη (AI) δεν γνωρίζει πώς γίνεται και δεν θέλω να το αποκαλύψω· πρόκειται για έξυπνο ανθρώπινο κώδικα (αλλά με τον τρόπο που το κάνουν, δεν μπορούν να έχουν έναν πίνακα σε διαφορετικό mode από την κύρια περιοχή του παιχνιδιού…). Και όταν λέω Ocean, εννοώ την εσωτερική ομάδα της Ocean, όχι κάποια τρίτη εταιρεία στην οποία ανέθεσαν το έργο.
Με το software scroll μπορείς να σχεδιάσεις sprites πάνω από τα tiles και δεν χρειάζεται να ανησυχείς για την επαναφορά του υποβάθρου (background) από πίσω, όπως πρέπει να κάνεις με το hardware scroll.
Φαίνεται ότι αυτή η έκδοση του Gryzor χρησιμοποιεί hardware scrolling, αλλά με αυτόν τον ρυθμό είναι πάρα πολύ γρήγορο για την κίνηση των sprites, η οποία γίνεται pixel προς pixel. Επομένως, πάντα θα υπάρχει τρέμουλο (wobble) — ή, αν δεν θέλεις να τρέμει έτσι, κάνεις αυτό που κάνει το Ghosts and Goblins: καθώς πλησιάζεις στην άκρη, κάνεις scroll σε ένα μεγάλο τμήμα για να ελαχιστοποιήσεις τη συχνότητα που «πηδάει» η οθόνη.
Η κλασική απάντηση από το AI είναι «μετακινήσου pixel προς pixel έτσι και άφησέ το να τρέμει», λέγοντας ότι είναι αποδεκτό και δεν φαίνεται, όπως ακριβώς έχουμε κι εδώ… Στον MSX1 και σε συνεχές scroll όπως στο Salamander, ναι, είναι εντάξει επειδή τα sprites συνεργάζονται καλά με αυτό, αλλά όχι έτσι.
Με το software scroll μπορεί επίσης να κάνει μικρά «πηδήματα», επειδή συχνά γίνεται byte προς byte οριζόντια. Θα μπορούσες να φτιάξεις ένα software scroll pixel προς pixel, αλλά ελάχιστα παιχνίδια το κάνουν αυτό και είμαι σίγουρος ότι δεν θα είναι γρήγορο. (Για την ακρίβεια, δεν το έχω δοκιμάσει ακόμα, είναι κάτι που πρέπει να προσθέσω στη λίστα με όσα έχω δοκιμάσει).
Με το οριζόντιο hardware scroll, ο καταχωρητής CRTC R3 σου δίνει τον ίδιο ρυθμό με το software (αλλά τώρα έχεις τρεμόπαιγμα/flicker στις άκρες), κι αυτό και πάλι δεν είναι αρκετά ομαλό όταν τα sprites κινούνται pixel προς pixel. Μπορείς να κάνεις pixel προς pixel με hardware και με double buffering (για να αποφύγεις το flicker), αλλά πρέπει να μειώσεις το μέγεθος της οθόνης για να χωρέσουν όλες οι οθόνες στην κύρια μνήμη — εκτός αν το φτιάχνεις αποκλειστικά για το Plus.
Έτσι, στο Gryzor επέλεξαν την καλύτερη λύση για την εποχή, ώστε να πετύχουν ένα λογικό fps, κίνηση pixel προς pixel και ένα διασκεδαστικό παιχνίδι.
(Ναι, έχω δοκιμάσει πολλούς διαφορετικούς τρόπους με scrolling, συμπεριλαμβανομένων software και hardware. Αν η κίνηση του χαρακτήρα γίνεται με τον ρυθμό του hardware scrolling —συμπεριλαμβανομένου του R3— τότε δεν έχεις «πηδήματα» και το scroll μπορεί να είναι συνεχές και όχι όπως στο Ghosts and Goblins. Αλλά μόλις επιβραδύνεις τον χαρακτήρα πιο αργά από τον ρυθμό του hardware scroll, τότε πρέπει να συμβιβαστείς, όπως κάνει το G&G).
