I want to try your editors so much!

How could I resist to such a quote ?

Adeline Venture (hehe) in Shadow Of The Temple The puzzle platformer I really, really want to make some day.

I want to try your editors so much! But in order to finish, I will have to do it in an engine I already know well. Probably construct3 -- CastPixel

It made me want to pack a set of my dsgametools with contents of Castpixel's mockup pre-digested into a .spr file so that she could directly toy with the level editor ... perhaps also convert the tutogit scripts so that she'd get something playable!

So first thing to know is that SEDS works with 16x16 blocks. There is a perl script that can convert the mock-up into tiles but if used directly, it will be a complete mess as game assets.

1. 
   ensure things are aligned on the 16x16 grid as much as possible. That means the ladder half-way over pillar must be shifted. A few other things needs similar shifting on the mockup.
2. SEDS shows you 64-pixels slices at once. The scripts *can* handle wider pictures, but at the moment, they'll scan e.g. first row of 256x16 pixels and output 4 64x16 rows in the first page, then another 4x64x16 chunk etc. The result is barely usable, again, because many objects bigger than 16x16 will be de-aligned and will need to be re-aligned in the DS editor.
   
3. So instead, you may want to turn the mockup into a 64x* image where things are where you want. Todo: imlib2spr.pl should be able to scan the image in 64px-wide columns itself, so that this step becomes useless and the mockup remains readable.
   
4. The script may remove the background color, but when it does so, it also deletes fully background blocks from the output file. This is nice to avoid redundant data, but again, it screws up alignment on such a mockup. You can scribble something on those blocks or you may turn off the background color by giving another one with --bgcolor=ff00ff. Todo: have the imlib2spr.pl tool inject empty slots on the sprite page when it encounters such full-background blocks, to preserve alignment
5. B u t if I use --bgcolor=some-color, the tool will inject a fully-transparent block as block 0. This is required for proper operation of the game engine and the level editor, but this is useless on the sprite pages. And worse, having block 0 editable led to corrupted files in the past. todo: patch the tool so that the empty block is never used by the generated pages (and never allocated by the editor :P)

With all that taken into account, with a 64x* png file with the content of the mockup aligned on a 16x16 grid as often as possible, conversion is performed with 

SpriteEditor/bin/imlib2spr.pl cast-a-venture2.png venture.spr --nomap --nopack --blocksize=16

And the reverse operation to see how things went is

SpriteEditor/bin/spr2png.pl venture.spr /tmp/venture.png && display /tmp/venture.png

Once that looks fine, copy the venture.spr file on your SD card in the /moving/ directory, make sure you have SpriteEditor for DS at the root of your SD card and launch it.

• once launched, press START to enter the FILE screen
• click the |/_/ browse button to show the contents of /moving/
  
• if venture.spr doesn't show up, hold L trigger and touch the "UV" button on the alphapad to filter the list of files. (holding L lets you enter the second letter of each "button").
• touch the "venture.spr" name to load the file, then press START again to return to the edition grid.

 

Where are my thumbs ?

I'm trying to add support for spr.more in LevelEditor (so that we keep seeing monsters positioning while editing DreamLand maps ;) but it doesn't work well. After some debugging, I realize that the values for the 'animation number' stored in the first word of the 'TINY' section make no sense. Animation #17000 ? with 48 animations per sheet ?

A simple test with ./sprdo confirms that even if I just load-and-save a file that has meaningful thumbs numbers, we end up with bogus numbers in the saved file.

Still wondering what thumbs I'm talking about ? They are still 32x32 images produced while saving animations in AnimEDS that are then used in LEDS for monsters edition.

Watching the memory backing my vector through execution, I finally found a suspicious set of `free()` statements at the end of the 'extra/unknown data blocks to set of MEDS animations' function.

