À la découverte du mode cache d’iMPdraw

Par AsT / iMPACT.

Depuis quelque temps maintenant, ou plus précisément depuis la sortie de la version publique (iMPdraw_201013f), nous travaillons avec l’équipe iMPACT sur l’ajout d’une nouvelle fonction dans iMPdraw, la mémoire cache.

iMPdraw, c’est quoi donc que cette bête ? Et bien, pour faire simple, c’est un logiciel de dessin/retouche en fullscreen qui a été développé par une petite équipe, Kris, Barjack et moi. Que fait-il ? Il gère tout type d’Amstrad, soit les CPC et les Plus. Il s’adapte en fonction de la machine et propose de grapher avec la palette correspondante au modèle. Le système d’i/o est le plus puissant qui n’ait jamais existé sur ce type de logiciel puisqu’il permet de charger/sauver sur disquette mais aussi sur tous les nouveaux supports à savoir, la xMass (grâce à iMPdos), la M4 (Duke) et l’Albireo de Pulko (via l’albiDOS d’OffseT).

Après ce petit interlude, et avant de commencer à entrer dans le vif du sujet, sachez que cette mémoire cache n’est seulement accessible que par les utilisateurs iMPdraw ayant une xMass. Ce mode nécessite également la dernière version d’iMPdos. En effet, la gestion de la mémoire cache est pilotée par le Dos.

Mais, qu’est-ce que ce mode cache, me direz-vous ? Quelle est son utilité ? Et bien, depuis la création d’iMPdos, j’ai réservé sur le DoM quelques secteurs pour une utilisation “spéciale”. Laquelle ? Au départ, je n’en avais aucune idée puis, après avoir diffusé la dernière version publique d’iMPdraw, j’ai repensé à cette mémoire cache, toujours disponible et non utilisée. Cette mémoire est en fait représentée par les secteurs allant de 3 à #199. iMPdraw n’utilise que les secteurs #03 à #83, soit 64 secteurs pour 2 images de fullscreen 32k.

Je me suis donc mis au travail. Avant de commencer, nous avons parlé de mon idée avec Kris. Il semblait intéressé, ce qui m’a grandement motivé à tout mettre en place rapidement. L’idée de départ était la possibilité de stocker l’image courante, celle chargée dans iMPdraw, en mémoire cache. Pourquoi ?

  • Cela permettait de recharger rapidement et immédiatement le travail en cours.
  • L’image en cours peut être sauvegardée encore et encore sans prendre 1 octet en mémoire DoM disponible. Enfin, pas vraiment, parce que c’est sauvegardé dans la mémoire cache me direz-vous ? Oui, mais non, parce qu’elle n’est seulement accessible que de façon “invisible”. On ne peut donc pas l’écraser.
  • Avoir la possibilité de sauver 2 images en cache, (image 1 & image 2), ce qui permet de copier/coller d’une sur l’autre.
  • La possibilité d’un undo infini en mode fullscreen, juste en appuyant sur Escape.

Vous avez maintenant une idée de ce que je voulais obtenir au départ. Mais, pourquoi est-ce que je partage mes idées ici aujourd’hui ? Tout simplement car j’ai codé toutes ces fonctions, et même plus. Pour les petits curieux qui se demanderaient quoi, il faudra tester. Je laisse une part de mystère. Cependant, durant l’élaboration des diverses routines, j’ai réussi à me perdre dans les méandres du code et à faire que ce que j’avais déjà codé devienne une usine à gaz.

Du bug, du bug, du bug…

Au départ, tout fonctionnait parfaitement mais, au fur et à mesure de l’ajout d’autres fonctionalités, nous en sommes arrivés à corrompre iMPdraw mais aussi, nos fameuses xMass. J’ai donc décidé hier, de remettre TOUT à plat, d’effacer ce que j’avais déjà commencé, en gros, le travail de 3 semaines. J’en avais assez de faire des “patchs” pour corriger les bugs qui apparaissaient ici et là. C’est le problème lorsque l’on part dans tous les sens sans avoir au préalable établi une feuille de route, les premiers accrocs apparaîssent.

La bonne pratique

Remettre tout à plat, oui, mais comment ? Quelle est la bonne pratique ? Comme dirait le petit nicolas, “et ben, j’vais vous’l dire!”. Je suis revenu au fondamentaux. Le papier et le crayon, il n’y a rien de mieux pour se remettre les idées en place. Voici donc, le plan papier que j’ai réalisé hier.

On repart sur de bonnes bases ?

Une fois ledit plan papier réalisé, il ne me restait plus qu’à re-coder tout de zéro. Je lance donc mon assembleur, Orgams en l’occurence. Reste plus qu’à charger le fichier source défectueux. Je prends mon plan papier et commence par effacer les unes après les autres, les routines que j’avais codées et qui étaient devenues sources du délit.

Une fois toutes effacées, je commence à recoder les différents points en prenant soin de suivre point par point mon plan. Le plus important c’est de repartir sur une structure stable.

Les sous-routines codées, il ne me restait plus qu’à faire le lien avec les différentes fonctions que j’avais voulu mettre en place. A ce propos, une des nouvelles fonctionnalités dont je suis le plus fier, reste le undo infini. Cette routine a été une énorme source de bug au départ et je suis assez fier aujourd’hui de voir qu’elle fonctionne comme je l’avais pensée.

Le point positif de tout cela ? Tout a été codé en une seule passe, tout est fonctionnel du premier coup. Comme quoi, passer par la phase papier peut paraître inutile mais reste néanmoins dans ce cas précis indispensable. La phase papier a autorisé le découpage des routines centrales en sous-routines. Cela a surtout été utile pour travailler pas à pas. Je me disais : “Si je fais ça, je veux tel résultat”.

La morale de cette histoire, si morale il devait y avoir, c’est que le fait de tout re-structurer sur papier m’a permis de reprogrammer en 1 jour ce que j’avais codé “à la va-vite” en 3 semaines.