les tiles : du C64 à la NDS

:)

créer des images

Sérieux: les premières bornes d'arcade n'avaient tout simplement pas de processeur graphique. On pilotait directement la couleur (enfin, je devrais dire l'activation) du canon à électron avec des OUT DX,AL où AL vaut soit 1 soit 0. pour tracer une ligne de la raquette de PONG, il convenait donc de commencer à passer au blanc sur la bonne colonne pour repasser au noir quelques micro-secondes plus tard. Le malheureux Méga-Hertz du processeur était donc monopolisé à compter le temps qui passe pour décider s'il fallait afficher une barre ou pas.

Au fil des générations de console, le principe est pourtant resté jusqu'à la playstation et sur les portables Nintendo. Bien sûr, à eux seuls, ces "tiles" de 8x8 pixels placés sur une grille ne résolvent pas tous les problèmes et on leur rajoute volontier des "sprites", des sur-couches graphiques de taille réduite (de 8x8 à 64x64 pixels selon les machines) que l'on peut déplacer librement et indépendamment les unes des autres .. ou de la 3D pour New Super Mario Bros. -- mais ça, c'est une autre histoire.

Map + Tiles

Sur les micro-ordinateurs 8-bit (et sur Pac-man Arcade), l'écran était presque systématiquement construit sur base de deux mémoire: un jeu de caractères (8x8 pixels) d'une part et une table de N lignes x M colonnes : la map.



Cette "map" indique pour chaque case de l'écran le caractère à utiliser et un certain nombre d'attributs -- par exemple, faut-il prendre le blanc/jaune des pac-gommes ou le bleu des murs. En atteste ce "plantage" de pacman où, si le contenu de la mémoire vidéo a été "écrasé", elle continue à montrer des "vrais" caractères ou des bouts de labyrinthe et pas un tas de pixel incohérents: le caractères eux sont toujours bien là, c'est leur disposition sur l'écran qui est devenue totalement anarchique.

À l'époque, l'intérêt était avant tout technique: on aurait jamais pu se permettre de mettre une mémoire suffisamment puissante pour fournir les bits 1 à 1 à la vitesse où l'écran les réclamait. Et si même on l'avait fait, on aurait pas eu assez de temps pendant le retour du rayon pour changer le contenu de toute cette RAM. Tandis qu'avec un jeu de caractères figé, auquel la puce graphique à l'accès exclusif, on peut s'en sortir et il ne reste qu'à lire moins d'une centaine d'octets contigüs (la map) par ligne d'affichage. Ça, c'est jouable.



La base du graphismes "par tiles" (le terme anglais pour des pavés de salle de bain, ceux qui peuvent avoir des motifs à respecter) c'est donc de constuire ces graphismes qui pourront tenir sur un pavé de 8x8, ou sur un petit nombre de pavés de 8x8. Construire un niveau, ça revient à remplir une grille en mettant le bon numéro de pavé au bon endroit. Du coup, toutes les échelles se ressemblent, les fenêtres sont presques toutes les même, puisqu'on n'a la place que pour une ou deux variante de chaque objet. Au fil des générations de consoles, le nombre de pavés unique a augmenté en permanence, au point que sur DS, on a pas assez d'un écran pour les montrer tous. Pourtant, même avec un nombre réduit de pavés 8x8 qu'on organise en blocs de forme et de taille variable, on parvient à construire un environnement suffisamment diversifié pour que le joueur se concentre sur l'action. La puce graphique, elle reconstruit l'image à l'écran sur base d'une grille à peine plus grande que l'écran qui lui indique quel pavé mettre à quel endroit.

Scrolling continu

Pour un jeu dont l'écran reste figé la plupart du temps, comme le premier Zelda, on pourrait en rester là, mais on peut faire bien mieux: commencer à lire la grille (la map) dans un coin plutôt qu'un autre n'est finalement qu'une convention. Si on équipe la puce graphique avec un compteur (on parle de "registre", en électronique) qui dit à quel emplacement en mémoire commencer le rendu (plutôt que de remettre un zéro comme position de départ), on peut faire apparaître n'importe quel tile dans le coin supérieur gauche. Si on augmente ce compteur du nombre de tile par ligne après chaque image, on a un défilement continu bien que trop rapide pour être confortable (un peu comme dans l'intro de Sonic 3) qui reboucle sur lui-même.



