What's wrong with my spritesheet ?

Ok, this time, let's try to get that .spr file fixed. That's the right timing to get some framework that read and write .spr files on my host platform with the engine's C++ code.

You may remember this spritesheet captured some times ago, where 'striped'  tiles were suspected to be declared free although containing pixels ... It's a bit more complicated apparently: the tool building those spritesheets wasn't processing 32x16 blocks properly. The real "trouble map" (generated by the C++ tool) looks more like below: everything seems correctly aligned between the two versions. Well, everything except the last tile which is mapped on two different pages ...

Ouf. Longue semaine d'inspection du fichier de graphismes, avec un nouvel outil qui profite de mon système de test pour pouvoir utiliser directement le code du SpriteEditor pour faire l'équivalent d'un "chkdsk" pour les fichiers de sprites. J'en ai profité pour ajuster l'outil en PERL qui m'avait servi pour avoir cette "cartographie des problèmes" (ci-dessus) qui montre plus de problèmes qu'il n'y en a réellement (ci-dessous). En cause, les sprites de 16x32 (ou 32x16) qui n'étaient pas reconnus. Encore une petite étape de reconstruction, plutôt facile dans l'environnement PC, et me voilà prêt à attaquer les animations supplémentaires pour la récupération des power-ups.

It would be tempting to believe that with that double-mapped tile fixed, everything would work fine. For small blocks (16x16 pixels), the "blue-ish" free blocks would be used first, then the "red-ish" blobs (16x32 or 32x16 pixels) would be split by try_harder_alloc(). Except that splitting isn't allowed in normal allocations. In fact, if I can rely on cscope's output, splitting is *never* allowed.
Adding some more 16x16 sprites thus grows the file closer to its limit.

edit: Well, i finally decided to fix that by rebuilding the contents of the SpriteRam according to their appearance in the SpritePage, possibly duplicating whatever has more than one link. Since all animation definitions use : rather than a direct offset-in-SpriteRam, no additional work is needed. Good news.