Pour Reckless Squad nous utilisions simplement des fichiers Lua contenant toutes nos données, un peu à la manière du JSON. Pour moi c’était suffisant, mais c’est parce que je ne m’occupais pas franchement de l’équilibrage. Ce n’est que vers la fin du développement qu’on a ressentis le besoin de mettre les données en relation les unes avec les autres et d’avoir une vue d’ensemble. Franck a donc rassemblé toutes nos données dans un joli tableau Excel, mais on devait toujours reporter les changements aux fichiers Lua. Non seulement il y a un risque d’erreur assez fort (du genre se tromper de ligne) mais en plus il n’a pas fallut longtemps avant que les deux sources cessent d’être synchros.

On a fait avec, mais pour ce projet là je voulais faire les choses différemment. Au tout début j’utilisais Excel pour traiter des fichiers CSV, mais cela posait deux problèmes :

1. Un fichier CSV ne permet pas d’utiliser tout le potentiel d’Excel.
2. A chaque enregistrement du fichier il fallait répondre ‘oui’ a une série de messagebox. C’est devenu pénible assez vite.

La solution était de copier/coller le tableau Excel dans un fichier texte. Cela donne quelque chose de similaire au CSV, juste avec des tabulations plutôt que des point-virgules.

Mais ça reste une opération manuelle, rapidement agaçante, et il est facile d’oublier une colonne ou une ligne lors de la sélection.

J’ai donc décidé de retrousser mes manches et de m’attaquer à une vraie solution : écrire un utilitaire pour exporter les données d’un fichier Excel au bon format.

C# est tout naturellement la solution. J’ai créé un projet console et ai ajouté la référence “WindowsBase.dll” qui permet d’utiliser le namespace System.IO.Packaging. Comme le nom l’indique, on va manipuler des archives ZIP. Ou pour être plus précis, des archives XLSX.

Depuis Office 2007, Word et Excel utilisent le format Office Open XML qui est relativement similaire au Open Document. L’idée c’est que le document est constitué de plusieurs fichiers XML contenus dans une archive ZIP. System.IO.Packaging va donc nous permettre d’accéder à ces fichiers XML à l’intérieur de notre XLSX. Les specs du format font plus de 6000 pages, mais la partie qui nous intéresse est simplissime, un rapide coup d’œil aux fichiers XML (après les avoir réindentés) permet de comprendre comment ça marche.

La première chose qui peut surprendre, c’est que les cellules contenant du texte ne stockent pas le texte en question mais un nombre. Il s’agit de l’index vers une table contenant toutes les chaines de caractère du document. Probablement pour des raisons d’optimisation, comme on le fait souvent dans les jeux vidéo d’ailleurs. La première étape est donc de récupérer ces chaines qui sont dans le fichier /xl/sharedStrings.xml :

