L'optimisation du Tile Mapping

Bonjour les Zestes,

Je fais appel à vous dans le but d’avoir des retours sur le travail que j’ai réalisé. Je souhaiterai voir ce tutoriel en ligne un jour, de se fait j’étudierai toutes les critiques que vous me ferez afin de rendre ce tutoriel le plus pertinent possible!

au plaisir de vous lire !

Vous pourrez consulter la bêta à votre guise à l’adresse suivante :

Merci !

Très bon cours, même si j’aurais aimé avoir un pseudo-code à la fin, afin de savoir comment procéder en détail.

J’ai cependant noté quelques erreurs :

Dans votre librairie graphique, vous devriez disposer d’une fonction qui vous retourne la taille maximal des texture stockable en mémoire que votre carte graphique.

Ne serais-ce pas par ou quelque chose du genre ?

Notez que je vous ai fais la démonstration en pour l’abscisse. La reflexion est la même en ordonnée. Notez également que la toute dernière texture (en bas à droite ) fais 224 * 224 pixels soit 7*7 tiles.

Il faudrais enlever le en.

Personnellement, je dessine uniquement les tiles visibles à l’écran.

Voici un pseudo-code de ce que je fait :

1
2
3
4
5
6
7
8
9

case start x = (entier) (player x / tile size)
case start y = (entier) (player y / tile size)

case end x = case start x + (camera width / tile size)
case end y = case start y + (camera height / tile size)

for x : case start x -> case end x
    for y : case start y -> case end y
        draw tile [x;y]

Ainsi, j’ai toujours de bon FPS, car je dessine toujours le même nombre de tiles (et surtout, le nombre de tile minimum).

Pour ma part, ce tuto ressemble plus à une sorte d’astuce postée sur un forum par quelqu’un qui découvre le monde du jeu vidéo 2D.

En fait, l’astuce proposée (si j’ai bien compris) est équivalente à coller soi-même les tuiles avec un éditeur d’image (genre Photoshop) dans une seule image, et charger puis afficher cette image à l’écran. Or, un des principes fondamentaux du tile mapping, c’est de ne pas avoir à stocker plusieurs fois le même "bout de texture" en mémoire.

Mais sinon, oui en effet, dessiner les tuiles une par une n’est pas efficace, mais on peut déjà bêtement se contenter de ne dessiner que celles qui se trouvent dans le champ de vision de la caméra pour avoir des performances satisfaisantes. En vrai, des optimisations sérieuses vont bien au-delà de ce genre d’astuces (on peut par exemple dessiner toutes les tuiles d’un seul coup), mais je ne vais pas m’étaler sur ce sujet que je ne maîtrise pas spécialement.

Quant à la forme, ça manque franchement d’efforts. Beaucoup de fautes d’orthographes, de problèmes de mise en forme, d’abréviations mal placées, de phrases peu travaillées, etc.

Salut,

C’est un sujet intéressant.

Je pense que ça pourrait être mieux de faire un tutoriel un peu plus vaste quitte à expliquer ce que c’est que le Tile Mapping, comment procéder de façon simple, quels peuvent être les moyens d’aller plus vite (utilisation de Tiled par exemple) et quelles sont les limites et les solutions. Comme le dit FougereBle du pseudo-code ou même du code serait le bienvenue.

Sinon, comme le souligne Olybri, la forme mérite d’être retravaillée.

Bon courage,

Quelques soit votre langage de programmation et les librairie utilisé, Vous devriez stocké votre carte dans un tableau à 2 dimensions de sorte que pour accéder à une tile en particulier vous feriez :

Ce n’est pas correcte.

La solution du tableau multi-dimensionnel n’est pas la seule. Tu peux faire : map[(width * y + x) << nbrLayer + l].

Si tu souhaites faire quelques choses de plus vaste, il te reste à expliquer la méthode de l’autotiles pour optimiser tes cartes.

Elle consiste à générer automatiquement les angles.

Chaque case se divise en 4 coins, ces coins vont évoluer indépendamment en comparant les 8 cases voisines adjacentes et en diagonales. Pour chaque angle, il faut comparer la case en diagonale voisine et les 2 cases adjacentes voisines.

Chaque coin à un état qui peut varier entre deux valeurs de l’eau VRAI (1) ou de la terre FAUX (0). Ainsi il y a 2 possibilités par coins donc il y aura 2 x 2 x 2 x 2 = 16 situations possibles. Ce qui nous permet d’obtenir un nombre composé de 4-bit : B₃ B₂ B₁ B₀. Chaque bit B_i correspond à un coin, dans cette ordre : supérieur-gauche, supérieur-droite, inférieur-gauche et inférieur-droite.

Le nombre obtenu par la combinaison des 4-bit permet de définir l’index de la situation à laquelle on fait face. Si on suit l’ordre B₃ B₂ B₁ B₀ les situations sont ordonnés comme ceci : 0000 : 0 ; 0001 : 1 ; 0010 : 2 ; 0011 : 3…

Pour identifier la situation il faut comparer les 8 cases voisines adjacentes et en diagonales. Pour un coin, il faudra comparer la case en diagonale voisine et les 2 cases adjacentes voisines.