Satanée compatibilité !

 

    

    Un cours billet ce soir, écrit d'une main tant que mon chat me prends mon bras gauche pour son hamac !

Petit jeu, devinez pourquoi j'ai choisi cette couverture de film ?

Une idée ?

Et bien, dans ce film, on apprends que la réponse à tous les mystères de l'univers c'est 42 ! Or le CPC 464 vient de fêter ses 42 ans ! Et c'est de ce dernier dont je voulais parler !

    Quand j'ai lancé le projet Felgon, je voulais que le jeu fonctionne certes sur disquettes, mais qu'il fonctionne quand même sur un 464 équipé d'un lecteur. Je me suis donc astreint à ne pas utiliser d'instructions propres au Basic 1.1. J'ai aussi fait le choix de ne pas utiliser les 64k supplémentaires du 6128. Donc j'espérais avec ça, obtenir un jeu directement compatible sur le CPC 464 !

        Mais quelle ne fut pas ma déception, quand au moment de tester celà, je constate que le jeu plante dès le premier écran. J'audite alors mon code, et je constate qu'effectivement, il y avait un passage dans mon code, qui était dirons nous, d'une logique scabreuse ! C'était même à se demander comment ça avait pu fonctionner correctement sur le Basic 1.1 ! Qu'à cela ne tienne, je corrige, je lance le jeu sur 6128, le jeu fonctionne bien. Je le lance sur 464, et là, quelque chose ne tourne pas rond. Le jeu rame beaucoup plus que sur 6128 ! Je teste avec toutes les peines du monde, et pire que tout, bien plus tard dans le jeu, j'obtiens un message d'erreur incompréhensible ! Une variable contenant normalement le nom du fichier à charger, contenait une valeur totalement incohérente. J'ai essayé différentes optimisations qui n'avaient pas été nécessaires sur CPC 6128. Mais rien n'y fait, le jeu rame toujours autant, et il plante au même endroit ! 

        Je n'ai plus vraiment de pistes pour le moment, le fichier de données chargée à ce moment là, n'est pas très gros, mais le suivant l'est. Il est possible que ça vienne de là pour le message d'erreur. Par contre ça n'explique pas les lenteurs. J'ai fait des benchs sur les instructions que j'utilise le plus dans le moteur et j'ai pu constater que l'une d'elles fre("") que j'utilise pour nettoyer la mémoire régulièrement, est 10% plus lente sur 464. Mais ces 10% ou les 7% sur une autre instruction n'explique pas cette différence de performances ! J'ai la nette impression que la gestion de la pile d'appel est nettement meilleure sur CPC 6128, mais ça non plus, ça ne devrait pas expliquer la différence ! 

        Bref, ce CPC de 42 ans, conserve encore des mystères !

PS : Mise à jour, bilan de mes dernières recherches et tentatives.

J'ai remplacé toutes mes variables entières suffixés par % avec un defint i et en les renommant i.. 

J'ai revu plusieurs fois les branchements et je me suis aperçu plusieurs fois que j'avais fait des gosub sans le return correspondant. 

J'ai même remplacé certains gosub / return par des goto puisque certaines routines n'étaient pas réutilisées !

J'ai même fini par créer un code pour empiler la ligne courante à chaque gosub et à la dépiler à chaque return. Cela m'a permit de trouver mon dernier problème de gosub / return. Le résultat c'est que la pile d'appel ne monte pas plus haut que 3 empilements au maximum !

J'ai aussi remplacé les boucles while / wend par des boucles avec des goto.

Et malgré tout ça, le programme rame et finit quand même par planter sur 464 ! 
Je ne comprends plus rien ! Il va falloir que je recode le moteur complétement différemment !