ghost busting with spr2png.pl

No matter how much I improved SEDS, I still can't "optimize" my spriteset below 1024 tiles without messing up something. So I had to admit a disturbing possibility: maybe my tileset is *really* corrupted, and has been so unnoticed for some times ... maybe I'm suffering the equivalent of infamous cross clusters.

Let's recap: in .spr files, you find BLCK section that provides you the tile number for each block (logical entity) on that page. Then, you'll find one FREE section per "ram type" (block, sprite, streamed animations and drafts) telling you which tiles could be reused because you deleted its content. Good so far... except when they disagree.

Corriger ce spriteset de la school zone s'avère décidément plus complexe que prévu. Après une nouvelle série de corrections apportées à SEDS, toujours pas moyen d'avoir les bonnes images. En tentant de "rétrécir" les images, je me retrouve avec plusieurs sprites qui partagent les même données. Un vrai méli-mélo (in)digne du système de fichier FAT sur lequel tout celà est sauvé.

Permettez que je vous passe les détails techniques: il y a deux marquages des tiles occupés dans un fichier .spr (disons "vertical" et "horizontal"), et là, ils ne sont plus d'accord. Une stupide erreur au moment de sauver les sections 'FREE' des différents types de graphismes.

I already had modified spr2png.pl tool with a --cleanup mode that renders horizontal stripes accross tiles that weren't listed in any BLCK section earlier in the week, and now I've just added vertical stripes on tiles that are listed in the FREE section. We should thus see only solid sprites or 'dotted' tiles. But that's not exactly what happens: instead, I've got quite a lot of sprites with vertical stripes, that are thus supposed to be kept, but that could be erased as soon as I'll start editing new stuff.

My first mission, should I choose to accept it, will be to fix the .spr file so that all tiles stay safe. Then will come the hard stuff. Where in the code is the ghost maker... Have I forgot to adjust free lists when copying things around between spritesets?

Hopefully, not. It seems to be simpler than this: I have 3 FREE sections for the 'sprite' tileset. My bet is that I failed to set the proper spriteram identifier and have all "sprite, draft and streamanims free tiles" applied on the sprite tileset ^^"

Repaired, and still not working

Want a funny trivia? altough I got the spriteset "repaired", it's still too large for the game engine, after all. So I still don't see spongebop at all, but just some Bilou feet/hands again >_<

Maybe 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.

