Mi figue Mi raisin

 

    C'est la fin de mes longs congés d'été, une période que j'ai mis à profit pour avancer sur le projet Felgon. Comme le laisse deviner ma première illustration, le bilan de cette période est mitigé. En effet, bien qu'il y ait eu des avancées notables, je reste insatisfait. Même s'il n'y a pas vraiment de planning sur ce projet, j'ai malgré tout le sentiment de ne pas avoir autant avancé le projet comme j'aurai du. Cela dit, on peut quand même apprécier les avancées obtenus.

    Tout d'abord, niveau graphismes LZamu a fait du beau boulot, en rajoutant des écrans intermédiaires qui permettent une meilleure immersion dans les premières étapes de l'histoire. A mon dernier décompte, nous en sommes à 34 images réalisées sur la quarantaine de "tableaux" décrivant le premier et le second arc narratif. Attention par contre, à ce ratio qui est quelque peu trompeur ! Ce que j'appelle un tableau est au départ un fichier de données que je crée sous Excel pour enchainer les textes et les interactions. Ce fichier peut utiliser plusieurs images différentes. D'un autre coté, on peut utiliser sur deux fichiers de données la même image. 

    Coté technique, j'ai enfin réalisé un gros lot de tests de mon scénario avec le moteur lui-même. Cela m'a permis de détecter un grand nombre de bugs qui résidaient non pas dans le moteur, mais dans les données que je générais. Une case non remplie, un ensemble de lignes avec des conditions n'ayant pas prévu un certain cas de figure. C'est pas moins d'une vingtaine de bugs que j'ai corrigé ainsi. Coté moteur, je n'ai eu que quelques soucis mineurs, j'ai par exemple corrigé un soucis avec la fonte utilisé qui n'avait pas le caractère "ç" et le caractère ":" ce qui rendait certains textes de dialogues où j'affichais le nom du locuteur en premier suivi de ":" pour bien mettre en évidence que ce n'était pas le joueur qui parlait mais le PNJ. Ca fait bizarre de parler de PNJ et de joueur pour un roman interactif, mais je n'ai pas d'autres mots.

    J'ai aussi amélioré l'éditeur pour détecter ce type d'erreur quand c'était possible et j'ai ajouté un outil pour générer des statistiques d'avancée sur les graphismes. Mais pour les raisons que j'ai indiqué précédemment, ces statistiques ne sont pas à prendre au pied de la lettre.

    J'ai aussi corrigé un petit bug d'inattention, l'oubli d'appeler la génération d'un fichier de données.

    J'ai pas mal bossé sur l'organisation du scénario, en prenant enfin le temps de faire un graphe du scénario. C'est quelque chose que j'aurai du faire bien avant, tant ce genre de représentation permet d'éclaircir les idées et améliorer le résultat !
    