Eh bien non, parce qu'on a qu'un nombre limité de pistes de cuivre pour amener la sortie de ce compteur électronique vers la puce-mémoire en question. Donc dès qu'on va par exemple atteindre la ligne 32 en ayant commencé à la ligne 25 on retombe automatiquement à 0 vu qu'il n'y a pas assez d'électronique pour faire la différence entre un 32 et un 0. Donc non seulement c'est mieux, mais en plus c'est gratuit.

Dans la génération 8-bit, on complétait ce mécanisme de scrolling avec des registres de scrolling "fin" pour indiquer aussi sur quel pixel (horizontal et vertical) du premier pavé on commençait la lecture. Le reste de l'électronique reste identique: on passe à la ligne de pavés suivante seulement quand on atteint la 7eme ligne de pixels dans les pavés en cours, que l'on ait commencé au 1er, 4eme ou 6eme pixel. Sur les consoles suivantes, la position horizontale et verticale, exprimée directement en pixels est tout ce que le codeur voit et le hardware se débrouille pour en extraire adresse mémoire, ligne-dans-un-tile et colonne-dans-un-tile tout seul.



Ils ont utilisé une mémoire vidéo plus grande que l'écran lui-même. C'est particulièrement flagrant sur le GBA, celà dit, qui propose un écran de 240 pixels de large avec une mémoire vidéo de 256 pixels de large. Du coup, il y a toujours au moins une colonne de tiles qui est complètement masquée et dont le contenu peut être changé à la volée.

Cliquer pour afficher l'image en taille réelle

.

Pour se fixer les idées, imaginons qu'on regarde un beau paysage peint sur une toile. Mais en fait, cette fois, la toile n'est pas tendue sur un cadre mais entre 2 rouleaux de sorte que le public ne voit qu'une partie. Pendant que la toile passe derrière (partie hors-écran), le peintre remplace une tranche de la largeur d'une page A4 par la suite du dessin, puis quand elle commence à disparaître de sa vue, il passe à la tranche verticale suivante, etc. Le public ébahi a alors l'impression de voir se dérouler devant lui des kilomètres de peinture alors que la toile ne fait que 10m.

Et voilà: on a un scrolling au pixel près en ne remettant à jour en mémoire qu'une vingtaine d'octets à chaque pas du personnage. Comparativement, sur PC, on est obligé de redessiner pixel-par-pixel l'entièreté du décor à chaque image et il faudra attendre le 486 et les cartes graphiques PCI pour commencer à avoir quelque-chose de comparable à un Super Mario.

Les petites animations

Autre avantage du système des tiles: ça facilite les animations, et particulièrement dès que les tiles sont dans une mémoire reprogrammable (dès les machines 16-bits): plein de pièces d'or à faire tourner ? pas de soucis: il suffit d'en faire tourner une (dans la mémoire des tiles) et automatiquement, toutes les pièces à l'écran en profitent.

Les couleurs

Quelle que soit la génération de console, l'utilisation des palettes revient encore une fois à un problème de taille en mémoire: il y a plus de couleurs disponibles que ce qu'on ne peut en "nommer" par pixel en gardant une console/un micro à un prix abordable. Sur les 60 couleurs de la NES, on travaillera donc par "palettes" de 3 couleurs + un code de transparence qui laisse voir la couleur de fond. Comme 4 couleurs, c'est généralement trop peu même pour un jeu 8-bits, on va autoriser un nombre restreint de palettes différentes (4*3 couleurs sur NES, 16*15 pour la SNES et le GBA) et conserver le numéro de palette dans les fameux "attributs" associés à chaque tile.

