Le scroll multidirectionnel

"Traveling without moving" (part 2)

Foreword

Alors maintenant, vous avez compris comment gérer un scroll text, et vous avez probablement remarqué par extension qu'avec cette méthode, on peut tout à fait gérer un scroll unidirectionnel.

Les choses se corsent un peu lorsqu'il s'agit d'un scroll multidirectionnel, parce que là, à moins de n'avoir qu'un tout petit débattement dans l'autre sens que son scroll, on est coincé.

Old school

Je m'en vais donc vous expliquer comment je gére un scroll multidirectionnel, en simulant une mémoire "à rouleaux", comme on en trouvait sur toutes les machines qui géraient du mode caractère (Game Boy, GBA, Famicom et Super Famicom, Neo-Geo, PC Engine et même Saturn (je m'avance un peu pour certaines, mais je ne pense pas me tromper)). Personnelement, je l'ai expérimenté sur la famille des Game Boy.

Donc sur ces vieilles machines avec très peu de puissance (1,05 MHz pour une Game Boy N&B), il était évidement inenvisageable de recopier toutes les tiles du décor une par une à chaque image (c'est de toute façon une très mauvaise idée, même à l'heure actuelle). Heureusement, on avait à disposition un hardware bien pensé.

Bon, ok, sur une GB, il aurait suffit de mettre à jour uniquement les codes caractères, mais même : c'est une mauvaise idée. On ne doit gérer que ce qui rentre dans l'écran.

Donc, la mémoire à rouleaux : Pour les scrolls, on avait donc un espace en VRAM pour afficher son écran. Cet espace mémoire avait donc une particularité, quand on débordait à droite, on revenait à gauche A LA MEME HAUTEUR. Idem pour le bas, on revenait en haut au même x.

Exemple

Prenons pour exemple une VRAM de ce type comportant 16 blocs de large sur 16 blocs de haut, et un écran de 10 blocs de large sur 10 blocs de haut.

Pour simplifier la compréhension, nous dirons que les blocs font 10 pixels de côté (C'est vraiment pour l'exemple, car c'est une très mauvaise valeur. En réalité, il faudra des puissances de 2, pour le coup 8 ou 16 pixels).

Nous avons donc un écran de 100x100 pixels, dans une VRAM de 160x160.

Dans le dessin ci-dessous, la fenêtre d'affichage en bleu est positionnée en (75, 33). Forcément, 75 + 100 = 175, ça déborde à droite.

tuto

Le hardware, lui, voyait ça de la façon suivante :

tuto

Pour restituer l'affichage suivant à l'écran :

tuto

Ensuite, comme c'est souvent le cas, le scroll avance. Faisons le avancer vers la droite. Position écran = 76. On n'a rien à faire, puisque les blocs sont déjà dans la VRAM. Colonnes 77, 78, 79, idem, pas de problème. Colonne 80 : Changement de bloc. On va donc préparer une nouvelle colonne de blocs à droite (la colonne en vert dans l'image ci-dessous).

tuto

A partir de maintenant, tant que le scroll restera entre 80 et 89 en x, et 30 et 39 en y, on ne touchera donc jamais au décor.

On ne copie qu'une ligne et/ou une colonne de blocs de la largeur/hauteur de l'écran + 1 qu'aux passages d'un bloc à l'autre. Et c'est le seul et unique moment où on va aller lire des codes de blocs dans sa map ! Tout le reste du temps, il suffit de déplacer la position de la fenêtre d'affichage.

Application

Comme sur PC on n'a pas le hardware équivalent, on va simuler notre VRAM précédente par un simple buffer mémoire qu'on se contentera de blitter à l'écran, soit selon les cas de 1 à 4 blits.

Dans la vraie vie, on ne va jamais choisir une taille de bloc de 10 pixels. On va encore une fois s'orienter vers une taille multiple d'une puissance de deux (qui a dit 16 ?), ce qui permet de masquer facilement.

Pour la taille du buffer, afin de simplifier les opérations (éviter les divisions et modulos qu'on pourra avantageusement remplacer par des '&' et des shifts), on va choisir une taille maline : Les puissances de 2 immédiatement supérieures aux dimensions de l'écran. Par exemple pour un écran de 320x240, mon buffer fait 512x256. (Il faut au minimum 1 bloc entier de plus que la dimension).

Voici les 4 cas de blits possibles, à gauche le buffer, à droite l'écran :

Cas A, la fenêtre écran ne dépasse ni à droite ni en bas, 1 blit :
tuto

Cas B, la fenêtre écran dépasse à droite, 2 blits :
tuto

Cas C, la fenêtre écran dépasse en bas, 2 blits :
tuto

Cas D, la fenêtre écran dépasse à droite et en bas, 4 blits :
tuto

Sur PC, on n'a pas le choix : On ne peut pas éviter quelques blits vers l'écran. Mais dans tous les cas, quelques gros transferts sont plus rapides qu'une multitude de petits.

Home