This time, I could use runME to transfer the files (for some reason, I need to switch to "beam out" window, then back to "beam in" so that the "edit" spriteset button appears ?), but I wonder whether it could have dropped the animation information, somehow. Or is it something with the reading of autoexec.spr in SEDS that behaves differently from the typical START+L+* ?
Quelle histoire! Voilà la School Zone à peu près aussi sinistrée dans mes fichiers .spr que dans le monde de Bilou ... ici l'encre à disparu, là les encriers ont enfin retrouvé leur taille normale, mais dumblador ne marche plus... A force d'utiliser mes outils en cours de réparation pour tenter de réparer une bourde, les choses deviennent de plus en plus hasardeuses. Heureusement, j'ai les originaux de chaque fichier bien au chaud, sur mon disque dur (enfin, pas trop quand-même, hein ...)
Après avoir corrigé la copie de pages et la supression de blocs 32x32, je m'attaque à un dernier point mystérieux: la disparition des animations lorsque je transfère mes fichiers via runME (donc, avec un fichier 'autoexec.spr' présent au lancement de SEDS). Avec un peu de chance, j'arriverai (enfin) à récupérer tout le monde dans un seul .spr ...
Erhmm.. looks like it is. I'm missing an "&extdata" argument to keep track of "whatever the Sprite Editor doesn't natively understand"... such as animations. And all this happens with my brother's white DS, since DarkneSs is under repair after its "big fall"...
Ahaa ... got the autoexec.spr thingy fixed (yeah, there was the bug, as you may have guessed from checking the svn snippets). Some more beams and I also have the "smaller inkjet" copied into its proper place, the "minilevel" archived in the "draft" dataset ... Will I dare to run the engine on that ?
YES! pfew. I got it fixed, apparently. I will now be able to resume the attempts to bring ink swamp, inkjet and spongebop some life. howdy.
want a funny trivia: altough I got the spriteset "repaired", it's still too large for the game engine, after all.
ReplyDeleteMaybe some blocks should be marked "free" and they aren't, maybe I really need to optimize so that I lower the allocation watermark ... or maybe it's something else.
Some visualization of the spriteset content (preferably on SEDS's file window) would *definitely* help to figure out. A 32x32 sprite can provide one-pixel-per-spritepage. think about it.