Tout ça peut sembler du crépage de chignon à l'heure actuelle (encore que le temps de téléchargement du contenu pour un jeu flash ne devrait pas être pris trop à la légère, à mon avis), mais il faut se rendre compte qu'on parle ici de jeux qui devront être placés sur des ROMs de taille limitée, et qu'une ROM plus grande se traduisait systématiquement par un prix de vente plus élevé (et donc potentiellement moins de ventes). Comme en plus le processus de création des ROMs était long et que les studios devaient pré-commander le nombre d'unité de jeu souhaitées [source: The playstation revolution], on est moins surpris d'apprendre que les développeurs de Zelda: link to the past et Super Mario World (pour ne citer qu'eux) aient décider de faire leurs graphismes sur 7 couleurs par palette plutôt que les 15 disponibles pour gagner de l'espace sur la cartouche. En général, entre "plus de couleurs" ou "plus de contenu", c'était le contenu qui gagnait (nostalgique, moi ? quelle idée!)

C64: Hires/Lores

Là où le VIC de Commodore se démarque de ses concurrent (se rapprochant du coup des circuits dédiés qu'on trouvait dans les bornes d'arcade), c'est en proposant un mode où les caractères sont "multi-couleur" mais avec des pixels 2 fois plus larges. En revanche, si ça ajoute des couleurs, ces pixels ultra-larges ne sont vraiment esthétiques: seuls les possesseurs d'une console Atari seront épatés. Le C64 va donc un cran plus loin. Un caractère peut être monochrome ou 3-couleurs (avec une combinaison pour laisser paraître la couleur de fond) et on peut règler pour chaque caractère le fond et l'avant plan séparément. Le mode multi-colore fait raffistolage: de ces 3 couleurs, 2 seront définies pour l'ensemble de l'écran et une seule pourra être changée caractère par caractère. Par contre, on pourra (moyennant règlages adéquats) mélanger des caractères "haute définition" et des caractères multicolores sur le même écran. Indispensable pour avoir les picots bien pointus des Soeurs Giana.

NES: 4 palettes

Le C64, c'est une machine un peu hybride, conçue à l'intersection des ordinateurs personnels d'IBM, avec sa combinaison "couleur de fond/couleur de texte" et d'une machine d'arcade avec ses sprites tricolores et ses interruptions dédiées qui permettent de connaître avec précision la position du faisceau d'électrons. Avec la NES, l'affichage de texte cesse d'être une priorité. Pour convaincre mémé d'acheter la console de salon à son fifi, plus question de sacrifier en résolution pour avoir plus de couleurs. La machine aura bien moins de RAM de travail (2Ko seulement) et les graphismes seront essentiellement dans de la mémoire ROM. Pas besoin donc de ménager de la bande-passante CPU-mémoire et on a bien plus de bits par seconde pour la liaison cartouche-PPU. Grâce à ça, on peut se permettre le grand luxe d'avoir 2bits de couleur par pixel et 2 bits de "numéro de palettes" par bloc de 16x16 pixels.



Eh oui. Processeur tournant à peine à plus d'1MHz sans refroidissement, et la technologie la moins chère possible -- la seule qui soit à la portée du grand public. Ceux qui ont fait le calcul vous feront remarquer qu'on a toujours que 4 couleurs par tile de 8x8 pixels et ils auront presque raison. Disons plutôt qu'on a:
- une couleur de ciel, qui sera la même partout à l'écran.
- 3 couleurs pour chaque objet ... juste assez pour mettre un peu de texture sur le brun du bois ou des reflets à nos lames de rasoir géantes.
- 4 "matières", c'est-à-dire 4 sélections de 3 couleurs, choisies librement parmis les 60 que peut produire la puce graphique: ce sont les fameuses palettes.



