SpriteRam, SpriteSheet, SpritePage, SpriteSet

Ce week-end, c'était priorité au montage des étagères dans mon petit bureau de 7m³, mais j'ai quand-même pu me concentrer un peu sur les petits soucis de gestion de mémoire qui me ralentissaient dans l'écriture de mon éditeur d'animations.

Pas étonnant que 3 ans après, je m'y perde un peu ... SpriteSet est commun à tous mes projets DS: c'est en gros le support du format .spr généré par le sprite editor. Mais les données graphiques qu'il manipule se sont étoffées. Les SpritePages ont été introduites en 2007 pour permettre d'éditer plus que ce que l'écran de SEDS ne peut afficher d'un coup. Les SpriteRams, en 2008 pour compenser le fait que la mémoire vidéo de la DS est séparées en "caractères" et "sprites".

I *had* to set the priority on some furniture assembly this week-end, to make my "7m³-desktop" a place where I can actually focus on what I do. Yet, I found some time to meditate on the VRAM allocation issues that were preventing me from doing progress on the animation editor. We're talking here about a set of classes that was initially designed to manipulate a single VRAM bank directly and that started to be multi-purpose (game engine + editors), multi-sets (manipulates set of sets of sprites), and that embraces ram heterogeneity (VRAM + main RAM). No wonder I was baffled.

In the case of the animation editor, the various "limbs" may use different spritepage (at least, 16x16 limbs may not reside on the same page as the 32x32 limbs), and at least for building miniatures on the timeline widget, those pages must be accessed simulatenously although there might not be enough VRAM to hold them altogether. I added a few methods to SpriteSet to address this situation in an almost clean manner.

Pour le moteur de jeu, l'ensemble des sprites est chargé en VRAM et les SpritePages servent uniquement à la construction des animations. Pour les éditeur, par contre, le contenu graphique (et donc SpriteRam.target) est généralement présent en mémoire centrale, et la VRAM est plutôt affectée aux SpriteSheets.

Pour AnimEDS, il ne me suffit plus d'avoir une seule "page" présente et affichée: les différentes étapes d'animation vont utiliser des éléments issus de différentes pages, parfois pour les afficher séparément, parfois pour les combiner. Les cogitations du week-end ont donc suggéré d'ajouter une fonction unique SpriteSet::getdata qui partage une partie de la fonctionalité de SpriteSheet::getdata mais qui peut récupérer n'importe quelle image du fichier .spr en mémoire à partir du seul numéro de page et numéro d'image dans la page.

N.B.: ça fait beaucoup d'espace "gâché" sur la gauche. J'imagine que 16x16 serait suffisant pour choisir un composant...