Tile Mapping : Présentation générale

Bienvenue dans la première partie de ce tutoriel.

Dans cette partie, nous allons présenter le « Tile Mapping », et faire un petit programme qui affiche un petit monde simple de deux façons différentes :

• avec des nombres directement dans le code ;
• avec un fichier texte comme modèle.

Vous avez déjà tous joué à ce qu'on appelle des jeux de plates-formes en 2D. Il s'agit de jeux où un personnage court dans un monde, parfois à toute vitesse, saute, monte sur des blocs, et infatigablement continue à courir et à sauter…
Pendant que vous courez, l'écran défile. Le monde que vous parcourez peut être plus ou moins grand.

Un exemple très connu de jeu de plates-formes, duquel nous allons nous inspirer, est Super Mario Bros.

Vous avez déjà sûrement joué aussi à des jeux vus de dessus, comme ce bon vieux Zelda.

Dans ce tutoriel, nous allons essayer de voir comment de tels jeux sont faits. Comment le monde est mis en place et comment faire défiler l'écran.

Comment, avec SDL, peut-on arriver à faire un tel type de jeu ? Comment avoir quelque chose de rapide et d'efficace ?

III-A. Cheminement du tutoriel▲

Avant de parler « Tile Mapping », voici une technique qui pourrait être utilisée pour faire un jeu de plates-formes.

L'idée qui vient à l'esprit tout de suite est de dessiner son monde sous un logiciel de dessin, « Paint » par exemple. L'idée serait de charger l'image au démarrage du programme, de l'afficher en tant que fond d'écran, puis afficher un Mario par-dessus. Les inconvénients sont les suivants.

IV-A. C'est coûteux en mémoire▲

IV-B. C'est inexploitable▲

Le plus gros inconvénient est que c'est inexploitable. En effet, si vous affichez votre image de fond, puis que vous affichez Mario, pouvez-vous dire facilement si Mario est sur une plateforme ? Dans l'air ? Dans un mur ? Que s'il avance d'un pas, il tombe ?
Eh non… Vous pouvez éventuellement vous en sortir sur une image où le fond est uni, mais si vous avez une image de fond comme CastleVania ci-dessous, vous ne pouvez pas vous en sortir de cette façon…

Cette technique a trop d'inconvénients pour être utilisée. Je voulais en parler, car c'est souvent la première idée qui vient, de « dessiner » son monde, mais nous allons l'oublier, et passer enfin à la technique dont je vous parle depuis tout à l'heure…

Avant de définir ce qu'est le Tile Mapping, nous allons ensemble regarder quelques images de jeux connus. Comme on dit « un bon croquis vaut mieux qu'un long discours, cela devrait nous aider.

Quelle est la particularité des cartes de ces jeux ?

Eh bien nous pouvons constater que des motifs se répètent. En effet, les sols sont des briques identiques, collées les unes à côté des autres.

Mieux que ça, on peut remarquer la régularité parfaite de la chose : les points d'interrogation de Mario sont exactement au-dessus des briques de sol.

Pareil, dans Zelda, que nous voyons en dessous, il y a des motifs identiques qui se répètent avec une grande régularité.

Le concept de « Tile Mapping » est de coller côte à côte des tuiles (« tiles » en anglais) dans une zone régulière. Pour cela, nous subdivisons l'écran en une grille régulière, et nous mettrons un carreau dans chaque case.

Vous voulez voir la grille ?

Si on regarde bien cette dernière image, et qu'on oublie Mario, l'ennemi, l'étoile, et les nuages, qui sont des sprites, nous avons affaire à un décor très régulièrement placé. Chaque brique s'emboîte parfaitement dans la grille.

Comme déjà dit, chacune de ces petites briques est appelée tuile, ou « tile ».

Il y a les tuiles uniques, comme les briques et les points d'interrogation, et les tuiles composées, comme le pot de fleurs, qui est plus gros qu'une case. Cependant, ce pot de fleurs, bien qu'il semble être un objet unique, sera vu par la machine comme huit cases infranchissables…

L'avantage d'une telle méthode est donc qu'au lieu de définir le monde (considérons qu'il ne bouge pas) par une grande image, on le définit par une grille de 13*15 cases.

Nous disions que nous définissons l'image d'au-dessus par 13*15 cases.

Cela fait 195 cases.

Combien y a-t-il de tuiles différentes ?

Sur notre image, on a :

• le bloc ciel ;
• le bloc sol ;
• le point d'interrogation ;
• quatre tuiles différentes pour le pot de fleurs.

… moins d'une dizaine…

Nous pouvons imaginer un tableau de 13 * 15 cases qui contiennent un nombre. Si le nombre est 0, on met du « ciel », si le nombre est 1, on met un bloc cassable, si c'est 2, on met un « ? », 3 le bord supérieur gauche du pot, 4 le bord supérieur droit, 5 le bord gauche, 6 le bord droit, 7 le sol d'en bas, etc.

On définit, pour notre Mario, le tableau suivant :

000000000000000 
000000000000000 
000000000000000 
000000000000000 
100000000111110 
000000000000000 
000000000000000 
000000000000000 
003400022220022 
005600000000000 
005600000000000 
005600000000000 
777777777777777

Ce tableau de nombres décrit parfaitement notre monde, car il nous dit, pour chaque case, quel bloc mettre.

Vous suivez toujours ?

Du coup, avec :

• quelques tuiles,
• un tableau de nombres,

on définit un monde ! Schématiquement, cela donne :