The history of that function is that it abstracted something from `spr.load` script statement so that `spr.more`can exist. When it is done with them, the GameScript used to dispose of remaining really-unknown data blocks. Such as thumbnails. They won't be needed while we play the game and they eat up significant amount of memory.

Then, there was the code of SpriteEditor, the FileModel, to be precise. It had been updated so that it could invoke the same sort of 'FromExtras' function, but since we're not interested in MEDS animations while editing sprites, template magic makes this whole function unused. And then is the new tool, that tries and use code meant to be for GameScript but in a load-modify-write setup. That one ends up with freed pointers in its array and then try to save back those opaque data in the file. This is where my 17000 comes from.

The perplexing thing is that AnimEditor itself doesn't seem to read back the TINY thumbnails, but still when I load a file from OtherFileWindow, I get no thumbs on my top screen. Not until I edit something and move to another page, that is.

It took me time to check everything, and it finally revealed that, yes, makeThumb() are properly invoked even for OtherFileWindow, as soon as we call MetaWindow::data_reloaded() to signal things were updated. But the setup ThumbsWindow::restore() installed to show and use the TileTable showing the thumbnails got screwed up by OtherFileWindow's default layers settings. forcing a call to THW::restore() within data_reloaded finally fixed the issue. So that means bilou.spr on lime DS is likely fine and I can download it to resume development of LevelEditor's support for spr.do ^_^ (erhm. Next time. It's quarter-to-midnight and I've got meetings tomorrow ^^")

edit: unfortunately, after retrieving bilou.spr and school.spr that had been edited by AnimEditor on the NDS, they still contain rubbish TINY sections... I'll have to work on a medsdo tool to study that...

• [okay] AnimationModel already has RenderThumbs 
• [todo] animchk wrongly claims the options of sprck.
• [okay] *::Load and *::Save should be in the model layer.
• [check] could we be missing vector::clear ?
• [todo] we shouldn't push a TINY if it wasn't rendered.
  

Oneliner to convert them all

fe -nx *.spr "perl ~/DS/SpriteEditor/bin/spr2png.pl 
        %.spr ~/hobby/dspr/demo-%.blk.png
        --maxheight=256"

fe -nx *.spr "perl ~/DS/SpriteEditor/bin/spr2png.pl 
        %.spr ~/hobby/dspr/demo-%.spr.png
        --extra --maxheight=256"

Another oneliner to gather them all, and in HTML bind them...

(echo '<html><body>' ; 
   fe *.png "echo '<div style=@display: inline-block;
     background: grey; text-align: center;@>
     <img src=@%@ title=@%@ style=@display: block;@>
     <small>%</small></div>'" ;
   echo '</body></html>') 
   |  sed -e "s/@/'/g" > test.html

Why ? Because I need to know which are okay, which need to be recovered and which need post-processing.

And then I realize that I cannot 'compact' the alternate spritesets (draft and animations), and one possible explanation for that is that the 'free tiles' information for that pool is incoherent. Maybe my `sprck` tool could fix that, but to be honest, its output is so cryptic that I might need to run it in DDD to figure out. 

• horizontal vertical tripes mean there's no pages using the block
• vertical horizontal stripes mean there's a FREE entry for the block.
  
• why is there so many FREE slots indicating that tile#0 is free ? (there's sprck_cleanup() to address that).
• even after it 'repaired' the file, I seem to still have the same 
• [done] fix spr2png --cleanup so that it works properly with --extra=1 and --extra=2.
  
• [dont] ensure sprck is capable of dropping FREE entries when a block is used on a page. instead, we have to mark them free
  
• [okay] ensure sprck can add FREE entries when no page is using a block - that's automatic in -repair mode.
  
• [done] have fe and color.pl and whereami hosted in DS/bin (or DS/tools/ or wherever it fits) on Codeberg
  

spr.more et sprdo

J'avais prévu de commencer par "Bon, ça commence à prendre forme", mais le temps que me mette à blogger, j'ai presque fini. L'idée est donc de montrer qu'il est possible de charger les sprites d'un jeu GEDS en deux fois, avec un morceau pour le personnage principal et un morceau pour les monstres, par exemple, histoire de pouvoir avoir des monstres liés à l'environnement traversé par notre personnage (comme dans quasiment tous les jeux assez longs).

Si je dis "les monstres" et pas "les blocs", c'est que dans leur cas, le fichier .spr contient aussi les animations, et que ces animations font directement référence à des numéros de page. Charger en deux fois, ça voudra donc aussi dire modifier à la volée les animations pour s'adapter aux nouveaux numéros de pages. C'est codé, mais pour le tester, il me faut des fichiers à fusionner. Or jusqu'ici, je n'ai pas énormément de fichiers .spr avec des animations. J'ai l'école, le personnage-easter-egg de la présentation de AnimEDS, peut-être un 'papa Noël' quelque part (mais où?) et peut-être un badman (mais où??).

Bref, j'ai fini par me dire que le plus direct, c'était sans doute de couper bilou+école.spr en deux fichiers bilou.spr et école.spr pour montrer qu'on pouvait les recombiner ensuite. Pour ça, ça m'a semblé utile de revenir sur un de mes outils de hacking de fichiers .spr: sprdo. Il s'agit d'un programme linux tournant en ligne de commande et qui utilise le même modèle de manipulation des .spr que le Sprite Editor lui-même. (mon collègue parlerait-il de code métier?). 

Un argument Lfilename.spr, et voici un fichier chargé. Un deuxième argument pk6, et on fait comme si on effaçait la page n°6. un p? et on voit des informations sur chaque page présente dans le fichier en mémoire. C'est un peu primitif, mais ça fait l'affaire.

Il fallait donc y ajouter une commande "montrer l'animation unetelle" puis faire en sorte que "supprimer la page unetelle" supprime aussi automatiquement les animations qui y font référence.

ça n'a pas été sans mal, mais j'y suis presque (reste à "nettoyer" les fichiers .spr de tous ces sprites qui n'ont plus de raison d'être, histoire de ne pas dépasser les 64K au moment de fusionner les deux. (normalement, j'ai déjà du code pour ça)

edit: on y était presque. Inkjet et les power-ups se sont chargés correctement. une partie de Bilou.cmd ausi, puis on arrive à une animation située sur la "deuxième page" d'animations avec Bilou (0311) et là bardaf: il n'y a plus personne. En compactant le spriteset les doigts dans le nez, sprdo m'a visiblement perdu certaines animations (la plus haute étant la n° 107 alors qu'il faudrait que j'aille jusqu'à la 129)

• [done] use the right anim (the one using the right page) for the waves
• [done] apply waves animation from the proper page (that also fix blinking of Bilou's limbs)
  
• [done] pendat and blador use proper shared limbs page
• [done] understand why the heal pick-up is gone
  
• [done] proper animation when we pick up a bonus
• [done] proper animation when we bounce on an eraser.
  

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.

catch this!

A new animation and a good deal of "sprtools" to merge pixels drawn on "lime" DS and animations built on the DSi ... Unfortunately that will not be enough. There's one "dead" moment where you cannot see the "grab-in-the-air" animation whatever you do: when Bilou reaches the top of his jump. The reason is that there's already a "transition animation" running at this time, and that there is no way so far to cancel such an animation for another. I may have to fix that before I can proceed any further: it will likely be very important for super powers.

Une nouvelle animation, quelques coups de sprtools pour fusionner les pixels dessiner sur l'une des DS et les animations présentes sur la DSi. Eh pas de bol: ça ne suffit pas pour avoir un mouvement 'attraper en l'air' qui rendrait le gameplay de SchoolRush plus fluide. En fait, ça marche presque tout le temps sauf lorsque Bilou est au sommet d'un saut. La faute à l'animation de transition qui s'active à ce moment là: le moteur de jeu n'a pour l'instant aucun moyen 'd'annuler' une animation de ce genre. Je vais aller corriger ça, parce que ça risque d'être critique pour les coups spéciaux.

• [done] "force" flag to override transition animations
• [done] make "grab" a dedicated state
• [done] edit areas directly in AnimEDS
• [done] import AnimEDS areas in GOB states
• [done] selectively activate/deactivate areas in AnimEDS

extractanim.pl

Maybe you wonder why, after two teasers on "the great walking pendat", you still can't see it animated ? Well, the thing is I still haven't got any competent animation exporter so far. All the previous animations from AnimEDS were either hand-generated from static snapshots, or screencasts from either AnimEDS in desmume or from the game engine.

But that screencast tool (byzanz-record) shows its limits when one wants pixel art-level animation, and not merely a gameplay teaser: it's introducing dirty pixels all over the place.

Voilà un moment que je vous mets l'eau à la bouche avec "mon crayon qui marche", et vous n'avez toujours pas eu droit à une petite animation. Pourquoi ? eh, ben parce que je n'ai pas encore d'exporteur d'animations. Je m'en suis tiré jusqu'ici avec des animations bricolées à partir de screenshots ou des 'screencast' convertis en .gif animés tandis qu'AnimEDS tournait dans l'émulateur desmume. C'était sympa, mais l'outil de sreencast n'est pas complètement convaincant pour du pixel-art: il a trop vite tendance à rajouter du dithering dans tout les coins et des pixels parasites.

Du coup, je reprends ma doc de Imlib2 histoire d'extraire les différentes images d'une animation en .png à partir de ses descriptions puis on construira l'animation dans un 2eme temps.

So I refreshed my brain with API of the Imlib2 library I used for spr2png a while ago and started a proper animation ripper for my own .spr file format. I plan to first build static frames in .png and let a post-processing step build an animation out of that. I bet swapping will be the most annoying feature to support.

Stay tuned ...

hmm ...

edit: Well, the tools have progressed, that's sure. I still need to hack support for 32x32 blocks, though. On the other hand, it's pretty screwed for the pendat: I used pencil tiles as a quick replacement for pencil sprites content, but that's not a valid approach in the game engine, and that isn't either for the extractanim.pl tool :P

But with the "apply change to this frame and all the following" button, replacing the page and recovering graphics is a matter of 5 minutes with the DS in hands ^_^

Comme vous l'avez deviné, le truc-machin en haut est tiré d'un des premiers essais de l'outil. Il a fait de son mieux, le brave, mais j'avais été pécher mes morceaux de crayons dans la spritesheet 'blocks' plutôt que dans une spritesheet 'sprites'. Et extractanim.pl ne charge pas les blocks, évidement. Heureusement, j'avais ajouté une option "appliquer les changements à cette frame et toutes les suivantes" dans AnimEDS, du coup j'ai pu corriger tout à en 5 minutes DS en main.

sprfix

Il me manquait un dernier outil à ma panoplie d'outils destinés à manipuler les fichiers .spr ... je m'en suis rendu compte en rédigeant le post sur sprsplit et dumpanim: sprfix.pl, un outil capable de lire un .png édité et de ré-encoder les nouvelles images dans un nouveau .spr

As soon as I got sprsplit.pl and sprmerge.pl written, I figured out I still had to write a new tool: sprfix. Its goal ? to do the opposite of spr2png -- which I've been using for years to "export" my graphics -- and re-inject new pixels where they're supposed to go. After all, using a picture editor tool such as the Gimp seems the most natural way to recover some tiles from a former file, no ?

La manipulation est encore un peu complexe, avec des étapes de préparation puis de fusion, mais finalement, un outil comme "the Gimp" est encore ce qu'il y a de plus naturel pour faire de la récupération de données, même si les copies de page à page m'ont plus ou moins permis de m'en sortir jusqu'ici.

sprsplit.pl ; dumpanim.pl

SEDS, LEDS and AnimEDS use a dedicated file format: .spr, which is not very complicated, but specific to this project. The rationale is that, given the limited resources on the DS, I don't want to mess up with parsing or encoding of complex representation. I've got chunk of data, which have a given size and a given "type". This is how IFF files used to work back in the Amiga times, and I don't believe there is need for more over here.

However, with the toolset growing in features, hacking .spr files with an hex editor becomes tedious. A few weeks ago, I came up with two small tools -- sprsplit and sprmerge -- that can explode a .spr into one-file-per-chunk so that one could more easily e.g. replace a buggy animation with a sane one (from a previous file) without losing updates on the graphics themselves. Granted, a separate .anm file with the animations alone would have saved me the trouble :P

Bien: Bilou marche à gauche et à droite, escalade la règle, l'encre est animée et la "zone de collision principale" a fini de changer au moindre mouvement. Mis à part le côté 'bricolage' de la map et un nombre effrayant de messages de débug au démarrage, le niveau-test pour la school zone commence à devenir un brin plus propre. Dernier couac avant de m'intéresser de plus près aux "transanims": un à-coup dans la démarche de Bilou (alors que l'éditeur d'animation m'en fait un rendu parfaitement fluide ...)

Je sors donc un des petits outils développés dernièrement -- sprsplit -- pour "éclater" le fichier .spr correspondant en 'blocs logiques' histoire de repérer plus aisément l'animation qui cloche. Ensuite, un nouveau petit outil -- dumpanim -- va (enfin ;) me permettre de "décompiler" les commandes pour avoir la confirmation qu'une des commandes "délai 2 frames" n'a pas été convertie en "instruction pour l'éditeur d'animation" mais qu'elle reste bien présente dans les instructions adressées au moteur de jeu.

I've been one step further today, with a small "dumpanim" tool that present in a readable(?) format the content of an animation. It's crude, for sure, but less than mentally converting 0x2104fffe into UPDATE|COORDS|4|-2|-1 or 0x01000002 into CONTROL|DELAY|0x0002, etc. Here's how to make sense of its output:

• :**=xxxx : this is a "definition", such as page numbers, box size, etc. They're only read once
  
• .s?=yyyy : indicates that sprite #? should be changed
• .c?=xx,yy : indicates that sprite #? should be moved to (relative) coordinates xx,yy
• .m=xx,yy : indicates that the whole object should move by xx,yy
• !dxxxx : indicates that we should pause for xxxx frames before going on with playback
• !loop, !pop, !done : end-of-animation notifications
• // : an annotation for the editor (typically, how to place frames on the timeline when only the movement of the GOB guides the playback speed).
  

Now that AnimEDS' export code is fixed, I have great walk animations. Huzzah!

Mais bon, assez ri: la maison a besoin d'un coup de pouce pour se ranger ... entre les chaussettes et dumblador qui se bloque dans tous les coins, je vais devoir ajuster mes priorités :P

raymanim.spr

Ma fée et ma loupiote sont chez Mamy Laine ... j'en profite pour bricoler mon éditeur d'animation. La version améliorée du script "imlib2spr.pl" (capable d'importer les images du RSD game-maker, souvenez-vous!) m'a permis de récupérer des têtes et des corps de Rayman, mais pour les mains et les pieds il me fallait de préférence du 16x16.

C'est l'occasion de rendre enfin fonctionnel le script sprtool.pl destiné à importer des spritepages d'un spriteset à l'autre. Me voilà donc armé d'un "raymanim.spr" pour tester le code de mon éditeur d'animation sans devoir (re-)passer par la case "pixel art". On devrait gagner du temps.

Using the scripts I developed in late October last year and some bug-fix on the sprtool.pl script that was longing for revival since 2008, I managed to build the perfect test-case for the in-progress animation editor: a rayman spritesheet with head and body as 32x32 sprites and a set of hands/feets as 16x16. This time with my beloved PSX sprites :P

(PS: Rayman est un personnage (C) Ubisoft, apparaissant ici à titre de "fair use" (pour ceux qui aurait passé les 100 dernières années dans un auto-cuiseur au fond de l'océean))

Small step for me, Giant leap for Badman

I guess this is another instance of "I just can't help", and I can only hope I'm not to blame. As I was working on retrieving more content for Aderack's Wiki, I stumbled upon that previous post where I was listing things that were needed for an anniversary edition of Badman on DS. One of them was "produce .spr files out of extracted BBL files", somehow. Since I was sick last week, I could hardly focus on Apple Assault or any "real" coding, but hacking perl scripts wasn't too hard.

Alors que je tentais d'expliquer à Aderack que "non, je ne cherche pas à porter les jeux Game-Maker sous DS", je me rends compte que le principal obstacle technique à une version anniversaire de Badman -- les tirs -- est maintenant résolu. Alors vu que j'étais trop naze pour réfléchir la semaine dernière, j'en ai profité pour bidouiller du script Perl de-là de-ci histoire de peaufiner la conversion des fichiers .BBL en .SPR. On ne s'emballe pas : ça reste hautement expérimental et artisanal, mais à force d'ajustement, j'ai fini par pouvoir sortir les sprites du jeu dans un setup "un sprite par pavé de 32x32 pixels" mieux adapté à une conversion vers le format SEDS.

The first step was to update bbl2png.pl so that it accepts the --width=32 --height=32 options that are required for inserting padding and --xoffset=6 --yoffset=12 that allow 20x20 sprite positioning within 32x32 frame. Piece of cake.

I had a bit more difficulties with making the resulting image converted into a regular .spr, especially because the tools I used so far were targetted at importing maps, not sprites. A bit more tweaking allowed perl /home/pype/DS/SEDS/runme/imlib2spr.pl badman-cbl.png badman-cbl.spr --blocksize=32 --bgcolor=420042 --nopack --nomap to properly produce the sprite sheets I wished to have, with 10 Game-Maker sprites per sheet ... ready for action :P

Je dis "mieux adapté", mais rien n'était encore joué. Mon bon vieux script "imlib2spr.pl" avait en son temps été conçu pour produire des maps destinées à tester mon scrolling, absolument pas à remplir des pages de sprites avec un nombre réduit de blocs 32x32. Il m'a donc fallu un brin plus de chipotage pour parvenir à refaire un fichier qui soit accepté par l'éditeur, mais ça y est, photo à l'appui !

On verra bien s'il finit par en sortir quelque-chose :P

spraddpage et compagnie.

Bon, puisque SEDS est "réparé", j'ai essayé de ramener l'entièreté de mes graphismes vers la DS. Certains avaient été faits sur la DS de mon frère (l'appleman, par exemple), d'autres sont des retouches dans Gimp, d'autres encore viennent du "vieux" jeu de tiles (oui, oui, celui qui a tout explosé en dépassant les 1024 tiles ;)

Découper, aligner sur la grille, rogner, convertir, re-convertir, compresser les palettes, transférer, fusionner, re-transférer ...

Je vous donne un petit aperçu en image de ce que ça donne, simplement pour fusionner un .spr qui était sur la DS et une image .png déjà préparée qui traine sur le PC ... puis je vous laisse imaginer le tableau quand il faut répéter l'opération avec quatre sources différentes ^_^

Ennfin. Je crois n'avoir rien perdu ni oublié dans la bagarre, ce qui relève presque de l'exploit !

spr2html ^_^

Il parait que j'ai tendance à utiliser HTML pour tout et n'importe quoi ... j'ai bien peur d'avoir remis ça ... J'avais bien un petit script capable de transformer une image (de préférence un niveau de jeu) en un 'SpriteSet' (que j'utilisais pour les tests de scrolling), mais jusqu'ici je n'avais rien d'équivalent pour le sens "retour".

Et comme j'ai un peu la flemme d'écrire des pixels sur une image .png, je me suis plutôt tourner sur une jolie petite table HTML. Avouez que le résultat est plutôt réussi, non ? bon, évidemment pour l'instant on ne voit encore que les "tiles" un par un, tels qu'ils sont dans la mémoire vidéo, mais encore un peu de chipotage, et je pourrai les voir par "bloc" de 16x16 ...

De quoi simplifier les procédures de conversion de données que je vais devoir faire... Parce que là, sans un éditeur de map, je n'irai pas beaucoup plus loin. Animer les pommes qui n'utilisent pas des tiles consécutives. bof.

So far, the tiles you edited with SEDS could only be opened with SEDS (or shown on your DS screen through the 'runme' companion program). That was true until yesterday. Here comes the "spr2html" converter tool that can turn those "opaque" .spr files into a bunch of HTML tables that show palettes and tilesets contained in the spriteset. So far, it is mostly a debugging tool for the other manipulation scripts (merging sprite sheets, converting colors, etc) that prooved to be more efficient than beaming files to the DS and back, but it should be quite trivial to upgrade into a full-featured "exporter" that would produce .png pictures straight out of my .spr files...

edit: et je me rends compte de la raison des palettes "toutes mélangées" que j'ai obtenues dans mes "livres de sprites" qui rassemblent plusieurs planches séparées: je comptais les couleurs 1,10,11,...,19,2,20,21, ... 29,3 ... à chaque étape, alors forcément, quand on répête ça, on finit par un jeu de couleurs tellement mélangé qu'on est prêt pour une petite belote :P

oh, for those who wonders, i've used the "bgcolor" attribute of "td" tags and and solely filled my table cells with to ensure they'd have the proper size. That doesn't seem to please all browsers around, but as long as one of them (konqueror, but not firefox) renders it fine, i'm happy.

LBM & Linux

Je suis un vieux de la vieille qui a commencé ses pixels sous MS-DOS. Et de temps en temps, j'aime pouvoir récupérer mes vieux dessins tout pixelisés. Mais voilà, bien peu de programmes supportent les fichiers .LBM de mon ancien Deluxe Paint II enhanced :(

Sous ubuntu, pourtant, le package netpbm fournit un outil ilbmtopbm qui servira à ImageMagick (les programmes 'display' et 'convert', entre-autres) pour passer du format LBM au format PBM (Portable Bit Map) -- inconnu de tous, sauf de la bibliothèque ImageMagick qui peut pratiquement tout faire à partir de là.

Reste que imagemagick persiste dans l'idée que mes fichiers Deluxe Paint devraient s'appeler ".ilbm" et pas ".lbm". Comme c'est pénible et que je suis geek, j'édite le fichier /usr/lib/ImageMagick-6.2.4/config/delegates.xml et là ou on voyait une ligne "decode 'ilbm', je passe à

  <delegate decode="lbm" command='"ilbmtoppm" "%i" &gt; "%o"' />
  <delegate decode="ilbm" command='"ilbmtoppm" "%i" &gt; "%o"' />

Bref, voilà comment mon frère a maintenant mes petits sprites de Kid Paddle pour les envoyer sur le forum de Midam ^_^

(packages à installer: libimlib2, imagemagick et netpbm/libnetpbm10)

sprtools (t.a.g.)

Wow. You've gone through all the posts about my own tools for my own SPR file format ! I'm impressed.
It may sound an odd idea to run your own file format when doing a video game. This is mostly motivated by the odd memory structure of the DS video chip, tiled to the bones. '.spr' file are mostly a VRAM dump with IFF-like headers, created by my SpriteEditor. "sprtools" are all the PC-side programs that manipulate those dumps, converting, extracting, recombining pixels and checking more complex data structures embedded within the file, such as the list of "free tiles" within a chunk of video memory.