Introduction à la série d'articles sur les différentes techniques de scrollings
Je vais d'abord faire un petit rappel sur les adresses écrans et parler du rebouclage d'adresse dans une ligne de bloc, car c'est LE truc fondamental qui a orienté les choix techniques de nombreuses personnes.
Partez paaaaaaaaaaaaaaas! Donc je vais faire un rappel sur l'écran de base mais aussi sur LE fameux écran de beaucoup de jeux vidéos à 64 octets de large et enfin attaquer les notions et difficultés qu'on va rencontrer avec un scrolling hardware.
Tout d'abord, prenons l'écran du BASIC standard. Remplissons la mémoire VISIBLE par des caractères, une lettre différente par ligne. J'ai surligné avec un trait VERTICAL rouge les incrémentations de poids fort, c'est à dire les adresses où il n'est pas possible de faire un INC L pour passer à l'octet d'à côté. D'ailleurs, dans tous les articles des routines de sprite, j'utilise soit LDI, soit LDIR, soit INC HL pour passer à l'octet suivant, c'est à cause de ça.
L'écran BASIC standard affiche 16000 octets (200 lignes de 80 octets). Le BASIC configure par défaut le CRTC pour parcourir les adresses d'une seule page de 16K (ou 16384 octets). Mais où sont donc passés les 384 octets restants? Ils sont hors-écran. Pour les visualiser, on peut étendre un peu la zone affichable avec le registre 6 du CRTC.
; à faire en BASIC out &BC00,6 : out &BD00,26 ; 26 lignes au lieu de 25 |
Notre écran devient...
Et là, on remarque rapidement deux choses :
- Les octets "libres" non affichés, sur une longueur de 24 caractères (soit 48 octets de long)
- Un trait bleu en bas de l'image matérialisant le rebouclage de la ligne de bloc
Quézaquo le rebouclage de ligne de bloc?
Comme vous le voyez sur la capture, c'est l'endroit le plus PENIBLE de la mémoire affichée car à cet endroit, le CRTC ne se contente pas d'incrémenter l'adresse physique. Son compteur interne ne peut pas dépasser 2047. L'adresse passe donc de #C7FF à #C000. Ce n'est pas grand chose à gérer un rebouclage de bloc, mais si on doit le faire à chaque octet affiché, ça fini par devenir très coûteux en CPU!
Le trait rouge pointillé reste bien aligné, on ne change pas de ligne de bloc lors de l'affichage d'une ligne graphique.
Quand on utilise comme nous jusqu'à présent un écran fixe, ON S'EN FOUT! Mais dans le cas d'un scrolling hard, ce point de rupture va rapidement venir dans la zone visible! Cette animation va parcourir les 1024 positions possibles de scrolling d'un CPC de base. (Modifications du registre 12 et 13 du CRTC)
Avec un écran reformaté à 64 octets de large
De nombreux jeux vidéos utilisent un écran moins large avec 64 octets seulement. C'est à la fois hérité des speccy-porcs et aussi une technique pour optimiser les changements de ligne. Si on n'utilise pas de scrolling hard, on voit que les changements de poids forts (traits verticaux rouges) sont TOUS sur le côté droit de l'écran, toutes les 4 lignes.
On voit aussi que le rebouclage des lignes de bloc se passe à la toute fin de la zone visible (trait bleu) et qu'il n'y a pas d'octets de la page graphique, non visibles.
Ainsi, afficher un sprite peut se faire avec des incréments simples qui sont deux fois plus rapides que les incréments 16 bits.
Cependant, dès lors qu'on scrolle l'écran horizontalement (verticalement ça passe ^_^), toutes ces optimisations ne peuvent plus être réalisées, comme on le voit sur la capture avec un décalage arbitraire.
Tout au plus on pourra déterminer facilement si le sprite qu'on va afficher se trouve sur une zone de chevauchement ou non (je ne sais pas quand on parlera de ce genre d'optimisations, mais c'est pas pour tout de suite...)
Les bases étant posées, nous allons pouvoir commencer à faire scroller notre écran en tenant compte de toutes les contraintes évoquées. Rendez-vous dans l'article sur [mon premier scrolling hard]
