Portage du jeu et anecdote

Cela fait un petit moment déjà que je n'ai pas posté de nouveau billet.
La raison est que j'ai n'ai pas vraiment de nouvelles choses à dire, si ce n'est que j'ai travaillé énormément sur mon projet GS1. Il est terminé, c'est sûr, mais dans le cadre des études. Je n'ai ajouté aucun élément de gameplay ou autre fonctionnalité, loin de là.

Non, le plus intéressant est que maintenant il marche totalement avec SDL comme librairie graphique, et FMod pour les sons. Le renderer software est toujours présent et marche parfaitement avec SDL (sauf que ce n'est certainement pas codé proprement, j'ai eu la flemme de faire les appels aux fonctions lock surface pour écrire directement dans le buffer).

J'ai également amélioré le renderer software en ajoutant les plans de clipping de la caméra. Ca a permis de supprimer quelques bugs d'affichage de triangles, produisant des aberrations dans le depth buffer parfois (par exemple, dans the death corridor, si vous vous collez sur les bords vous remarquerez que les murs s'affichent partiellement par dessus le vaisseau avec une forme ronde). J'ai d'ailleurs une anecdote intéressant sur le sujet :
Au départ, j'ai voulu trouver une solution pour le clipping moi même (comme toujours, j'ai envie de réinventer la roue. C'est dans quel contexte déjà? Ah oui! Je fais un renderer 3D en software ... réalisé un millier de fois par un million de personnes depuis déjà 20 ans au moins). J'avais beau retourner le problème dans tout les sens, le clipping semblait fonctionner mais certains polygones disparaissaient toujours mystérieusement ... A force de tourner en rond je finis par m'avouer vaincu et décide d'adopter une méthode déjà existante : l'algorithme de clipping de Sutherland Hodgman. Je l'implémente, tout fier de moi, et j'obtiens le même résultat! En fait mon propre clipping marchait parfaitement, c'est juste que j'avais oublié un détail en dehors de cet algorithme. Mon code ressemblait à ca:

récupérer le triangle T à afficher
appliquer la matrice de transformation à T
clipper T pour obtenir un polygone P
appliquer la matrice de projection à T
test du backface culling en fonction de T
...
appliquer la matrice de transformation à P
afficher P

Vous voyez le problème? Un indice : les aberrations surviennent lorsque la projection est appliquée sur des points situés hors caméra. Toujours pas? Autre indice : le backface culling vérifie si un triangle doit être affiché ou non (mon problème vient de polygones qui ne s'affichent pas). Je saute quelques lignes pour éviter de spoiler la réponse ;)
















Le problème était que je testais le backface culling avec T, non clippé, qui pouvait donc avoir des valeurs totalement fausses après l'application de la matrice de projection. La solution consistait donc à ignorer totalement T cette fois (car d'autres calculs étaient faits dessus) en le remplaçant par l'un des triangles que compose P .

Le clipping en lui même marche bien maintenant, mais il nécessite encore quelque optimisations. Le fait est que j'implémente l'algorithme de Sutherland-Hodgman avec des std::list. Du coup pleins d'allocations et désallocations mémoire en plus de copies inutiles sont effectuées. Ce qui donne un fort ralentissement lorsque la caméra passe à l'intérieur d'un polygone (au début de fighting above the earth). Mais le soulagement d'avoir enfin trouvé et réparé ce bug, précédé par quelques crises de nerf, m'ont incité à passer à autre chose :

Le portage du jeu vers OpenGL.
Cette fois, je garde SDL comme base, mais je remplace toutes mes opérations de rasterisation et calcul de matrice fait main avec des appels à l'API. Le plus dur n'est pas vraiment savoir quoi utiliser, mais plutôt savoir quels réglages appliquer pour obtenir le bon affichage. Voilà l'état d'avancement en images :

L'affichage de mes modèles fonctionne correctement, le chargement des textures aussi (sauf que c'est mal paramétré dans ce cas là donc on ne voit rien, juste un carré blanc pour les astéroïdes). Mes astéroïdes sont affichés en tant que billboards (ce qui fera certainement l'objet d'un prochain billet), et il reste à ajouter l'éclairage. Enfin, je n'aurais plus qu'à remettre en place le fond étoilé puis la planète et le tour sera joué.

Quand le portage OpenGL sera effectué, je tenterais de porter tout ca sur DS! Je suis trés confiant pour OpenGL, mais en ce qui concerne la DS, j'ai beaucoup de choses à apprendre et ca risque de prendre beaucoup de temps. Mais j'avoue que voir son propre jeu en 3D tourner sur sa petite console est une grande motivation.

Shooter 3D

Et le voilà! L'aboutissement du module à Teesside, Game Software Development 1.
Comme je vous l'ai dit à propos du moteur 3D sur un post précédent, j'ai développé un jeu 3D pour un projet qui en demande un en 2D et interdit toute librairie graphique. C'est comme ca que j'en suis venu à faire un moteur 3D en software.

Donc voilà le résultat!





Si vous devenez ultra fan de ce jeu, jetez un oeil aux fichiers xml, et si vous en comprenez le fonctionnement vous pourrez créer vos propres niveaux. Bon ok il faudra faire ça à la main mais ça peut devenir amusant.

Par ici pour le télécharger

Génération procédurale : Perlin

Tout geek dans la programmation jeux vidéo qui se respecte doit forcément en venir là un jour : la génération procédurale.
Premièrement, ca simplifie et accélère le processus de création dans un jeu vidéo. De deux, ca consiste seulement à utiliser de la programmation pour prétendre qu'on est créatif. De trois, "génération procédurale" ca sonne bien et ca donne l'air intelligent.

Le point de départ lorsqu'on s'intéresse à la génération procédurale, c'est Perlin. Vous n'allez peut-être pas le croire, mais même si son nom ressemble à un de ces vieux grecs (Thalès, Pythagore...) qui sont toujours aussi utiles de nos jours, Perlin lui, n'as pas 2000 ans d'avance. Il est même encore en vie.

Ce qu'il nous a apporté, c'est le bruit de Perlin. C'est à dire une fonction aléatoire pas si aléatoire. On peut dire aussi du bruit cohérent. Bon alors c'est quoi la différence entre un bruit non cohérent et un autre qui l'est? Rien de mieux qu'une image pour expliquer:

Une belle texture pour un nuage!
Ca peut également servir de heightmap.
Avec ça comme base, on peut générer des tas d'autres choses.

Vous voulez faire pareil?
Alors vous aurez besoin de la fonction de bruit de Perlin, ici sur son site. Attention, ça ne donne pas le résultat nuage que je vous ait montré.
Pour avoir ce résultat, il faut combiner plusieurs bruits de perlin. Ici il y a un tutorial qui explique bien comment faire.

Attention! Si vous voulez utiliser la fonction du bruit de perlin, celle qui est donnée sur son site retourne une valeur entre -1 et 1. Alors que pour produire une image les composants red green et blue sont entre 0 et 255. L'erreur serait de multiplier uniquement par 255, mais ca donnerait quelque chose entre -255 et 255. Soit ca fait bugger votre programme, soit vous obtiendrez une image avec des zones noires uniformes (car les valeurs entre -255 et 0 sont transformées en 0).



Pourquoi je vous parle de ça? En 3GS on a commencé les textures générées procéduralement, et comme je vous l'ait dit, il faut bien commencer par le commencement. Et donc chez moi ça donne ceci :