Suite de la série sur le développement du jeu La maison dans la colline sur VG5000µ. Après, la première partie, qui donnait le contexte de création, voici donc la deuxième partie, où j'aborde les outils de développement utilisés.
Les bases
Lorsque je développe un logiciel, je veux pouvoir me consacrer sur un temps contiguë maximum au cœur du projet. Même, et peut-être surtout, lorsque ce développement est un hobby, et que j'ai peu d'heures à y consacrer, ici et là en fonction de mon temps libre.
Ainsi, une fois le projet en développement, lorsque j'ai une petite demi-heure par-ci ou une grosse heure par là, je veux pouvoir m'installer et me consacrer à la valeur de ce projet. À son développement concret.
Pour moi, cela signifie que tout ce que je peux automatiser et qui me permettra de profiter de ces temps là au maximum doit l'être fait en amont. Si je dois cliquer sur des boutons, faire des manipulations, lancer ou configurer des logiciels à chaque fois que je fais un essai, voire même à chaque fois que je débute une session, c'est un temps précieux qui est inutilisé. Chaque manipulation est aussi une occasion de faire une erreur.
Dans le passé sur ce site, j'ai déjà présenté quelques outils destinés à me faciliter la tâche. Et dès les essais sur l'EF9345 dont je parlais dans l'article précédent, j'ai remis en place un script qui permet de lancer l'émulateur automatiquement, configuré avec lancement du chargement.
Comme je me doutais que le programme allait gagner en taille, j'ai ajouté au script une manière de passer l'émulateur en vitesse accélérée le temps du chargement.
Ainsi, dès que je termine une compilation, je n'ai que quelques secondes à attendre avant de retrouver le jeu, prêt à être testé, dans l'émulateur.
Le framework
Afin de pouvoir itérer sur le jeu, particulièrement sur son gameplay, j'ai choisi de développer dans un mélange de C et d'assembleur. Le C permet des modifications simples de morceaux de code sans trop se poser de questions bas niveau. L'assembleur permet d’accélérer certaines parties une fois qu'elles sont fixes, ainsi qu'un accès rapide au matériel.
Car en effet, si j'ai choisi de faire un jeu d'aventure graphique, je tiens à deux choses au niveau de l'affichage :
- que l'affichage d'une pièce soit très rapide (si ce n'est immédiat),
- que les mouvements à l'écran ne provoquent aucun clignotement
Difficile voire impossible à faire cela en BASIC. Plus facile à faire en C, mais c'est l'assembleur qui me permettra de vraiment réaliser ces objectifs.
De même, je voulais initialement que le jeu tienne sur une machine sans extension mémoire. Malheureusement, je ne réaliserai pas cet objectif. De peu...
z88dk
Quelques temps (années ?) auparavant, j'avais croisé le chemin de z88dk, un framework de programmation en C dédié aux machines Z80. Cela me semblait être une bonne occasion pour l'essayer, avoir l'espoir qu'il vienne avec des fonctionnalités intéressantes qui me feraient gagner du temps.
Après tout, il y a des outils de création de programme assemblés dans une suite complète, une bibliothèque C pour Z80, un support VG5000µ et un fichier crt.s déjà configuré et configurable. Ça, se sont les avantages.
Après usage pendant toute la durée du projet, voici les inconvénients :
- le programme principal qui appelle les autres pour la compilation n'a pas une syntaxe d'option standard, et cela me posera des problèmes avec
cmake,
- le compilateur par défaut n'est pas le meilleur, je m'en rendrai compte beaucoup plus tard, vers la fin du projet. Il est possible d'utiliser un compilateur alternatif, qui optimise visiblement mieux. Malheureusement, les deux ne se comportent pas tout à fait de la même façon, et j'ai préférer ne pas changer en chemin. On verra pour un futur projet peut-être,
- le support VG5000µ est axé sur une utilisation en mode texte, et passe par le système implémenté par la ROM, sans accès direct à l'EF9345. Ce n'est pas cohérent avec ce que je veux faire, et je n'utiliserai finalement aucune fonction spécifiquement dédiée au VG5000µ.
Au final, je ne suis pas entièrement convaincu par z88dk, qui à l'air de prendre une orientation plutôt CP/M et machined un peu plus puissantes qu'un VG5000µ.
Gestion de la construction
Pour le gestionnaire de construction de version, je suis parti sur cmake. C'est très probablement surdimensionné, mais je connais son utilisation classique. Ici, je voulais pousser plus loin et aborder sa configuration de chaîne de compilation « exotique ».
J'ai beaucoup appris sur cmake au passage ; ma solution finale n'est pas entièrement solide, je confirme à nouveau que Stack Overflow n'est d'aucune aide dès que vous avez un soucis qui n'est pas basique, que la documentation de cmake est toujours peu aidante... et qu'un Makefile tout simple aurait été probablement tout aussi efficace. Mais je m'emmêle toujours les pinceaux avec un Makefile dès que je quitte les règles de bases.
cmake est probablement trop automatique sur certains points, et il n'est pas toujours facile de lui faire comprendre que la buildchain utilisé ne se comporte pas tout à fait comme ce à quoi il s'attend.
Enfin maintenant c'est fait, et même si je dois corriger certaines petites choses au niveau des dépendances entre les .c, les .h et les .asm, ça marche globalement bien.
Éditeur de code
cmake était surdimensionné ? Que dire de l'éditeur de code que j'ai utilisé. CLion... vim ou visual studio code auraient suffit. Et il m'est arrivé d'utiliser vim pendant le développement pour quelques modifs rapides. Mais là encore, je connais bien CLion, ses outils, sa configuration, et l'habitude, ça compte.
De toute façon, mes outils d'automatisation ne sont dépendants ni de cmake, ni de clion, ce sont donc des choix indépendants.
Paré au départ !
Ou presque. J'ai cité les outils de développement principaux. Mais je parlais en introduction d'automatiser la mise en place de l'environnement de développement. Pour cela, j'utilise le terminal kitty associé à un script. Lorsque je lance ce script, le terminal se met en place avec les bon terminaux ouverts dans les bons répertoire, et des outils textes déjà lancés (ranger pour la gestion de fichier, lazygit pour la gestion de version, nb pour la prise de notes, le script d'automatisation à l'écoute).
Ainsi, démarrer une session depuis un ordinateur fraîchement allumé me prend deux clics pour avoir l'intégralité de l'environnement en place, et j'ai tout ce qu'il me faut pour la session. Cela aurait été un seul si je n'avais pas choisi Clion.
Alors... clic, clic... et la suite au prochain épisde.
