Un bon ouvrier a toujours de bons outils, c’est en substance ce que me disait mes parents, à l’époque encore étonné que j’avais fini premier de la classe alors que j’avais toujours une trousse avec un stylo et demi en état de marche et une dotation pour le moins aléatoire sur pas mal de points. Non pas qu’ils ne me fournissaient pas le matériel adéquat mais parce qu’à l’époque j’avais une tendance à facilement égarer compas, gomme et taille crayon. Aujourd’hui je suis convaincu de la nécessité d’avoir du bon matériel surtout quand on exerce la profession de développeur logiciel.

Il s’avère que dans ce métier de développeur la base de code que l’on emploie est un de nos outils les plus utilisés, au même titre que les bibliothèques fournies par le constructeur et le compilateur. J’avoue que sur Nintendo DS je n’avais jusqu’à présent pas une très grande confiance dans le SDK et notre base de code. Il faut dire que j’ai rarement été directement impliqué dans le développement et que j’étais plutôt du genre parachuté sur les projets ce qui n’aide pas à avoir une vue complète du développement. Cela contraste d’ailleurs avec certains de mes collègues, dont Vincent pour qui la console et son environnement de développement est plutôt fiable et il a nettement plus d’expérience à ce niveau là que moi.

Néanmoins depuis quelques temps je m’occupe de finaliser un projet qui aurait du être plié depuis longtemps. Ce projet a eu une histoire tumultueuse, et quand je l’ai repris il y avait encore de nombreux bugs, ce qui était plutôt étrange dans la mesure où à l’époque il devait être prêt pour la commercialisation. J’ai donc surtout fait du bugfix, même si un des principaux problèmes était le manque de mémoire. Il faut bien voir qu’une DS ça a 4Mo de mémoire. Cela n’est déjà pas énorme en soit mais quand en plus l’exécutable du jeu fait 1,6Mo ce n’est pas gagné.

Je devais réglé ce problème en ayant un minimum d’effet de bords car à ce stade du projet l’idée n’était pas de refactorer l’ensemble du code. Je me suis donc tourné vers les choses les plus évidentes. Par exemple des pans entiers du code était inliné de manière explicite. A notre époque de compilateur qui ont des heuristiques qui vont bien pour décider quelle partie « inliner » c’est plutôt inadéquat. Je passe aussi sur une méthode qui était en « virtual inline », les gens ont vraiment un sens de l’humour étrange.

Virer les inlines m’avait permis de faire descendre le projet de 1,6Mo à 1,1Mo mais j’avais alors des problèmes d’affichage sur les personnages, ils étaient en fil de fer. J’avais tiqué car dans la version de déboggage du programme les personnages étaient aussi en fil de fer. J’avais cherché pendant une journée si une directive de compilation conditionnelle forcer l’affichage en fil de fer mais sans succès. Tout cela s’apparentait donc à un bug. Et je commençais à avoir une bien piètre opinion de la stabilité du SDK.

Finalement en passant l’optimisation en optimisation minimisant la taille du code au lieu de la vitesse d’exécution du programme j’avais réussi à gagner environ 300ko de mémoire. Cela fut très funky dans la mesure où j’ai du régler l’optimiseur par fichier de code, et j’en gardais une certaine rancune vis à vis du compilateur. Ces 300ko de rab me permettait enfin de supprimer pas mal de crash dans les minijeux du à un manque de mémoire. Mais j’avais encore des rapports de bugs qui remontaient avec des plantages « aléatoires ». Je me décidais donc à faire une version spéciale qui comprendrait les optimisations de code mais avec des infos de déboggage pour avoir au minimum une idée de où chercher le problème.

Je lance cette version et paf elle plante. Et là mon sentiment de confiance n’est vraiment plus là. Je me dis qu’avec leurs outils de dev pourris on va pas s’en sortir. Je réfléchis sur comment régler le problème et là je me souviens de la première règle lorsque l’on débuggue : « s’il y a un problème, c’est en principe de ta faute ». J’ai donc commencé à essayer d’isoler le problème vu que bien entendu ça planter loin, loin dans le SDK. Au final je suis tombé sur un appel d’une fonction qui servait à copier les matériaux, cette dernière nécessitait un alignement des données sur un multiple de 4 … qui bien n’entendu n’était pas là.

J’ai donc corrigé le bug et non seulement  le jeu ne plantait plus mais en plus je n’avais plus le problème des personnages en fil de fer vu que ce dernier venait de là aussi. Et là j’ai compris que finalement la confiance cela ne tient à pas grand chose. A présent celle que j’ai pour les outils nintendo est remonté en flèche.