Felgon

      Décidément, je fais de la publicité pour la série Arcane, à la moindre occasion ! "Happy progress day !!" est une réplique de cette série ! Je ne vais pas vous raconter l'épisode, pour ne pas vous spolier la découverte de cette série.      Je voulais juste vous rassurer sur le fait que je progresse à nouveau sur le moteur. J'obtiens enfin des résultats tangibles à l'écran. Il reste encore des choses à corriger, à améliorer mais ça avance enfin ! Par contre visuellement, je n'ai pas grand chose à montrer de neuf ! Le fait est que j'avais des exemples faits auparavant avec des valeurs en dur, m'avait permis de faire des screenshots convaincants.     Donc à présent, je lis un fichier qui contient 2 structures de données différentes en un seul fichier. C'était un pré-requis important pour réduire le nombre de fichiers différents produits pour chaque tableau. Il me reste encore quelques fonctionnalités à développer sur ce moteur avant de pouvoir f

          Décidemment, je suis dans les métaphores maritimes en ce moment ! C'est bizarre pour un montagnard comme moi ! Bon après, je me qualifie de montagnard de part mon enfance, alors qu'en définitive, J'ai certes vécu mes 18 premières années en Lozère, mais j'ai vécu les 30 suivantes, à Montpellier, en Gironde et à Montauban ! J'ai donc passé plus de temps en dessous des 60 mètres d'altitudes qu'à mes fort modestes 600 mètres initiaux !     Mais assez parler de ma vie, sinon je n'aurai plus rien à raconter en début de stream ! 😉  Le fait d'avoir réduit le périmètre du projet m'a redonné un peu de motivation pour faire marcher ce moteur ! Jusqu'à présent, je bloquais à cause d'un véritable sac de noeuds de dépendances qui faisait que chaque avancée semblait ne jamais rien changer à l'avancement global !          Finalement, mon coup de sabre dans ce noeud gordien était nécessaire. Je ne doute pas qu'un bon programmeur s'e

      Cela fait un moment que je galère sur ce moteur de jeux ! Je dirais même que ça fait trop longtemps ! J'ai beau me creuser la tête, je n'arrive pas à trouver comment diminuer significativement la longueur du code de ce moteur ! J'arrive à 16 ko de code source, et le moteur n'est toujours pas terminé ! Je dois garder de la mémoire disponible pour pouvoir charger les écrans, et même les fichiers de données. La complexité du moteur, vient en premier lieu du fait qu'il gère 2 types d'écrans :  Les écrans à choix multiples Les écrans à saisie libre      C'est ce deuxième type d'écran qui est le moins avancé dans mon moteur. Il est évidemment plus complexe à gérer. Même si l'algorithme n'est pas très compliqué dans le principe, son implémentation en BASIC du CPC, entraine beaucoup de code supplémentaire. Ces écrans amènent la nécessité de créer un très grand nombre de tableaux supplémentaires. Comme je l'ai déjà expliqué, quand je définis une

      En théorie de l'informatique, on utilise ce que l'on appelle des paradigmes. Il existe plein de paradigmes différents actuellement. Les paradigmes consistent à volontairement limiter les possibilités offertes par le langage de programmation afin de rendre celui-ci plus intelligible et maintenable. Ainsi, lorsque l'on respecte le paradigme de la programmation structurée, on s'interdit d'utiliser l'instruction GOTO. Certains langages supportent nativement plusieurs paradigmes, par contre notre bon vieux BASIC du CPC ne facilite pas vraiment la tâche. En même temps, le CPC est sorti en 1984 !     Ce n'est qu'en 1985 que Bertrand Meyer a présenté un nouveau paradigme : la programmation par contrat par le biais de son langage Eiffel. Pour simplifier, ce langage permettait au programmeur de rajouter des instructions dédiées permettant d'arrêter l'exécution si jamais une condition ou plusieurs conditions ne sont pas vérifiées. Il était bien sur po

  Dans un projet sur CPC, il y a toujours un moment où l'on tombe sur un éceuil : La mémoire ! Dans l'informatique depuis ces 20 dernières années, on a pris la mauvaise habitude de ne plus regarder à la dépense en termes de mémoire, amoins de travailler sur des volumes colossaux, en général notre PC est capable d'encaisser des codes long de plusieurs méga octets sans sourciller. Mais sur notre CPC sorti en 1984, il en va bien évidemment autrement ! Lorsque l'on stocke en mémoire, du texte, chaque lettre représente un octet. Et nos 41 kilo octets disponibles en Basic, sont vite consommmés si l'on prend de mauvaises décisions ! Ainsi, pour stocker les objets entreposés dans les différents lieux du monde, j'avais prévu de créer un tableau de chaîne de caractères et de concaténer dans chaque case correspondant chacune à un tableau, les identifiants des objets présents. La forme aurait été pour me simplifier la vie 00035;00046;00008; Cela consomme évidemment plus de

      Même si j'avance dans mon moteur, je n'ai encore rien de très visuel à montrer pour le moment. Le gros soucis dans notre vieux basic c'est qu'il ne facilite absolument pas l'encapsulation, la création de données structurées, la factorisation d'un algorithme pour l'appliquer à plusieurs données différentes...     Cela engendre beaucoup de code qui semble être dupliqué, mais appliqué à un autre tableau...et cela alourdit d'autant plus le code.     Et pendant ce temps, LZAmu peaufine ses graphiques avec les contraintes que je lui ai rajouté qui sont tout de même importantes !      Dès le départ, j'avais décidé que comme on allait incarner plusieurs personnages dans le jeu, pour savoir qui on était à tout moment de la partie, on afficherait la tête du personnage en permanence à droite sous le titre. Cela me paraissait intéressant et assez original. Mais je n'ai pris conscience que plus tard que engendrait un nombre important de contraintes pour