Le XPath “*/*/*” devrait être “sst/si/t” mais pour une raison que je ne m’explique pas, ce dernier ne fonctionne pas. En utilisant les jokers à la place ça fonctionne avec tous les fichiers Excel que j’ai pu tester, donc je vais pas chercher plus loin.

Maintenant que nous avons notre table de chaînes, on va pouvoir s’attaquer à la feuille de calcul en elle même. Un même document Excel peut avoir plusieurs feuilles, et elles sont stockées dans le dossier /xl/worksheets/. Même procédure que plus haut pour charger le fichier XML en mémoire. Le noeud qui nous intéresse est sheetData qui contient une liste de noeuds row, eux même contenant des noeuds c (pour cell).

Simple, pas vrai ?

Bon il y a deux trois trucs auxquels il faut faire attention. Dans mon cas je veux charger ma feuille de style dans un tableau à deux dimensions, il faut donc garder ça en tête :

• Excel saute les lignes vides. Le numéro réel de la ligne est fournit par l’attribut r.
• De même, les colonnes de droite vides ne faisant pas parties d’un tableau ne sont pas présentes.

C’est facile à contourner, je me contente de repérer de tels cas et d’ajouter des cellules vides jusqu’à ce que j’ai un beau tableau 2D.

Excel stocke deux informations par cellule : la valeur (<v>) et la formule (<f>). Dans mon cas la formule ne m’intéresse pas, je veux juste le résultat final, je ne récupère donc que la valeur. L’attribut t (type) d’une cellule indique s’il s’agit d’une chaine de caractère ou d’un nombre. De ce que j’ai pu voir, il n’est présent que pour les chaines de caractère (t=”s”). S’il n’y est pas c’est que c’est un nombre.

Comme j’ai besoin de faire la distinction entre int et float pour exporter en binaire, je regarde s’il y a un point dans la chaine de caractère. Si c’est le cas, toute la colonne contient des floats (même si les autres nombres sont entiers).

Dans le cas d’une chaine de caractère, c’est aussi un nombre que vous trouverez. C’est l’index de la chaine dans la table que l’on a créé plus haut.

A ce moment là nous avons déjà un tableau contenant l’intégralité de notre feuille de calcul. J’ai rajouté une fonction pour séparer la première ligne du reste du tableau et la considérer comme un en-tête :

Cependant, mes fichiers Excel contiennent dans une même feuille plusieurs tableaux, par exemple je me sert des stats du joueur pour déterminer celles des monstres. J’ai donc un tableau contenant les dites stats, et je ne souhaite pas l’exporter. J’ai aussi d’autres colonnes dans mon tableau de monstres qui ne sont pas pertinentes et qui servent uniquement pour les formules. Ce que je veux, c’est n’exporter qu’un sous-ensemble de ma feuille de calcul.

Comme nous avons fait en sorte de stocker nos cellules dans un tableau à deux dimensions, extraire un sous-ensemble est trivial :

Le tableau s’indexe comme n’importe quel tableau 2D (y*width+x), et avec ça je peux donc extraire juste la partie qui m’intéresse.

Enfin, l’export. Mon utilitaire exporte au même format que le copier/coller, l’avantage c’est qu’il le fait tout seul comme un grand quand je lance mes scripts de compilation. Je peux donc utiliser cette ligne de commande pour exporter un sous ensemble du tableau :

XLS2BIN.exe txt “Data.xlsx” “Monsters.txt” sheet1 true 0 20 18 22

Cool.

J’ai aussi codé une fonction permettant d’exporter directement en binaire, ce qui peut être intéressant pour les petites tables triviales. Mais il est plus probable que vous ayez besoin de traiter ces données, par exemple dans mon cas le tableau des monstres contient une colonne “animation d’attaque”. L’animation est spécifiée avec une chaine de caractères (ex: “sword”) mais j’utilise un autre script pour remplacer cette chaîne par l’ID de l’animation. Cela a plusieurs avantages :

• Données plus compactes et temps de chargement plus court, ce qui est important sur un smartphone.
• Possibilité de vérifier les données et de tout arrêter si l’animation “swrod” (au lieu de “sword”) n’a pas été trouvée.

Cet autre script recrache toutes les données du jeu dans un unique fichier binaire, et c’est la seule chose que le jeu en lui même connaisse. Pas besoin de parser des chaines de caractère, toutes les données sont déjà dans le bon format. Je développe pour Windows Phone 7 et utilise donc C#, ce qui m’oblige à récupérer les données avec un BinaryReader, mais si vous utilisez du bon vieux C ou C++, un simple fread peut suffire pour charger l’ensemble des données dans une structure. Faites juste attention à ne pas avoir des champs de taille variable.

Bon arrivé là je vais quand même vous passer ce petit utilitaire, avec ses sources. Je l’ai fait à l’arrache, c’est assez peu documenté et il est possible que ça ne fonctionne pas avec tous les fichiers Excel. D’ailleurs, j’ai utilisé Excel 2007, je n’ai aucune idée si ça fonctionne avec 2010. Lancez-le sans argument pour voir la liste des paramètres attendus.

Télécharger

Enfin, comme jamais rien n’est parfait en ce bas monde, il reste un problème avec cette méthode. A vrai dire il reste un problème avec toute méthode impliquant Excel : il locke les fichiers tant qu”ils sont ouverts. La fonction File.Open (même en read only) va donc échouer si le fichier est déjà ouvert par Excel. Devoir quitter et relancer Excel à chaque fois qu’on veut tester les nouvelles valeurs est, disons-le franchement, super chiant. Si quelqu’un connait un moyen pour éviter ça, je rêve de l’entendre.

Cet article est une traduction en français légèrement revue d’un article technique que j’ai écrit l’an dernier pour le site de D2P Games.

Pour Reckless Squad nous voulions un jeu qui soit hautement rejouable. Pour cela nous devions générer aléatoirement beaucoup de choses, de cette façon, le jeu continue de se réinventer lui même.

C’est aussi un gros avantage pour nous, développeurs, parce qu’on ne peut pas vraiment se permettre de réaliser toutes les maps du jeu à la main (même si on en a déjà fait pas mal pour les missions).

Alors comment marche notre algorithme ?

Dans Reckless Squad, chaque map est un “chemin” allant d’un point de départ à un point d’arrivée. Mais nous voulions ajouter quelques cavités pour le rendre plus naturel.

La première étape a été de choisir où commencera le chemin. Nous avons choisis le côté gauche de l’écran, parce que c’est ce à quoi nous sommes habitués dans les cultures occidentales : nous lisons de gauche à droite. Ce point de départ sera alors situé sur l’un des bords de l’écran. Nous déterminons la position exacte aléatoirement.

Une fois que nous avons ce point de départ, nous avons besoin d’un point d’arrivée. Même technique, sauf que le point se situe maintenant sur le côté droit de l’écran.

Nous avons également décidés que le chemin passerait toujours pas le centre de la map, donc j’ajoute ce point entre les deux autres. A ce moment là, j’ai déjà trois points qui forment mon chemin :

La map est une grille 2D, comme vous pouvez le voir les points sont “dessinés” dessus avec des croix.

J’itère ensuite sur les points, deux par deux, et trouve un nouveau point entre chacun d’eux. Ensuite je le déplace légèrement et aléatoirement tout en faisant attention à ce qu’il reste bien à l’intérieur de la map :

En gris vous pouvez voir l’ancien chemin, le nouveau est en blanc. Je répète l’opération :

Encore et encore :

Et après beaucoup d’autres itérations, j’ai le contour de ma map :

En noir, la “zone bloquante” et en blanc le chemin.

Il est possible de contrôler les différents paramètres de l’algorithme, comme le nombres d’itérations, la distance autorisée entre chaque points et la taille de la map pour obtenir des résultats très différents. Par exemple, voici un niveau que se devait d’être long :

Maintenant je veux “habiller” la map de façon à ce qu’elle soit jolie : ma première étape consiste à séparer les “éléments isolés” du reste de la “zone bloquante”. Les éléments isolés seront représentés par des arbres, des rochers, etc. Ils sont en vert sur cette image :

Arrivé là, je vais ajouter du “volume” aux maps car Reckless Squad utilise une perspective vue de dessus de 4/3 comme les vieux RPG 2D.

J’ai décidé que les deux tiles les plus basses seront vues de face, et le reste du dessus. Souvenez-vous des maps de la bonne vieille ère SNES :

La partie en rouge constituera la “zone bloquante”, vue de dessus. La partie verte est la bordure qui fait la transition entre cette zone et ce que j’appelle “la falaise”, à savoir la partie bleue. Il s’agit du mur vu de face.

J’applique le même principe aux maps de Reckless squad :

La bordure est ici dessinée avec cette atroce couleur rose, les deux tiles en dessous représentent la falaise.

Une fois que toutes mes tiles sont marquées “herbe”, “zone bloquante”, “bordure”, “falaise” ou “élément isolé”, je peux leur ajouter des images. Cette partie est plutôt simple : je colle des sprites par dessus. Les sprites sont triés par calques pour conserver l’effet de perspective : les unités sont dessinés par dessus l’herbe et la falaise, mais sous la zone bloquante et la bordure.

Et voilà le résultat final !

Bien que générée aléatoirement, cette map peut être retrouvée et recrée à loisir grâce au numéro que vous voyez en haut à gauche sur les captures d’écran précédentes. Il s’agit de la “seed”, le nombre qui détermine le tirage des nombres aléatoires.

En effet, ce n’est un secret pour personne mais les ordinateurs n’ont absolument aucune imagination et les nombres aléatoires sont en réalité des listes prédéfinies. La seed (graine) détermine quelle liste de nombres utiliser. En spécifiant la même seed à notre algorithme, il produira exactement le même résultat.

Et petit bonus qui n’était pas dans l’article originel, une fois que la map est générée, j’applique le pathfinding entre le point de départ et le point d’arrivée pour déterminer le chemin qu’empruntera le convoi. Cela me permet de dessiner la route que vous voyez sur la capture d’écran précédente, elle permet au joueur d’anticiper les mouvements du convoi qu’il doit protéger.

Mais ce n’est pas tout, a partir de là, je peux appliquer un coefficient à chaque tile pour savoir sa distance par rapport à ce chemin idéal. Cette distance me permet de positionner les coffres légèrement en retrait du chemin, forçant le joueur à abandonner temporairement son convoi et le mettre en danger pour aller les chercher.

Voilà ! Je pense traduire d’autres articles que j’avais écris à l’époque, donc stay tuned !

Même si je me débrouille bien dans Smash Bros et Soul Calibur, je suis quand même incapable de battre Bison dans Street Fighter II et les raccourcis vers les combos sur le stick droit de la manette est la seule raison pour laquelle j’arrive à avancer dans BlazBlue. Et si je joue contre quelqu’un qui s’investit vraiment dans le jeu, je me fais systématiquement massacrer

Mais cela ne m’empêche pas d’être émerveillé par de tels jeux. Je pense que ça vient en partie du fait que l’on dispose d’une large gamme de personnages, tous uniques. Aussi bien sur leur backstory, que leur design ou leurs coups. Et si un type de jeu me fascine, vous pouvez être sûr que je vais essayer d’en faire un, ou au moins de comprendre comment ça marche.

J’ai donc réalisé une petite démo de jeu de combat, une sorte de prototype avec peu de fonctionnalités, pour voir un peu les dessous de la chose. Et voici mon parcours.

Contrôles et physique

J’ai décidé pour ce prototype d’inclure les actions suivantes :

• Se déplacer (courir)
• Sauter
• Se baisser
• Attaque horizontale
• Garde

J’ai changé le repère en mettant le zéro sur Y au niveau du sol et en inversant l’axe, ainsi sauter augmente la composante Y, et il n’est pas possible de descendre sous 0 (le sol).

J’ai ensuite une fonction qui transforme une telle coordonnée monde en coordonnée écran, pour afficher les sprites au bon endroit.

La physique est gérée avec deux vecteurs 2D : la position et la vélocité du combattant.

Pour déplacer le personnage, j’ai juste à modifier sa vélocité. Courir reviens à changer la vélocité sur X (300 et -300 actuellement) et pour s’arrêter il suffit de la remettre à zéro. De même, sauter revient à définir la vélocité sur Y (800, il faut que ce soit assez “fort” pour dépasser la gravité).

Link s'accroupit et Marth se protège

A chaque mise à jour de la simulation physique, j’ajoute à la position le produit entre la vélocité et le temps écoulé depuis la dernière frame (le delta time, en secondes) et réduit légèrement la vélocité avec la “décélération” qui augmente au fur et à mesure que le temps passe. Cela permet d’annuler la vélocité de façon fluide, ça fonctionne un peu comme la friction de l’air.

De même j’applique la gravité qui se fait de plus en plus forte, comme à la décélération. Lorsque le personnage touche le sol, je cesse d’appliquer la gravité et je remet les forces de décélération et de gravité à leur valeur d’origine.

Il est important de préciser que je traite les deux axes séparément, c’est bien plus simple comme ça.

Animations #1

Ma première implémentation du système d’animation est simple et se base sur des sprite sheets. Elle est en réalité tellement simple que je n’avais qu’une seule frame par animation.

(Les sprites viennent de The Spriters Resource et le fond de BlazBlue)

Une animation est composée d’une ou plusieurs frames, et le personnage ne peut avoir qu’une seule animation courante. Par défaut c’est “Idle” : le personnage se tient debout, sans bouger. Puis chaque action a sa propre animation, qu’elle soit déclenchée par l’appuie d’une touche (le saut, courir, etc), par la physique (retomber) ou par un évènement (se faire blesser).

En fonction de l’animation courante, les actions possibles changent. Par exemple il n’est pas possible de s’accroupir en même temps que l’on saute, et quand on est touché, on ne peut rien faire.

Marth en plein saut

Hitboxes

Chaque frame d’une animation a une liste de hitboxes, qui ne sont en réalité que des rectangles. Ces hitboxes sont divisées en 3 catégories :

• Les bleus sont capables de prendre des dégâts
• Les rouges infligent des dégâts si elles touchent une bleu
• Les vertes bloquent les attaques

Si une frame n’a pas de hitbox, elle ne peut rien faire. C’est le cas par exemple des frames lorsqu’un ennemi est touché, il est invulnérable pendant un certain temps.

Après avoir pris une attaque, Marth est invulnérable pendant un court instant

Les collisions sont testées entre les différentes hitboxes et soustraire la position du joueur à celle de l’ennemi permet d’obtenir le vecteur direction de l’attaque afin de propulser la cible dans la bonne direction. J’imagine que spécifier ce vecteur à la main pour chaque attaque est une meilleure idée, cela permettrait plus de souplesse (on choisit la direction où on veut que l’adversaire soit éjecté), mais pour l’exemple courant cela suffit.

Intelligence artificielle

L’IA fonctionne comme une simple machine à états, tellement simple qu’elle est réalisée avec une série de if/else.

En fait elle est aussi simple qu’inefficace : l’ennemi se rapproche du joueur jusqu’à être à sa portée, et décide alors de réaliser une action au hasard entre attaquer, sauter, se baisser et se défendre. Vraiment, qui espère gagner un combat comme ça ?

Je n’ai pas encore eu le temps de vraiment me pencher sur cette partie là, donc pour le moment ça restera comme ça.

Toutefois je pense qu’une machine à état devrait être suffisant pour faire une bonne IA, à condition qu’elle soit bien pensée et assez complète bien sûr.

Animations #2

L’inconvénient des sprite sheets, c’est que ça demande beaucoup de boulot, et beaucoup de mémoire. Et si vous augmentez la résolution, ce qui devient une nécessité avec les écrans d’ajourd’hui, vous augmentez le temps nécessaire pour créer chaque frame ainsi que le poids de chaque image.

Une autre solution, est d’emprunter une technique du monde de la 3D : l’animation squelettale.

On commence par découper notre personnage en plusieurs parties :

Puis on les rassembles et les animes, comme on le ferait avec un système d’animation 3D à base des bones.

Bien réalisée, l’animation squelettale peut être complétement transparente et bluffante.

Les jeux Vanillaware en sont l'exemple parfait

Mal réalisée, cela donne un effet “marionnette” complètement ridicule. Bon malheureusement, ce que je vais vous montrer à l’instant tombe dans cette catégorie.

Pour être bien réalisé, il faut :

• Bien sûr, permettre la rotation de chaque bone (c’est la base)
• Permettre également la translation
• Ainsi que la la mise à l’échelle
• Et enfin permettre le changement d’image associée à chaque bone

Ensuite avec de la patience, du temps et des compétences on peut arriver à l’exemple ci-dessus.

Voici une capture d’écran de mon éditeur d’animation :

Cliquez pour voir en grand

Sur la gauche, on a la liste des “parts”, il s’agit d’une image qui se comporte comme un bones.

En dessous, il y a un petit espace pour configurer la “part” sélectionnée, notamment le point d’origine du bone par rapport à l’origine de l’image, la position par rapport au bone parent (et le bone parent en question) et enfin l’ordre d’affichage (Z).

Sur la droite, c’est la liste des animations.

Comme il n’y a pas d’interpolation pour le moment, on peut changer la durée de chaque frame séparément. Ensuite il est possible de changer l’angle de rotation de chaque “part”.

Si vous faites attention, vous verrez derrière un autre sprite légèrement transparent, il est là pour l’onion skinning. Il s’agit de la frame précédente, affichée pour servir de repère.

Le personnage présenté est décalqué inspiré de Ragna, de BlazBlue.

Seulement tout ça n’a d’intérêt que si on affiche quelque chose à l’écran ! On va donc voir dans cet article comment sont décrites les formes géométriques que l’on affiche en 3D.

Les primitives

Les primitives sont les formes de base qui nous serviront à décrire toute notre géométrie. Elles sont très simples et permettent de faire déjà beaucoup de choses.

• Les Points : de simples points dans l’espace, on peut leur donner une épaisseur
• Les Lignes : des lignes.
• Les Triangles : c’est la primitive principale, la plus utilisée.
• Les Quadrangles : Comme un triangle mais avec quatre côtés.
• Les n-gones : très peu utilisés pour la 3D temps réel, ce sont des polygones qui ont n côtés (plus de 4, sinon ce sont des triangles ou des quadrangles). Je ne m’attarderai pas là dessus car leur usage en 3D temps réel est extrêmement marginal (pour ne pas dire inexistant).

Mis à part les n-gones, les cartes graphiques actuelles sont capables d’afficher directement toutes ces primitives. Cela n’a pas toujours été le cas, et beaucoup d’anciens modèles de cartes découpent les quadrangles en deux triangles.

D’une façon générale, les triangles permettent de représenter un vaste panel de formes, et tous les jeux actuels sont basés sur eux.

On préfèrera donc utiliser uniquement des triangles pour le rendu, par soucis d’homogénéité. En revanche, rien n’empêche d’utiliser des quadrangles lors de la modélisation, pour “y voir plus clair”.

A gauche, le sac lors de la modélisation. A droite, lors du rendu en utilisant uniquement des triangles.

Vertices

Les vertices (singulier vertex, sommet en français) sont des points dans l’espace 3D qui définissent une forme. Ces points sont les sommets de nos primitives.

Un seul vertex suffit à définir un point, deux font une ligne, trois un triangle et quatre un quadrangle.

Les points en orange sont les vertices

Ces vertices peuvent être partagés et servent à former plusieurs primitives (comme c’est le cas sur l’image au dessus).

Dans ce cas il va falloir dire au programme quels vertices forment une primitive, pour cela on utilisera des indices.

Indices

Un tableau de vertices, aussi nommé vertex buffer

Les indices (singulier index) servent à décrire nos primitives.

Imaginons que nous souhaitions partager nos vertices pour économiser de la mémoire (un seul vertex sera utilisé pour 3 ou 4 triangles par exemple), nous allons les stocker dans un tableau appelé vertex buffer (voir ci-contre).

Les indices correspondront à la colonne ID. On compte toujours à partir de 0, ainsi le premier élément dans le tableau aura l’index 0, le second 1, le troisième 2, et ainsi de suite.

On utilisera donc ces indices pour décrire notre primitive, si on veut par exemple décrire un triangle, on dira que ses trois sommets sont les vertices numéro 0, 4 et 6 (au hasard).

La carte graphique va donc regarder dans le vertex buffer à quoi correspondent ces indices. 0 ? c’est 0,0,0. 4 ? c’est 100,3,45. 6 ? 12,30,0.

Et avec ça elle va donc afficher notre triangle. Plusieurs primitives peuvent donc ré-utiliser les même indices, et donc les même vertices.

On fournit cette liste de vertices à la carte graphique à travers un autre tableau que l’on nomme logiquement index buffer.

Mais les indices ne servent pas seulement à partager des vertices, ils permettent par exemple de choisir la géométrie à afficher.

Imaginons que l’un de vos personnages porte un fourreau à la ceinture, et que dans certaines circonstances vous souhaitez ne pas l’afficher : il vous suffira de retirer les indices décrivant le fourreau de votre index buffer

Textures

Les textures servent à ajouter du réalisme aux modèles 3D. Et parce qu’une image vaut mieux qu’un long discours, voyez vous même :

A gauche sans textures, à droite avec.

Les textures servent donc à ajouter des détails par dessus nos modèles.

Une texture n’est qu’une simple image :

La texture du modèle présenté plus haut

On voit tout de suite le challenge : il faut faire correspondre un modèle 3D à une image 2D… pour cela on doit l’aplatir !

On appelle cela le dépliage d’UV ou UV Unwrapping, c’est une technique qui consiste à faire correspondre à chaque vertex un point sur la texture. Je ne vous cacherai pas que c’est une étape très longue et fastidieuse, heureusement des outils de plus en plus perfectionnés permettent d’automatiser ou de simplifier la tâche.

Le dépliage d'UV : on fait correspondre un point sur la texture à chaque vertex

Ces coordonnées de textures sont exprimées entre 0 et 1 :

Le coin supérieur gauche de la texture correspond à 0,0 et le coin inférieur droit à 1,1

Je vais couvrir les principaux concepts utilisés en 3D de façon à les introduire. Je ne vais pas les expliquer en détail, ces articles sont juste une première étape pour vous permettre d’approfondir vos recherches plus tard.

Ils sont destinés à n’importe qui ayant déjà vu la 3D à l’œuvre (à travers un jeu vidéo ou un film d’animation par exemple) et qui se souvient de ses cours de géométrie du collège.

Ce premier article parlera du monde en trois dimensions et de la façon dont il est affiché sur un écran en deux dimensions.

Un monde en 3D, un écran en 2D

Pour le moment, les écrans (moniteurs comme téléviseurs) sont limités à la 2D. C’est à dire qu’ils ne peuvent afficher que des images planes sur leur surface. Cela viendra surement à changer dans un futur plus ou moins proche, mais pour le moment il faut s’en accommoder. Même la fausse 3D vendue par certains cinémas ces derniers temps n’est qu’une image 2D traitée par des lunettes pour donner un semblant de 3D.

L’enjeu est donc de projeter une scène en 3D sur une image 2D.

Projection d'une scène 3D sur un écran 2D

Cela se fait au moyen d’une caméra : tout comme un cinéaste utilise une caméra pour capturer “le monde réel” en une séquence d’image, nous utiliserons une caméra pour capturer notre scène en trois dimensions.

Les repères

Vous vous souvenez surement de vos cours de géométrie et des repères orthonormés directs, avec les abscisses et ordonnées.

En informatique, les conventions sont légèrement différentes : on considère que le coin haut-gauche de votre écran (ou d’une image) est l’origine. L’axe X est alors l’axe des abscisses (horizontal) et l’axe Y celui des ordonnées (vertical).

Quand on donne des coordonnées (en maths comme en informatique) en commence toujours par l’abscisse (X) puis par l’ordonnée (Y). Le point (10,5) est alors a pour abscisse 10 et 5 pour ordonnée.

La 3D ajoute une nouvelle dimension, la profondeur, que l’on note Z.

Les différents repères

Cependant la façon de représenter les repères en 3D n’est pas normalisée.

Il existe deux tendances principales : main droite (right-handed) et main gauche (left-handed).

Concrètement ce qui change est l’orientation de l’axe Z.

Pour donner un exemple : OpenGL et XNA sont “right-handed” alors que DirectX est “left-handed”.

Certains intervertissent les axes Y et Z (par exemple l’Unreal Engine utilise Y pour la profondeur et Z pour la hauteur), ce n’est qu’une différence de convention, les concepts derrière sont les même.

La caméra

La caméra est définie par plusieurs paramètres :

• Sa position dans l’espace 3D
• La position de sa cible (l’objet qu’elle filme en quelque sorte)
• Son champs de vision (field of view)
• La distance minimale qui définit le “near plane“
• La distance maximale qui définit le “far plane“

Ces informations permettent de définir une pyramide tronquée (un tronc, frustum en anglais) :

Le "View Frustum" défini par la caméra

Le champs de vision (abrégé FOV) est un angle qui définit ce que pourra voir le joueur. Le FOV est également utile pour réaliser un effet de zoom.

Le View Frustum permet d’utiliser une technique nommée Frustum Culling qui consiste à n’afficher que ce qui se trouve entre le “near plane” et le “far plane” :

Frustum Culling, tout ce qui est dans la zone verte est affiché, le reste non

C’est cet effet que vous voyez à l’œuvre quand, dans un jeu vidéo, vous voyez un objet apparaitre soudainement au loin. En réalité l’objet qui se trouvait au delà du “far plane” se trouve désormais dans le view frustum et est affiché. On utilise généralement du brouillard (fog) au loin pour adoucir cet effet indésirable.

Prochainement

Dans le prochain article j’expliquerai comment sont décrites les formes en trois dimensions, pour que vous sachiez comment se décompose le personnage que vous voyez à l’écran.

On parlera de vertices et de triangles, de textures et de normales, etc.

En attendant, si vous avez des remarques, des questions ou des suggestions concernant cet article, les commentaires sont à votre disposition.

Le deuxième article est en ligne !

On va donc voir comment récupérer le vendeur, le modèle de la carte graphique, une liste d’extensions et déterminer la version des shader models implémentée.

Toute se fait au travers de la fonction glGetString.

glGetString renvoit une chaine de caractère contenant des informations fournies par le driver de la carte graphique :

• GL_VENDOR : le vendeur de la carte graphique (ex: NVidia, ATI ou Intel)
• GL_RENDERER : le modèle exact de la carte graphique (ex: GeForce 8600 GT)
• GL_VERSION : la version d’OpenGL utilisée (ex: 2.0)
• GL_EXTENSIONS : une liste d’extensions séparées par des espaces

Récupérer la liste des extensions

C’est surtout cette liste d’extensions qui nous intéresse, mais elle est difficilement exploitable en l’état, on va voir comment se faciliter la vie :

std::set Extensions;

std::string ext = std::string ( (const char*)glGetString ( GL_EXTENSIONS ) );

std::string extension = "";
for ( std::size_t i = 0; i < ext.size(); ++i )
{
	const char& c = ext[i];
	if ( c != ' ' )
		extension += c;
	else
	{
		Extensions.insert ( extension );
		extension = "";
	}
}

Ce code va parcourir la chaine de caractère et rajouter chaque extension dans un std::set.

Pour savoir si une extension est supportée, il ne nous reste plus qu’a vérifier qu’elle est présente dans le set :

bool CheckExtension ( const std::string& extension ) const
{
	return ( Extensions.find ( extension ) != Extensions.end() );
}

On peut désormais tester la présence d’une extension facilement.

Déterminer la présence des shaders GLSL

Les shaders GLSL permettent de programmer la carte graphique à l’aide d’un langage haut niveau similaire au C (voir Les shaders GLSL avec Irrlicht et Cel Shading en GLSL).

Pour déterminer si ces shaders sont disponibles, il faut vérifier la présence de quatre extensions :

• GL_ARB_shading_language_100
• GL_ARB_shader_objects
• GL_ARB_vertex_shader
• GL_ARB_fragment_shader

bool CheckGLSLSupport () const
{
	return (
		CheckExtension( "GL_ARB_shading_language_100" ) && CheckExtension( "GL_ARB_shader_objects"       ) &&
		CheckExtension( "GL_ARB_vertex_shader"        ) && CheckExtension( "GL_ARB_fragment_shader"      ));
}

Déterminer la version des shader models

Il n’y a malheureusement aucune fonction directe pour déterminer le niveau de shader models.

Cependant, a chaque niveau de shaders models correspondent des extensions particulières :

• SM 4:
  • GL_NV_gpu_program4
  • GL_NV_geometry_program4
  • GL_NV_vertex_program4
  • GL_NV_fragment_program4
  • GL_EXT_gpu_shader4
  • GL_EXT_geometry_shader4
• SM 3:
  • GL_NV_vertex_program3
  • GL_NV_fragment_program2
  • GL_ATI_shader_texture_lod

Si vous n’avez ni les SM3 ni les SM4, mais que les shaders GLSL sont disponibles, alors vous avez les shader models 2.

Pour résumer :

int GetShaderModel () const
{
	if (
			CheckExtension("GL_NV_gpu_program4"			) ||
			CheckExtension("GL_NV_geometry_program4"	) ||
			CheckExtension("GL_NV_vertex_program4"		) ||
			CheckExtension("GL_NV_fragment_program4" 	) ||
			CheckExtension("GL_EXT_gpu_shader4"		 	) ||
			CheckExtension("GL_EXT_geometry_shader4"	)
		)
	{
		return 4;
	}
	else if (
				CheckExtension("GL_NV_vertex_program3"		) ||
				CheckExtension("GL_NV_fragment_program2"	) ||
				CheckExtension("GL_ATI_shader_texture_lod"	)
			)
	{
		return 3;
	}
	else if ( HasGLSLSupport() )
	{
		return 2;
	}
	else
	{
		return 0;
	}
}

Et voilà !

Maintenant vous disposez d’un petit arsenal pour mieux détecter les spécificités de la carte graphique, et adapter votre application en conséquence.

Habituellement j’utilise SFML pour le fenêtrage et la gestion des évènements, pour l’affichage j’utilise directement OpenGL (3D oblige).

Mais j’ai décidé de déléguer la gestion et l’affichage du texte à SFML pour deux raisons : TrueType et Unicode.

Si charger une font TrueType est simple et bien décrit dans les tutoriaux, afficher correctement les caractères Unicode est une autre histoire…

Pré-requis

Tout d’abord vous allez avoir besoin d’une font qui gère l’Unicode et propose tous les caractères nécessaires. Mon but était d’afficher les caractères japonnais, j’ai donc utilisé Arial Unicode MS, également utilisée par Firefox.

Font.LoadFromFile ( "arial_unicode.ttf" , 14 );
sf::String sftext ( text , Font , 14 );
Window.Draw ( sftext );

Vous êtes surement familiers avec ce code, il se contente d’afficher le texte text avec la font arial_unicode.ttf de taille 14.

Attention toutefois, text ne doit pas être une std::string si vous comptez utiliser Unicode.

std::string est une chaîne de caractères de type char, de l’ASCII donc. Utilisez donc son équivalent UTF-8 : std::wstring (pour “wide string”).

std::wstring text = L"du texte !";

std::wstring s’utilise comme std::string, à la différence du L qui précède les chaines. Ce L sert à spécifier que la chaîne qui suit utilise l’encodage UTF-8 au lieu de l’ISO-8859-1.

Un exemple avec du texte japonais mélangé à du français (je tire ça d’un dico français/japonais) :

std::wstring text = L"Texte Japonais : 月 【つき ・ tsuki 】 lune";

Si vous utilisez cette chaîne de caractère avec le code précédent, vous verrez que seuls les caractères de l’alphabet latins s’affichent. C’est parce qu’il faut spécifier un charset.

Le charset

Le charset est un tableau d’unsigned int qui spécifie à SFML quels caractères il doit générer à partir de la font. En effet, pour pouvoir afficher du texte, il faut d’abord transformer les caractères en bitmaps. Et si tous les caractères Unicode devaient être rendus en bitmap, non seulement le temps de chargement serait long, mais la mémoire utilisée serait colossale (plus de 160Mo avec Arial Unicode MS de taille 24 !).

SFML nous laisse donc spécifier les caractères que l’ont veut générer, et par défaut ce sont les 256 premiers caractères (qui correspondent aux caractères ASCII et quelques étendus).

Les caractères sont identifiés par leur code (un unsigned int donc), et vous pouvez trouver les codes et leurs équivalents sur le site de l’Unicode : http://unicode.org/charts/.

Chose à savoir, quand vous spécifiez le charset à SFML, le premier code spécifié doit être 0×20, sinon rien ne s’affichera.

Généralement les codes sont organisés en plages, par exemple : de 0×20 à 0xFF pour les caractères Latins.

Voici donc un petit snippet permettant de spécifier un charset à SFML à partir d’une liste de plages :

// ===========================================================================================
/// A range of UTF-8 codes used to generate the final font charset
// ===========================================================================================
struct CharsetRange
{
	/// The minimum UTF-8 code
	unsigned int Min;

	/// The maximum UTF-8 code
	unsigned int Max;

	/// Get the range between the two UTF-8 codes
	unsigned int GetRange () const { return Max - Min + 1; }

	/// Constructor
	CharsetRange ( unsigned int min , unsigned int max ) : Min ( min ) , Max ( max ){}
};

Cette structure représente une plage de codes consécutifs.

// ===========================================================================================
/// A charset is a set of UTF-8 codes organized as ranges
// ===========================================================================================
typedef std::vector<CharsetRange> Charset;

Et ceci est notre charset : une liste de plages.

Maintenant on va récupérer cette liste de plages pour générer un tableau d’unsigned int que l’on spécifiera à SFML lors de la création de la font.

// ===========================================================================================
/// Set the current font
// ===========================================================================================
void SetFont ( const std::string& filename , unsigned int size , const Charset& ranges )
{

	// Determine the number of characters in the charset
	unsigned int totalRange = 0;
	if ( ranges.size() > 0 )
	{
		for ( std::size_t i = 0; i < ranges.size(); ++i )
			totalRange += ranges[i].GetRange();
	}
	else
		totalRange = 0xFF - 0x20;

	sf::Uint32 charset[totalRange];

	// Add the characters to the charset
	int it = 0;
	if ( ranges.size() > 0 )
	{
		for ( std::size_t i = 0; i < ranges.size(); ++i )
		{
			for ( unsigned int character = ranges[i].Min; character <= ranges[i].Max; ++character )
			{
				charset[it++] = character;
			}
		}
	}
	else
	{
		for ( unsigned int character = 0x20; character <= 0xFF; ++character )
		{
			charset[it++] = character;
		}
	}

	// Load the font
	if ( !Font.LoadFromFile ( filename , size , charset ) )
	{
		Font = sf::Font::GetDefaultFont();
	}
}

Et voilà !

Vous remarquerez qu’il y a une vérification : si le vector est vide, on spécifie une plage par défaut.

Et pour ceux qui voudraient afficher des caractères japonais et qui ont du mal à trouver les plages correspondantes aux différents alphabets, les voici :

// ===========================================================================================
/// A list of default charsets
// ===========================================================================================
struct DefaultCharsets
{

	// ===========================================================================================
	/// Return the default charset for european and american characters
	// ===========================================================================================
	static Charset GetDefault()
	{
		Charset ranges;
		ranges.push_back ( CharsetRange ( 0x20 , 0xFF ) );		// ANSI
		return ranges;
	}

	// ===========================================================================================
	/// Return the japanese charset
	// ===========================================================================================
	static Charset GetJapanese()
	{
		Charset ranges;
		ranges.push_back ( CharsetRange ( 0x20 , 0xFF ) );	// ANSI
		ranges.push_back ( CharsetRange ( 0x3000 , 0x30FF ) );	// Hiragana
		ranges.push_back ( CharsetRange ( 0x30A0 , 0x30FF ) );	// Katakana
		ranges.push_back ( CharsetRange ( 0x31F0 , 0x31FF ) );	// Ainu
		ranges.push_back ( CharsetRange ( 0x4E00 , 0x9FAF ) );	// Kanji
		ranges.push_back ( CharsetRange ( 0xFF65 , 0xFFFF ) );	// Halfwidth katakana
		return ranges;
	}
};

Je dois avouer avoir eu du mal à toutes les trouver…

C’est quand même assez incroyable à quel point les choses peuvent être simples quand on dispose de bons outils comme SFML !

Alors D2P ça vient d’un brainstorming de quelques secondes et c’est l’acronyme de “Dax” , “Dri” et “Paul”, les surnoms (ou noms) des membres de l’équipe. Oui je sais, c’est d’une originalité terrible.

Mais on s’en moque de ce qu’est D2P, ce qui nous intéresse c’est ce que fait et va faire D2P : du jeu vidéo.

Pourquoi

Depuis quelques années, le jeu vidéo s’est démocratisé à une vitesse ahurissante et a intégré le quotidien de la plupart des foyers.  En 2004, l’industrie du jeu vidéo pouvait déjà se venter d’avoir dépassé Hollywood. Et la tendance ne s’est pas inversée depuis, bien au contraire, on le voit avec le succès de la Nintendo DS et de la Wii : le marché du jeu vidéo grandit de jour en jour.

Pour notre part, nous avons toujours été passionné de jeu vidéo, personnellement ce fut ma porte d’entrée dans l’univers de l’informatique, alors nous avons décidés de “passer la seconde”, et de nous mettre au travail.

Nos projets

Nous compensons notre faible effectif et le peu de temps que nous avons  (pour le moment nous travaillons sur notre temps libre) par la technique et l’organisation.

La clé d’un travail efficace réside dans la qualité des outils employés, et c’est en grande partie mon rôle de m’assurer que tout aille bien de ce côté là.

Pour commencer, nous voulons toucher un public le plus large possible, nous voulons pouvoir déployer nos jeux sur quasiment toutes les plates-formes possibles et imaginables, avec le moins d’effort possible.

Uniscript est la réponse à ce problème. Uniscript est un langage de script interprété qui fait sien la philosophie de Java : “code once, run everywhere”.

Concrètement, Uniscript est un langage très simple et très léger proposant tout de même le support de la programmation orientée objet. Son avantage par rapport aux autres langages de script est qu’il est très facile d’écrire un interpréteur pour ce langage (il y a peu d’instructions).

Un compilateur nous sert à transformer le code (qui partage en grande partie la syntaxe du C++) en bytecode, pour être ensuite exécuté par des machines virtuelles.

A chaque fois que nous portons nos jeux vers un nouveau support, nous créons une nouvelle machine virtuelle spécifique à ce support. Le code du jeu ne change absolument pas.

Un système d’extension nous permet de profiter de fonctionnalités en plus, offertes par certains supports.

Notre premier projet utilisant Uniscript sera un jeu orienté pour le web (Flash), à priori on se tournerait vers un shoot em up, même si nous ne sommes encore que dans la phase de conception et que tout peux changer.

Les plans pour le futur

Nous envisageons de monter une véritable structure l’an prochain (aux alentours de novembre surement) afin de travailler de façon plus officielle, et surtout à mi-temps (et non plus sur notre temps libre).

Les choses devraient donc s’accélérer à ce moment là.

En attendant, vous trouverez des informations régulièrement sur le blog de Paul : My Game Is Rich et bien sur, ici même. Alors comme on dit, stay tuned !

PS : si Paul avait pu, c’est à Los Angeles qu’il aurait fait l’annonce je pense :p

Le cel shading, c’est l’ “effet cartoon” que vous pouvez voir à l’œuvre dans Jet Set Radio ou Zelda The Wind Waker.

Le nom de cet effet viens des cellulos utilisés lors de la création d’un dessin animé, ce sont des feuilles de papier transparentes dont on peint le verso afin de colorier les personnages tracés au recto.

Toutefois, je n’expliquerai que la création du dégradé, pas des bordures noires. Ces dernières sont un autre sujet, passablement plus compliqué.

Je pars du principe que vous avez quelque base en GLSL, au moins savoir comment réaliser un shader tout simple (par exemple colorier un modèle en rouge).

Tout d’abord, analysons l’effet :

Capture d'écran de Zelda The Wind Waker

Ce qui donne cet effet cartoon, c’est avant tout les textures unies, les modèles non réalistes et les couleurs pastelles. Le but du shader sera d’appliquer les ombres sur le modèle 3D. Contrairement au rendu dit “photo-réaliste”, le cel shading emploie des ombres franches, bien marquées, comme dans les dessins animés.

Le Vertex Shader

Le vertex shader est ici très simple, puisqu’il ne fait rien de spécial.

varying vec3 Normal;

void main(void)
{

// Front color
gl_FrontColor = gl_Color;

// Determine the normal of the vertex
Normal = gl_NormalMatrix * gl_Normal;

// Textures coordinates
gl_TexCoord[0] = gl_MultiTexCoord0;

// The position of the vertex
gl_Position = ftransform();

}

Si vous êtes un minimum familier avec GLSL, ce code vous sera sans doute très parlant. Il fait le minimum que l’on exige d’un vertex shader : transformer les sommets, récupérer les coordonnées de texture et déterminer les normales.

La variable Normal sera passée au pixel shader grâce au mot-clé varying.

Le Pixel Shader

Voyons maintenant un pixel shader tout simple, qui affiche le modèle 3D de façon unie :

uniform sampler2D Texture0;

varying vec3 Normal;
void main (void)
{

vec4 color = texture2D( Texture0 , vec2( gl_TexCoord[0] ) );

gl_FragColor = color;
}

Une fois de plus, le code est vraiment très simple : il se contente de récupérer le pixel sur la texture aux coordonnées données, puis déclare que c’est ce pixel là qui sera utilisé pour l’affichage.

Remarquez que l’on retrouve notre variable Normal qui est la normale du sommet, on va en avoir besoin pour réaliser le cel shading.

Comme tout modèle d’éclairage, le cel shading a besoin d’une lumière pour fonctionner. Pour faire simple, on va se content de gérer une seule source de lumière, incolore.

On va donc rajouter dans la déclaration des variables la direction de la lumière  :

uniform vec3 LightDir;

En général, on s’en sert pour représenter le soleil.

Créons maintenant une nouvelle fonction :

vec4 CelShading ( vec4 color )

{

return color;

}

que l’on va appeller comme ceci :

void main (void)
{

vec4 color = texture2D( Texture0 , vec2( gl_TexCoord[0] ) );

color = CelShading ( color );

gl_FragColor = color;
}

C’est dans cette fonction que l’on appliquera l’effet du cel shading. L’avantage de le faire dans une fonction plutôt que directement dans main est multiple :

• Vous pouvez rajouter une couche de “pré-processeur” à votre code qui gère les programmes afin de réaliser un équivalent du #include du C/C++ : dans ce cas vous pourrez séparer vos différents effets dans différents fichiers.
• Et ainsi mélanger les effets entre eux facilement, par exemple :

color = RimLighting ( color );
color = CelShading ( color );

(Pour info, le Rim lighting est la technique appliquant à un modèle 3D une fausse lumière semblant venir de derrière lui. Mario Galaxy l’utilise sans cesse)

Revenons à notre fonction, on va calculer l’intensité de la lumière à un point donné :

float Intensity = dot( LightDir , normalize(Normal) );

C’est actuellement la partie la plus compliqué du cel shading (si si !).

On fait un produit scalaire entre le vecteur tracé entre la direction de la lumière, et la normale de notre sommet. Cela nous retourne l’intensité de la lumière sur ce dit sommet.

Mon but n’est pas d’expliquer la partie mathématique derrière tout ça… je pense que j’en serai bien incapable !

L’intensité est une valeur entre 0 et 1. 0 signifie pas éclairé, et 1 entièrement éclairé.

Prenez le temps d’essayer ce code :

vec4 CelShading ( vec4 color )
{
float Intensity = dot( LightDir , normalize(Normal) );

float factor = Intensity;

color *= vec4 ( factor, factor, factor, 1.0 );

return color;
}

On a alors un ombrage de Gouraud (gouraud shading), les ombres sont douces, il y a un dégradé.

Notre but sera de “casser” ce dégradé pour faire des ombres franches.

Comment faire ? C’est très simple : en testant la valeur de l’intensité non plus comme une valeur linéaire, mais comme des bornes.

vec4 CelShading ( vec4 color )
{
float Intensity = dot( LightDir , normalize(Normal) );
float factor = 1.0;
if ( Intensity < 0.5 ) factor = 0.5;
color *= vec4 ( factor, factor, factor, 1.0 );

return color;
}

Si l’intensité est inférieure à 0,5 (la moitié), alors on obscurcit le pixel, sinon (si c’est au dessus), on le laisse tel quel.

L’effet est là :

L'effet de cel shading

Il est désormais possible de faire des réglages, par exemple en rajoutant plusieurs étapes au dégradé :

float factor = 0.5;

if      ( Intensity > 0.95 ) factor = 1.0;
else if ( Intensity > 0.5  ) factor = 0.7;
else if ( Intensity > 0.25 ) factor = 0.4;

Maintenant c’est à vous d’expérimenter !

Rassurez-vous, ce qui est fait n’est plus à faire et cet article (ainsi que ceux qui suivront) seront plus simples et plus intéressants.

Maintenant que vous voilà rassurés, place à la 2D !

Notre but dans cette étape est de gérer l’affichage dans notre programme et d’afficher une image à l’écran.

Cela n’a rien de compliqué, bien au contraire.

La théorie

Avant d’implémenter quoi que ce soit nous devons comprendre comment fonctionne un jeu.

Un jeu est en perpétuelle évolution, il est sans arrêt mis à jour. L’emploi d’une “boucle infinie” qui ne s’arrête que lorsque le jeu est quitté est la base de tout jeu vidéo.
Voyons les différentes étapes en détails :

Initialisation : c’est dans cette étape que nous chargeons nos ressources : images, sons, modèles 3D, etc. Nous préparons le terrain pour la suite, c’est le chargement du jeu.

Traitements : la gestion du jeu en lui même. C’est cette partie qui s’occupera de prendre en charge les contrôles du jeu. C’est là qu’intervient toute la logique du jeu, comme l’IA par exemple.

Affichage : maintenant que la situation du jeu est à jour, il faut que le joueur en ai un retour. C’est le but de l’affichage : envoyer au joueur une image qui reflète la situation actuelle. C’est sur cette partie que nous allons nous concentrer cette fois-ci.

Libération : sous entendu, des ressources. On fait le ménage en quelque sorte, on passe le balais après la fête. Il s’agit de détruire toutes les ressources chargées et de rendre la main au système.

Si vous regardez bien, la partie “libération” mise à part, cela correspond exactement aux trois méthodes de l’objet GameManager créer précédemment :

protected override void Initialize ()
{
	base.Initialize ();
}

protected override void Update ( GameTime gameTime )
{
	base.Update ( gameTime );
}

protected override void Draw ( GameTime gameTime )
{
	base.Draw ( gameTime );
}

XNA s’occupe donc déjà de mettre en place cette boucle de jeu, tout ce que nous avons à faire c’est compléter ces trois fonctions.

Il sera peut être nécessaire de rajouter une méthode “Delete” à notre objet GameManager, mais pour le moment le Garbage Collector du framework .NET fera très bien l’affaire.

Revenons-en donc à notre boucle infinie, et notamment à la partie “affichage”.

Pour bien comprendre comment marche l’affichage dans un jeu vidéo, il faut comprendre le double buffering.

Le principe du double buffering est simple : afficher une image prend du temps, on ne peut donc pas se permettre de l’afficher directement à l’écran. Ou alors le joueur verrait l’image se construire sous ses yeux, très rapidement, ce qui provoquerait un scintillement permanent des plus déplaisants.

Il faut donc tout dessiner sur un autre écran, caché, et permuter les deux lorsque tout est prêt. C’est le principe même du double buffering : dessiner sur le back buffer (la mémoire de la carte graphique) puis échanger avec le front buffer (l’écran).

Cette notion est très importante.

Une fois que les deux buffers ont été permutés et que l’image finale apparait à l’écran, il convient de dessiner la suivante. Pour cela nous devons d’abord effacer la précédente qui est restée dans le buffer.

Ensuite nous redessineront notre scène, puis nous invertirons de nouveau les buffers. Et bis repetita.

L’opération doit se faire au moins 24 fois par secondes pour que l’animation soit crédible et que l’œil la voie bien comme une animation, et pas une simple suite d’images. Toutefois, la fréquence de rafraichissement idéale est celle de l’écran. Le nombre d’images dessinées par seconde est alors appelé framerate ou FPS (frames per seconds).

C’est quelque chose que vous retrouverez tout le temps par la suite, le FPS est notamment un très bon indicateur de performances.

Notre fonction d’affichage se résume alors à :

1. Effacer le contenu du back buffer
2. Afficher nos images
3. Dire à la carte graphique qu’il est temps d’intervertir les buffers

Par chance, XNA s’occupe tout seul de la dernière étape.

GraphicManager

Toujours a la recherche d’une architecture propre pour notre programme, nous allons créer une classe pour gérer l’affichage.

On va alors créer une classe GraphicManager :

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using Microsoft.Xna.Framework;
using Microsoft.Xna.Framework.Graphics;

namespace ArticleXNA
{
    class GraphicManager
    {
	public GraphicManager ( GameManager game )
	{

	}
    }
}

C’est notre GameManager qui s’occupera de gérer le GraphicManager, il lui faudra donc une référence vers l’objet :

private GraphicManager _GraphicManager = null;

Et dans la méthode Initialize :

protected override void Initialize ()
{
_GraphicManager = new GraphicManager ( this );

base.Initialize ();
}

Nous passons une référence à notre game manager vers GraphicManager pour pouvoir créer un GraphicDeviceManager.

Cette classe est celle qui s’occupe de gérer le contexte graphique (GraphicDevice) sous XNA. Elle s’occupera notamment de le recréer si besoin est (par exemple lorsqu’on minimise le jeu en plein écran).

class GraphicManager
{

    public GraphicManager ( GameManager game )
    {
        _GDM = new GraphicsDeviceManager ( game );
    }

    private GraphicsDeviceManager _GDM = null;

}

C’est à cet objet que nous fournirons des informations telle la résolution du jeu, si on l’affiche en plein écran ou pas, etc.

_GDM.PreferredBackBufferWidth = 800;

_GDM.PreferredBackBufferHeight = 600;

_GDM.IsFullScreen = false;

_GDM.ApplyChanges ();

Notre fenêtre devrait désormais avoir une taille de 800*600 pixels.

L’affichage : SpriteBatch

De nos jours, la 2D n’est plus que de la 3D sans profondeur. La 2D est donc gérée exactement comme la 3D par la carte graphique, à l’exception près que la perspective est remplacée par une projection orthogonale (concrètement, la caméra fait face à la scène).

Heureusement, XNA nous simplifie la tâche en nous proposant de faire de la 2D facilement, sans connaissances en 3D.

Tout cela se fait par l’intermédiaire de la classe SpriteBatch.

Nous allons donc rajouter une instance de SpriteBatch dans notre GraphicManager :

private SpriteBatch _SpriteBatch = null;

Et dans le constructeur :

public GraphicManager ( GameManager game )
{
    _GDM = new GraphicsDeviceManager ( game );
    _GDM.PreferredBackBufferWidth = 800;
    _GDM.PreferredBackBufferHeight = 600;
    _GDM.IsFullScreen = false;
    _GDM.ApplyChanges ();

    _SpriteBatch = new SpriteBatch ( _GDM.GraphicsDevice );
}

Pour afficher un sprite, il faut le faire entre les instructions Begin() et End() de SpriteBatch.

Un sprite est une texture (une image) que l’on affiche à une position donnée, pour charger une texture avec XNA, on a deux solutions :

1. Passer par le Content Pipeline, l’avantage est que c’est portable sur XBox 260, le problème, c’est game studio (il faut rajouter l’image à sa solution Visual Studio…)
2. Pour Windows uniquement : Texture2D.FromFile ( _GDM.GraphicsDevice , “texture.jpg” )

Par exemple :

Texture2D TextureLogo = Texture2D.FromFile ( _GDM.GraphicsDevice , "logo.png" );

Puis pour l’afficher :

_SpriteBatch.Begin ();
_SpriteBatch.Draw ( TextureLogo , new Vector2 () , Color.White );
_SpriteBatch.End ();

On spécifie la position en second argument, et la couleur qui agira comme un filtre.

La position est définie par ses composantes X (abscisses) et Y (ordonnées) de la façon suivante :

Avec le code suivant, on obtient :

Voici le code source complet (mais temporaire) :

GameManager.cs

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using Microsoft.Xna.Framework;

namespace ArticleXNA
{
    class GameManager : Game
    {

        public GameManager ()
        {
            _GraphicManager = new GraphicManager ( this );
        }

        protected override void Initialize ()
        {
            Window.Title = "Article XNA";
            IsMouseVisible = true;

            _GraphicManager.Initialize ( 800 , 600 , false );

            base.Initialize ();
        }

        protected override void Update ( GameTime gameTime )
        {
            base.Update ( gameTime );
        }

        protected override void Draw ( GameTime gameTime )
        {
            _GraphicManager.Clear ();

            base.Draw ( gameTime );
        }

        private GraphicManager _GraphicManager = null;

    }
}

GraphicManager.cs

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using Microsoft.Xna.Framework;
using Microsoft.Xna.Framework.Graphics;

namespace ArticleXNA
{
    class GraphicManager
    {

        public GraphicManager ( GameManager game )
        {

            _GDM = new GraphicsDeviceManager ( game );

        }

        public void Initialize (int width , int height , bool fullscreen)
        {
            _SpriteBatch = new SpriteBatch ( _GDM.GraphicsDevice );

            _GDM.PreferredBackBufferWidth = 800;
            _GDM.PreferredBackBufferHeight = 600;
            _GDM.IsFullScreen = false;

            _GDM.ApplyChanges ();

            // Cela n'a en pratique rien à faire dans le GraphicManager, il est ici pour l'exemple !
            TextureLogo = Texture2D.FromFile ( _GDM.GraphicsDevice , "logo.png" );
        }

        public void Clear ()
        {
            _GDM.GraphicsDevice.Clear ( Color.CornflowerBlue );

            // Cela n'a en pratique rien à faire dans le GraphicManager, il est ici pour l'exemple !
            _SpriteBatch.Begin ();
            _SpriteBatch.Draw ( TextureLogo , new Vector2 () , Color.White );
            _SpriteBatch.End ();

        }

        private GraphicsDeviceManager _GDM = null;
        private SpriteBatch _SpriteBatch = null;

        // Cela n'a en pratique rien à faire dans le GraphicManager, il est ici pour l'exemple !
        private Texture2D TextureLogo = null;

    }
}

Program.cs

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace ArticleXNA
{
    class Program
    {
        static void Main ( string[] args )
        {
            try
            {

                GameManager game = new GameManager ();

                game.Run ();

            }
            catch ( Exception e )
            {
                Console.WriteLine ( e.ToString () );
            }
        }
    }