Cela m'a permis de mieux réorganiser la répartition des fichiers sur les 3 premières faces de disquettes. J'ai d'ailleurs eu pas mal de soucis avec cette première face, et j'ai du, pour gagner quelques kilo-octets regrouper 5 fichiers de données en un seul. Ainsi, un même fichier gère à présent 5 images différentes ! En fait, si le basic du CPC avait disposé d'assez de mémoire, j'aurai pu faire tenir le jeu dans un seul gros fichier. Mais bien entendu ce n'est pas possible et le dernier bug que j'ai rencontré ce vendredi après midi, m'a bien rappelé à quel point l'interpréteur Basic sur CPC détestait qu'on atteigne ses limites de mémoire !

    En 1994, j'avais atteint les limites mémoires de l'interpréteur et ça m'avait fait jeter l'éponge sur mon projet l'ile au trésor. Un échec douloureux, mais finalement  corrigé et amélioré en septembre 2020 après des mois de travail et l'aide de nombreuses personnes plus douées que moi !

    Et là, j'avais déjà eu un petit coup de semonce, lors d'un des bugs de scénario qui faisait rendre la main au basic. En faisant un ? fre(""), j'ai constaté qu'il ne restait que 2 kilo octets de libre ! J'analyse mon moteur et je constate avec effroi que j'avais tout simplement oublié d'appeler la routine forçant le recours au garbage collector. Je corrige ça, et tout roule bien pendant mes congés, j'avance bien, mais donc ce vendredi j'obtiens le message string space full in 830. Ce fût un choc, mais j'aurai du m'y attendre. Lorsque j'ai fait ma liste de tâches à faire au début du projet, j'avais noté de faire une série de tests avec un scénario bidon pour simplement tester les limites du moteur en termes d'utilisation de la mémoire. Et bêtement, j'ai remis cette tâche à plus tard, en me concentrant sur la création du véritable scénario. Le premier arc narratif, constituait en lui même, un premier test de validation, mais seulement dans des limites basses. Et là, j'ai eu cet échec sur un des plus gros fichiers de données que j'avais rédigés. Les fichiers les plus gros que j'avais parcourus jusque là, ne dépassaient pas les 6 kios mais celui-ci en faisait 10 ! Ca n'a l'air de rien, mais c'est en moyenne plus de la moitié d'un chapitre de Germinal par exemple. Donc, passé le premier choc, j'analyse les causes, et je me dis que comme en Basic, on a un système de garbage collector et que je lui ai forcé la main, j'ai du fragmenter la mémoire rendant le chargement de ce fichier impossible ! Je me dis alors qu'empêcher ce problème consisterait à refaire mon moteur, en gardant des tableaux fixes que l'on remplit de chaines d'espaces avant de les recharger avec de nouveaux fichiers textes. Ca m'avait l'air complexe, et sans garantie de succès. J'ai envisagé un temps de tout recommencer avec ugBasic ou Turbo Pascal 3.0 mais c'était trop risqué, je n'avais aucune idée de comment les limitations de ces technologies allaient m'impacter. De plus, un changement de technologie, ou même un changement de méthode de chargement pouvait impliquer de changer le format des fichiers de données et avoir un impact très important sur l'éditeur.

    J'ai donc pris la décision de temporiser, et je me suis rappelé que l'interpréteur Basic peut avoir des comportements très erratiques quand ses limites sont atteintes mais qu'au moins là, j'ai eu une sortie en erreur avec un message propre. Je me suis dit, qu'avant de tenter une réécriture complète du moteur, ce qui à ce stade aurait été franchement orchidoclaste, il fallait vérifier mon hypothèse comme quoi, il y avait une fragmentation grandissante de la mémoire à cause du garbage collector et que celle-ci arriverait tôt ou tard simplement en déroulant le scénario.

    J'ai donc pris le temps de refaire un premier mini scénario reprenant 6 fichiers de données de mon jeu dont celui sur lequel il s'était planté. Ainsi, si le moteur plantait d'entrée sur ce fichier, j'aurai la preuve que ça arrive à cause de ce gros fichier et pas du ménage mal fait lors du passage des précédents. J'ai aussi eu l'idée de faire boucler le scénario du dernier au premier pour voir si au final, le scénario peut se dérouler plusieurs fois sans saturer la mémoire. J'ajoute une variable compteur dans le mini scénario, et pour un premier test, je la positionne à 50. Je lance le moteur et le jeu s'arrête au même endroit, dans le même état, sur le premier gros fichier de 10k ! En me rappelant de la limite de mémoire obtenue la dernière fois que le moteur s'était arrêté, j'en ai déduit que je devais enlever 2.5 kio au fichier pour être tranquille.

    Je fais le test, et ça passe, je plante au second gros fichier ! Je le corrige de la même façon, et là je boucle le scénario ! Je l'exécute 50 fois (merci le mode turbo de Caprice Forever !) et là, je sors du moteur sans soucis au bout de 50 passages comme prévu ! C'est suffisant, mais je pousse le vice jusqu'à 255 pour être sur, je le relance et ça passe encore ! En sortie du moteur, vu que je me suis arrêté sur un petit fichier, j'ai encore 10 kio de libre ! Donc voila, même s'il y a de la perte de mémoire en utilisant le garbage collector, celle-ci est suffisamment réduite pour ne pas impacter le moteur !

    Je me serais bien passé de ce coup de flip, pour cette fin de vacances, mais je suis content de ne pas avoir à refaire mon moteur. Je vais juste faire une évolution de mon éditeur pour prévenir quand la longeur totale des chaînes de texte entrées sur une colonne dépasse les 7.5 kio et ça sera ok. L'avantage de ce moteur c'est qu'il n'est pas trop compliqué de morceler un gros fichier en plusieurs ou au contraire de regrouper plusieurs petits fichiers en un seul !

    Sur ce dernier point, j'apporte quand même un bémol, j'avais prévu l'option de permettre de générer un fichier basic supplémentaire pour faire du code spécifique pour certains tableaux, mais cela s'envisageait seulement pour des cas où il n'y avait qu'une image référencée dans le fichier de données. Avec plusieurs images, c'est nettement plus complexe, je n'ai pas d'API prévues pour ça pour le moment, et j'ai peur de devoir faire des programmes assez crades. Par ailleurs vu la faible quantité de ram encore disponible, je ne suis pas certain de vouloir prendre le risque de perdre encore de la place en mémoire !

    En attendant, vivement septembre et le début de la deuxième saison des figues en France !