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.
Rien de mieux qu'une image pour expliquer ça. Les classes entourées de bleu représentent celles avec un début d'implémentation. Cette couleur signifie que l'idée générale du rôle de la classe et son interface est présente dans le code, donc rien de complet, juste "prêt à être rempli".
