Tout ce qu'on fait compte !

 

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 stocker les nombres sous forme de caractères, mais d'un autre coté, je peux facilement étendre la longueur de ma chaine pour stocker plus d'objets sans avoir trop de contraintes. Je pars donc sur cette solution sans trop me poser de questions.

Puis, je me dis, que gérer les chaines en Basic sur CPC c'est pas la panacée, donc pour indiquer que j'ai supprimé un objet dans un lieu après l'avoir pris, je vais remplacer l'identifiant de l'objet par des espaces. Ces mêmes espaces pourront ensuite être repris pour stocker un nouvel identifiant d'objet ensuite.

Sur le papier, l'utilisation de mémoire reste assez contenu tant que l'on n'utilise pas trop d'objets différents dans le jeu !

Or si l'on veut rendre le jeu, un peu plus difficile, il faut forcément mettre des objets inutiles pour que le joueur se triture les méninges sur des pistes qui ne mènent à rien sans quoi, le jeu sera aussi simpliste qu'un scénario de scoobidou et à chaque objet trouvé, vous vous exclameriez "Oh, regardez un indice !". 

Si on pousse le principe trop loin, on arrive à une situation de saturation de la mémoire juste en prenant les objets et en les reposant dans un autre tableau ! Admettons que j'ai une centaine de tableau et que j'ai dans le jeu 42 objets différents. En les posant un à un dans tout les tableaux, je peux rien qu'en faisant cela consommer 26 kilo octets de mémoire pour rien, non pas en tant que programmeur mais en tant que joueur en mode béta testeur zélé !

Je vais donc réfléchir à une autre façon de gérer l'inventaire des objets présents dans les différents tableaux car je n'ai pas envie de gérer les retours d'un interpréteur Basic aux fraises faute de mémoire ! Cela m'est déjà arrivé dans mon précédent jeu l'ile au trésor et c'est très ennuyeux et contraignant !

Cela m'embêterait de devoir gérer ça, en le stockant sur la disquette tableau par tableau, car ensuite, à chaque nouvelle partie, on récupèrerait les objets dans les lieux où on les a laissé dans la partie précédente. 

Après, je peux aussi limiter le nombre d'objets stockable en un lieu donné. Tout comme il m'a paru raisonnable de limiter l'inventaire d'une personne à 10, qu'un lieu contienne plus de 10 objets ne fait pas grand sens...

En attendant de statuer sur la bonne solution pour cette problématique que j'entrevoie ici, je vais revenir sur ce que j'avais expliqué en stream. Je vais finalement enlever de mon programme moteur, le chargement de tout les autres tableaux qui resteront en mémoire. Cela rendra mon programme moteur plus lisible et plus facile à maintenir.