Lors de l'elaboration des graphismes d'un jeu sur Amstrad CPC, nous sommes souvent amenes a avoir recours aux tuiles (les "tiles" en anglais). Ce terme, et son utilisation, peuvent toutefois paraitrent sybillins pour celui qui ne pratique pas la discipline. Tentons, ensemble, de comprendre leur utilite et leur mode de fonctionnement.

Qu'est-ce qu'une "tuile" ?

Si l'on se refere a Wikipedia, une tuile est "un element graphique constitutif de certains jeux video"... Mouais, voila qui ne nous avance pas beaucoup ! Personnellement, j'ajouterais qu'une tuile est, a l'image d'une mosaique, la plus petite piece carree d'un graphisme qui, lorsqu'on la repete et la juxtapose, permet de construire des zones plus grandes. Pas convaincus ? Alors voyons ca en images !

Commencons notre petite explication par un exemple concret : le decor d'un niveau de mon projet RENEGADE IV ci-contre : Sur cet ecran, on peut voir un decor de salle d'arcade. L'image, telle quelle, pese environ 9 Ko, ce qui constitue deja un morceau assez imposant a stocker dans les petits 64 Ko de RAM d'un CPC 464. Si le jeu n'utilisait, en tout et pour tout, que cet ecran, ce serait envisageable, mais lorsqu'on souhaite avoir plusieurs levels qui s'etendent sur plusieurs ecrans (en scrolling par exemple), il devient alors absolument necessaire de reduire drastiquement le poids des graphismes.

C'est a ce moment precis que l'on a recours aux tuiles !

Attardons-nous sur le sol de ce meme ecran. En l'etat, ce bout de graphisme pese deja, a lui seul, environ 5 Ko. Mais a bien y regarder, le plancher est assez basique et semble etre simplement constitue de planches oranges et turquoises qui se repetent. Il y a certainement matiere a faire des economies de memoire !

La premiere action evidente a mener est donc d'isoler ces deux planches afin d'obtenir de petits bouts de graphismes que l'ont pourra repeter a l'infini. A ce stade du traitement, nous avons ainsi deja considerablement reduit le poids du graphisme puisque stocker ces deux planches en RAM ne prendra plus que quelques octets : Nous venons de creer nos 2 premieres tuiles ! BRAVO ! Mais ne pouvons-nous pas faire mieux ?

En y regardant de plus pres, on constate que meme ces planches (de 48 pixels de larges et 8 pixels de haut) sont constituees de motifs qui se repetent ! Decoupons une nouvelle fois en 12 petits carres de 4x8 pixels. Avec le quadillage, il apparait alors tres clairement que cette planche est bel et bien composee d'elements redondants, a savoir : le trait oblique qui revient a chaque extremite, et le trait horizontal qui est present 8 fois ! Il semble evident que conserver des motifs redondants constitue un gaspillage de RAM... Optimisons encore !

Ainsi, en ne conservant que les motifs uniques permettant de reconstituer les deux types de planches du sol (oranges et turquoises donc), nous parvenons a isoler un total de seulement 8 petites tuiles de 4x8 pixels. Autant dire que cela ne pese presque rien en RAM. Mieux encore, nous constatons qu'il est meme desormais possible d'agencer ces petites tuiles de differentes maniere pour obtenir toutes les tailles de planches imaginables a l'ecran. C'est encore plus efficace ! MISSION ACCOMPLIE !

Pour bien prendre la mesure de l'economie de RAM que nous venons de realiser, sans parler de la souplesse au niveau de l'agencement que nous avons gagne au passage, voici, ci-contre, un comparatif des deux versions des graphismes : En haut, le sol original compose d'un gros bloc de 9 Ko, gourmand en ressource, statique et immuable : 5 Ko En bas, les 8 petites tuiles, sobres en ressource, souples et legeres : 0,07 Ko Une fois les tuiles ainsi definies, le programme pourra alors reconstituer le sol en temps reel, en appelant et affichant la bonne tuile au bon endroit a l'ecran. Pour cela, le programmeur s'aide generalement d'un tableau faisant correspondre le numero de la tuile avec sa potition. Ci-contre, on peut voir de haut en bas : - l'aspect du sol desire - les 8 tuiles choisies (avec leur numero respectif) - le tableau de correspondance entre les numeros des tuiles et leurs positions a l'ecran. Avec ces elements, le programmeur pourra coder le sol par quelques lignes de donnees tres peu consomatrices d'octets. Ce qu'il faut savoir, c'est que pour cette explication, nous avons pris le probleme a l'envers. En effet, nous sommes partis d'un decors complet pour le decortiquer et le decouper jusqu'a sa plus petite tuile. Or, lors de la phase de developpement des graphismes d'un jeu, cette demarche et cette reflexion au sujet des tuiles doivent imperativement etre faites en amont.

End of File.