La partie de gauche s'appelle « TileSet ». Elle contient les différents carreaux à poser. Ce sont les Tilesets qui définissent le graphisme. Dans mon cas, j'ai fait un tileset d'une seule ligne, mais comme les jeux contiennent quand même davantage de tiles, on définit souvent un tileset sur plusieurs lignes.

Vous trouverez de nombreux exemples sur Google Images en cherchant « tileset » !

La partie du milieu est le tableau de correspondance.

La partie de droite est bien sûr le résultat final.

Revenons maintenant au coût mémoire.

Pour faire mon monde de Mario, j'ai besoin d'un ensemble de tuiles (une petite image en soi), et du tableau.

Si je considère que je n'aurai pas plus de 256 tuiles différentes (je tape très large, et c'est souvent le cas), je peux compter un octet par case de mon tableau.

Avec mon tableau de 13 * 15, j'ai moins de 200 octets…. C'est très petit.

Maintenant, supposons un monde entier de Mario (qui défile). Imaginons le monde déplié ainsi :

Combien il y a-t-il de cases là-dedans ? À la louche je dirais 300 en largeur et 20 en hauteur.

300 * 20 = 6000 octets.

Voilà, le monde tout entier tient sur une petite image de tuiles + 6 Ko de données : une cacahuète quoi…

Et avec ça, on fait un grand monde.

C'est ainsi qu'ont procédé les consoles 8 et 16 bits, qui n'avaient pas beaucoup de mémoire.

Imaginez que si on avait codé tout le monde sous forme d'une graaaande image, on en aurait eu pour des dizaines de mégaoctets, pour une seule « texture », ce qui aurait bien chargé la carte graphique, et qui, outre ceci, aurait été inexploitable par la suite. (Nous verrons les avantages du « Tile Mapping » lorsque nous parlerons de collisions avec le décor.)

L'algorithme n'est pas complexe. Nous définissons, une fois pour toutes, une longueur et une hauteur de tuiles (qui resteront fixes).

Puis nous faisons un double for (i,j) sur le tableau, et nous affichons la bonne tuile à la position (i * largeur, j * hauteur).

Voici l'exemple suivant en C qui reconstruit le petit monde de Mario (juste la partie qu'on a étudiée)

Téléchargez et dézippez l'ensemble des fichiers de ce tutoriel ci-dessous :

Tous les fichiers.

VII-A. Explication sur les programmes▲

#include <SDL/SDL.h> 

#pragma comment (lib,"sdl.lib")      // ignorez ces lignes si vous ne linkez pas les lib de cette façon. 
#pragma comment (lib,"sdlmain.lib") 

#define LARGEUR_TILE 24  // hauteur et largeur des tiles. 
#define HAUTEUR_TILE 16 

#define NOMBRE_BLOCS_LARGEUR 15  // nombre a afficher en x et y 
#define NOMBRE_BLOCS_HAUTEUR 13 

char* table[] = { 
"000000000000000", 
"000000000000000", 
"000000000000000", 
"000000000000000", 
"100000000111110", 
"000000000000000", 
"000000000000000", 
"000000000000000", 
"003400022220022", 
"005600000000000", 
"005600000000000", 
"005600000000000", 
"777777777777777"}; 


void Afficher(SDL_Surface* screen,SDL_Surface* tileset,char** table,int nombre_blocs_largeur,int nombre_blocs_hauteur) 
{ 
    int i,j; 
    SDL_Rect Rect_dest; 
    SDL_Rect Rect_source; 
    Rect_source.w = LARGEUR_TILE; 
    Rect_source.h = HAUTEUR_TILE; 
    for(i=0;i<nombre_blocs_largeur;i++) 
    { 
        for(j=0;j<nombre_blocs_hauteur;j++) 
        { 
            Rect_dest.x = i*LARGEUR_TILE; 
            Rect_dest.y = j*HAUTEUR_TILE; 
            Rect_source.x = (table[j][i]-'0')*LARGEUR_TILE; 
            Rect_source.y = 0; 
            SDL_BlitSurface(tileset,&Rect_source,screen,&Rect_dest); 
        } 
    } 
    SDL_Flip(screen); 
} 

int main(int argc,char** argv) 
{ 
    SDL_Surface* screen,*tileset; 
    SDL_Event event; 
    SDL_Init(SDL_INIT_VIDEO);        // prepare SDL 
    screen = SDL_SetVideoMode(LARGEUR_TILE*NOMBRE_BLOCS_LARGEUR, HAUTEUR_TILE*NOMBRE_BLOCS_HAUTEUR, 32,SDL_HWSURFACE|SDL_DOUBLEBUF); 
    tileset = SDL_LoadBMP("tileset1.bmp"); 
    if (!tileset) 
    { 
        printf("Echec de chargement tileset1.bmp\n"); 
        SDL_Quit(); 
        system("pause"); 
        exit(-1); 
    } 
    Afficher(screen,tileset,table,NOMBRE_BLOCS_LARGEUR,NOMBRE_BLOCS_HAUTEUR); 

    do  // attend qu'on appuie sur une touche. 
    { 
        SDL_WaitEvent(&event); 
    } while (event.type!=SDL_KEYDOWN); 
     
    SDL_FreeSurface(tileset); 
    SDL_Quit(); 
    return 0; 
}

Rect_source.x = (table[j][i]-'0')*LARGEUR_TILE;

char* table[] = { 
"Bonjour", 
"Salut!!", 
"Hello!!", 
"Saloute", 
"Hola!!!" 
}