Reprenons notre Super Mario Bros, on compte 2 teintes de brun et du noir pour la palette "briques", 2 teintes de vert et du noir pour la palette "tuyaux et buissons", la palette des nuages et la palette des bloc-questions avec son jaune (qui resservira aussi pour les pièces d'or). On passe en sous-sol ? hop, il suffit de modifier la palette "briques" pour y mettre des teintes de bleu désaturé. C'est la nuit perpétuelle chez Bowser ? Hop, je change la couleur du ciel pour qu'il soit noir et plus bleu .. etc.

N'y voyez pas de la paresse: à l'époque faire une ROM plus grande pour héberger autant de variété graphique qu'on peut en voir dans le projet "Super Arne Bros", c'est aussi prendre le risque d'avoir plus de puces défectueuses (oui, ça dépend de la taille), et si le prix de revient de la cartouche dépasse la place qu'il peut se faire dans le panier de la ménagère, ce sera un four... Parce qu'à l'époque, personne n'attend avec impatience le premier épisode de Mario ou de Zelda. C'est bel et bien de la ruse technologique pour faire quelque chose d'épatant avec des moyens plus que limités... mais le résultat est là. Et finalement, 13 couleurs pour le décor et 12 couleurs pour les personnages, ça donne quand-même quelque-chose de plus haut en couleurs que tout ce que le grand-public a pu s'offrir jusque là.

16-bit: Devant ou derrière ?

Arriva donc la Génération Suivante, avec des processeurs capable de traiter 2 fois plus de données d'un coup, de manipuler en une opération un nombre plus grand que le nombre de colonnes de pixels à l'écran (ouf!). Plus besoin de faire un référentiel des couleurs disponibles, on peut combiner librement les niveaux de rouge bleu et vert pour faire un rendu fidèle de Tintin au Tibet ou d'Obélix. Plus de risque de se faire refuser son projet d'adaptation parce que le public n'aurait pas reconnu le personnage.

Pourtant, à l'intérieur des puces, le problème fondamental reste le même: on arrivera jamais à produire 256x256x32768 bits en 1/50eme de seconde. On conserve donc pour les phases de jeu une structure de tiles, mais ils seront 4 fois plus nombreux, avec 15 couleurs chacun et on s'autorise 8 palettes de couleurs différentes. La valeur "0" dans les palettes avait pour signification "on peut voir à travers" sur la NES, ça devient d'autant plus intéressant lorsqu'il est possible d'avoir une deuxième map que l'on fait scroller indépendamment par-derrière. Un autre élément qui va permettre de donner plus de relief au jeu, ce sera de décider tile-par-tile si on veut que l'affichage vienne devant ou derrière les "sprites". Les amateurs de symétrie apprécieront la possibilité de faire retourner les tiles ... Les autres devront choisir entre un éclairage "par le haut" ou accepter que cette fonctionnalité ne leur sera qu'assez peu utile.

Entretemps, la RAM est devenue nettement moins coûteuse. On pourra se permettre une map faisant 2x2 écrans (et donc autorisant un scrolling libre) là où la génération 8 bits devait choisir entre 2x1 (scrolling horizontal) ou 1x2 (scrolling vertical) ce qui explique le level design si particulier des Megaman ... et les clignotements étrange sur le bord de l'écran dans SMB3 qui voulut ignorer cette limite coûte que coûte. La génération 16 bits autorisera aussi que les graphismes des sprites soient en mémoire reprogrammable ... mais ça, c'est une autre histoire.

C'est aussi quasi exactement le fonctionnement du graphisme GBA, si ce n'est que le bit de "priorité" (qui permettait de faire passer le mur par-devant le personnage) est abandonné au profit de 16 palettes de couleurs.

La dernière touche, apportée par la Nintendo DS fera monter les palettes à 256 couleurs tout en conservant la possibilité d'en avoir 16 différentes. Bien plus que ce qu'aucun artiste du Pixel ne parviendra à utiliser, mais on ne fait pas des jeux qu'en pixel art de nos jours ... Pas vrai, M. Ancel ?