At first, I thought some visualization of the spriteset content (preferably on SEDS's file window) would *definitely* help to figure out. Something like a 32x32 sprite can providing one-pixel-per-spritepage. But that'd be a bad idea.

I mean, *I* would find it handy, but it shouldn't be the problem of the sprite artist to organise the tileset so that sprites fit in. Doing something like "move this page to 'draft', click 'optimize' and then move the page back to 'sprite'" is a hack, not something I want to read (and definitely not write) in any user manual for my software.

The root of the problem is in the tiles allocation: it prefers allocating what has been recently freed, while it should prefer what has low values and would lead to a compact enough tileset. Think about it.

how to place monsters in LEDS

Oh, btw, I've updated the LEDS user guide page with instructions on how to add monsters in your level. That was some times ago ... I guess I was busy somehow by then.



Erhm... wait ... I still am (busy), am I not ?

such a mess ...

One file has the new (shrunk) inkjet ... the other has the survived ink swamp animation ... one has dumblador MEDS animation, the other lost them ...

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.

Oh, just not to forget it, the left-table on SEDS is still unable to offer 32x32 blocks properly, and it may still be required to switch back to the GridWindow before the right-table do it. That's a nuisance, and I think it took some 3 lines of code in AnimEDS to get it sorted out. Time for a merge-and-fix, dude-self. Done, thanks to doxygen-on-cybook ;)

cybook + doxygen = long

Le Sprite Editor est en rade, mon fichier d'images pour la school zone de plus en plus mal en point ... et pourtant je "perds mon temps" à essayer d'avoir du contenu 'bilou' sur mon nouveau gadget: le Cybook Odyssey. Encre électronique, écran tactile, ce n'est pas la noteslate que j'espérais, mais au moins il existe ... et avec un peu de chance, il me permettra d'avoir les yeux moins fatigués en fin de journée, au boulot.

L'appareil supporte les fichiers HTML en natif, donc les choses auraient dû être assez simples ... Sauf qu'en mode "lecture de fichier offline", les liens sont ignorés dans le mode HTML. Il me faut donc passer au format dédié "epub".

Je me suis perdu dans des tentatives de conversion doxygen xml -> docbook -> epub en passant par les feuilles de styles XSL de la bibliothèque boost ... alors qu'il suffisait de prendre un fichier HTML et de le passer à calibre pour qu'il me fasse un "joli" epub prêt à l'emploi (en près de 5 minutes quand-même :P), récupérant lui-même les pages inter-dépendantes, etc.

I wasn't much into amazon library, but I managed to purchase a french e-ink device to get some publications shown without having to print things all over the time: the Cybook Odyssey. It has a touchscreen (that was a must for me) and WiFi, and while it is not the NoteSlate I hoped to purchase, it should help me avoiding eye strain at the end of the day.

Since it natively supports HTML content, showing bilou-ish things on it should have been trivial, but unfortunately, if you check some HTML in offline mode, many things don't work. Hyperlink, for a start. And annotations. If I want to have some doxygen on it, I'll have to convert it to the dedicated e-book file format: epub.

Et là-dessus, je n'ai toujours pas corrigé plus SEDS ... et il est temps d'aller souhaiter bonne fête à mon papa ^^"

EDIT: note pour les autres utilisateurs de cybook: il y a malgré tout moyen d'avoir les annotations, surlignage et signets pour les fichiers PDF même si ça n'apparaît pas directement dans le menu contextuel. Tapottez un coup dans le coin supérieur droit de votre cybook (comme vous pouvez d'ailleurs le faire sur les .epub) pour avoir directement le menu "annotations" qui apparaît. C'est un peu hésitant (toucher/relâcher ne marchera pas, ni un petit glissement. Il faut vraiment une petite touche du bout du doigt comme si vous vouliez vérifier que la casserole n'est pas trop chaude sans risquer de vous brûler. Par contre, si votre pdf est un vieux document numérisé sans reconnaissance de caractères (au hasard, un mode d'emploi de C64 ? :P), oubliez tout ce qui nécessiterait un surlignage pour l'instant: le cybook prend vraiment trop longtemps à essayer de trouver le texte à surligner dans ce cas-là.

After some aborted attempts to go through docbook format, I realised that there was a tool (calibre) that could do straight HTML->epub conversion, producing some decent output. It takes a while to process the file, though. Easily up to 5 minutes. 

Oh, and you could have annotations and 'highlighting' with PDF files too, although it doesn't show up in the contextual menu. Just double-tap the upper-right corner to get the annotations menu showing up.

Bilou vs. Inkjet

Good thing: I at least have "real" pixel art for the inkjet. Something that I could use in-game without blushing. Too bad: it's oversized.

Ah bin, voilà: j'ai enfin des pixels pour l'encrier. Quelque-chose qui pourrait servir dans le jeu sans que je n'aie à rougir. Sauf que pas d'bol: c'est trop grand.

Les encriers sont plus grands que Bilou. ça au moins c'est clair. Que ce soit dans mes croquis ou dans la BD, mais pas deux fois plus grands. C'est d'autant plus ennuyeux que j'ai l'intention d'utiliser aussi les encriers comme des ascenceurs. Il faut donc que leur trou soit grand assez pour que Bilou y entre, mais juste assez étroit pour qu'il ne tombe pas dans l'encre. Il faudra que je les redimensionne, passer de la taille du milieu à la taille de gauche (24x24, je dirais).

Inkjets are larger than Bilou in both comic and concept art, but not twice as large. I could live with it if only Bilou was not using them as a transportation system. To achieve that, I need the "hole" of the inkjet to be just too narrow so that Bilou can't "fall" into the ink. That's clearly not the case with the middle inkjet. I'll have to resize it around 24x24 rather than 32x32 if I want it to work... and no: I don't really feel like scaling up Bilou :P

edit: drawing Inkjet is like playing DuckTales (GB): once you've found how to beat it once, it's easy to do it again. Small inkjet is now in the sprite file. Too bad, I did that *before* I merged back SEDS update, and saved the file with an old version ... which dropped my nice ink animation for the spriteset >_< I'll have to find back the trick I used previously to migrate some art between two sprite files.

fixing SEDS ...

(Flickr photo by amaky)

A blog is suppose to bring in updates, and yet after 6 years, I keep updating some posts again and again as the situation evolves. It happened again, I'm afraid.

So to keep you updated, I managed to fix the school spriteset using an upgraded version of SEDS. Spongebop now moves along and chase Bilou like a berrybat because I merely renamed "berrybat.cmd" into "spons.cmd" and then adjusted the animation statements :P

It turned out that most of the things I initially planned as "regression tests" for the editor trivially worked because they didn't care which SpriteRam they were working with... Yet many other things have been identified as broken/misbehaving, and will be fixed in the near future, but only after the revised SEDS is merged back on the trunk... and that will be after I'm back from my next conference. I'll allow myself the right to make SpongeBop behave as it should first, build up a proper animation for Bilou's walk and even to revise the pixel art for inkjet so that it indeed deserves the word "art" :P

Oh, mais oui, chers lecteurs francophones, merci à vous de rester là malgré mon emploi du temps surchargé qui me pousse à faire des posts monolingue pour l'instant.