Showing posts with label perl. Show all posts
Showing posts with label perl. Show all posts

Wednesday, March 10, 2021

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

Tuesday, January 08, 2019

debugging PERL regular expressions

Okay, I'm using PERL when I can, because it makes the job. I like how it is not distracting my train of thoughts when tackling a problem and how it makes scripts that are easy to hack later on. I love how it integrated regular expressions, but so far, I wasn't fond of how I had to test input patterns one after another with stripped down versions of the regular expression to find why it was failing.

And today I discover use re 'debug'.

With a simple line, I can get an overview of what the regular expression evaluator is trying to do when parsing a string (coloring added manually).

In yellow, we can track the position within the string: how much has been accepted so far. In green, a quick overview of what was just behind that position and what is just ahead. The blue code seems to identify the next operation that the regexp will do -- its program counter, sort of, and in white the detail of what is tried/done.

edit: let's not paint colors manually any more! A colorizer update for regex debugging !


 redebug=> sub {
          if (s/(END [(]0[)])$/$ign$1$norm/) {
            $compiling = 0;
          } elsif ($compiling) {
            s/(.*)/$ign$1$norm/;
          }
          if (s/^(Compiling .*)/$low$1$ign ___/) {
            $compiling = 1;
          }
          s/^(Freeing .*)/${ign}$1$norm/;
          s/^(Matching REx) ("[^"]+"[.]*) against ("[^"]+"[.]*)/$1 $high$2$norm against $low$3$norm/;
          s/(Found anchored)/$blink$1$norm/;
          s/^ ([0-9 ]+) (<[^>]+> <[^>]+>) * ([|0-9 ]+:)/ $blink$1 $high$2 $low$3$norm/;
          s/(Match succesful.)/$blink$1$norm/;
        },
        

Wednesday, March 16, 2011

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))

Thursday, October 14, 2010

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

Tuesday, January 12, 2010

blog backup scripts

Ok, Blogger provides you a .xml blog export for backup purposes, which happens to export virtually everything (including template and settings) into a RSS format. But what about your blog images, which imho account for a good 50% of this blog's spirit.

I gave blog2print a try, and they weren't able to grab more than a few jpg photos. So I went for my own, custom, regular-expression powered, post-processing perl script. Here comes the output. All the meaningful pictures gathered in a single folder, sorted by location in the XML file so that they can later be included in e.g. the output of a blogger2TeX tool ...

That makes 512 unique pictures (after fdupes duplicata deletion, thanks to Cyril for the tip) for ~350 posts (including 24 unpublished drafts)

Friday, March 27, 2009

vgmaps tool for RDS Game-Maker


bbl2map.pl

Et voilà. L'outil ultime : conversion des fichiers .MAP en allant rechercher les animations des monstres dans les .MON. Je suis encore loin d'avoir tout compris aux .mon (déplacement, etc.), mais au moins, j'ai de quoi me faire un joli musée de niveaux de nos jeux RSD Game-Maker. Pour ce qui est de faire une conversion .gam -> .nds, par contre, ce n'est toujours pas gagné. Si la plupart des maps se "compressent" assez bien sur des tiles de 8x8 (pour Badman II, en tous cas), la gestion des animations serait un vrai cauchemar dans un environnement pareil ...

Good news if you used to design games on RSD Game-Maker: i managed to build a fully-featured RSD .MAP reader that lookups .MON files (at least animations) to render a full map of your levels, with monsters depicted... Oh, it could still use the information from .GAM files to show you entry/exit points as well, i admit.

I guess anyone fluent in PERL could reuse the code to write a RSD->XXX converter given that you already know the map format for XXX. Unfortunately, that doesn't really bring me much closer to the "RSD->NDS" conversion/replay tool due to the silly 20x20 block size in .BBL files. Not much of a concern for handling the map (at least, in Badman II, most of the maps use quite few blocks and a plain conversion to 8x8 tiles does the trick), but animating such 20x20 blocks that are split over different tiles would likely turn into a nightmare. And trying to update a bitmap rendering of the level might be tedious (and boring) to implement, not mentioning the limited bandwidth to the screen's backbuffer , that would hit the framerate quite badly.
.

Thursday, March 26, 2009

BBL metadata.

Voilà. Une fois qu'on dispose de tout un jeu de .BBL avec les tileset correspondant, c'est bien plus simple de reconstituer le rôle des 20 bytes de contrôle ... C'est ce que fait de son mieux ce petit outil "bblmeta.pl" que je vous offre également.

Chaque ligne rappelle le numéro du bloc (en hexa) et sa position dans l'image générée par bbl2png (le premier, par exemple, r02 c12 correspond au premier canon, tourné vers la gauche sur la 3eme ligne de l'image). Suit ensuite les "flags" tels que lus dans le fichier .BBL puis l'interprétation de ces flags par le script bblmeta.pl

J'ai repris la technique des répertoires UNIX: un '-' chaque fois qu'il n'y a rien à signaler, une lettre sinon. Ainsi "B--a-K" serait un bloc solide (B) animé qui interagit avec une clé (probablement une porte). "--g-+-" est un bonus qui rapporte uniquement des points, etc. Pour être exhaustif, je dirais que le programme reconnait:

  1. Bloc, Floor, Wall ou ciel (-)
  2. Pickme : l'objet peut être ramassé pour l'inventaire
  3. g, l ou r : gravité normale, vers la gauche ou la droite. Les autres combinaisons ne sont pas reconnues.
  4. a : bloc animé,
  5. t: réagit au contact
  6. bonus/malus : H=hitpoints, x=kills, + : score
  7. L = 1UP, K=clé/porte.
En plus de ces "flags", certaines valeurs sont indiquées dans une liste entre parenthèse, comme la succession des blocs pour une animation, le nombre de hitpoints ou de clés, ou de points modifiés lors d'un contact , le numéro du monstre tiré (pour les blocs qui tirent des monstres), etc.

Here comes a second funny PERL script. It extracts meta-data from .BBL (Background BLocks), .CBL (Character BLocks) and .MBL (Monster BLocks) produced by RSD Game-Maker. If you used to write games with that editor, feel free to use that tool to retrieve all meaningful elements and port your old funware to some new platform. If you do so (or just plan to do so), please share the joy and post a comment.

This tool is a kind of "preliminary" reverse-engineering tool. It can tell you roughly what are the properties of individual blocks but detailed information may need to be looked up in the 40-digits hex string. Each line describes a block. Right to left you'll have the following information :

1c (r01 c13): 400100000000000000ffff1b64001c0400010000  --ga-x-  (a1b,100)(h-1)
^    coords   |--- complete hex dump of meta-data ---|  |flags|  |---details--|
+- block number
On the right side, "flags" tell you roughly what are the properties of your block. here you see an Animated block that has downwards Gravity and that hurts the player (x) on contact. Details tell you that it animates to block 1b after 100 ticks and that hitpoints are reduced by 1 on contact. On the left, you have block number (block #x pixels are located at bytes x*420..x*420+399 in xBL file) and the row/column coordinates on the picture generated by my former bbl2png.pl script.
Bref, ce n'est certainement pas aussi souple que l'éditeur du game-maker (et d'ailleurs, ce n'est pas un éditeur, juste un outil d'inspection), mais ça capturera la plus grande partie des cas que l'on retrouve dans un jeu de plates-forme comme les Badman.

Hope it Helps ^_^
PS: 1st byte is the index of the generated monster (0x40 = no monster generated), thus byte 2 is likely the delay between two such generations.

BBL to .png converter

J'avais pris l'habitude de faire un p'tit cadeau sur Internet pour mon anniversaire, et là, pour mes 30 ans, schnol. Avec les travaux dans la maison et le retour de Suisse, je n'avais rien à montrer. Quelle idée saugrenue m'a pris ce midi? Aucune idée. Mais je vous offre un petit script de conversion des fichiers graphiques du Recreational Game Maker (.BBL, .CBL et .MBL) vers des .png, plus pratiques à manipuler. download bbl2png.pl exemple d'utilisation :

perl ~/DS/SEDS/runme/bbl2png.pl /tmp/TOYZONE2.PAL /tmp/%.MBL m%.png --sprites

Here comes some pixels dump of sprites i've been working on in '97, at the peak of my RSD Game-Maker years. Each level had its very own tileset and spriteset (though there might be much shared things between two levels in the same "zone"). Behold Badman III, most likely the more complex (and unfinished) project with the RSD-GM ever. I finally managed to write a small ".BBL->.png" conversion script, meaning that i can retrieve *all* the graphics from all our previous games. 

Ca veut donc dire que je peux récupérer tous les graphismes de Badman et autres pour vous les montrer... Je doute qu'il y ait grand-chose à en tirer à part de la nostalgie ... j'ai tant appris en matière de pixel art, que même mes "plus jolis" boss sont tartes "by today's standards" :P En vrac, donc voici quelques sprites tels qu'ils sont présents dans la démo jouable Badman 3 (Badboyz are Back!). On y découvre "Ratman", d'après un T-shirt de T-Bob, qui ne sera finalement pas repris comme boss de la Cheese Zone. Juste après, Burner "relooké" qui laisse derrière lui une trainée de feu quand il court, avec un shading un peu douteux. Enfin, le gris aux oreilles rondes, c'est le "ratman" tel que vous pouvez l'affronter, avec son astro-flasheur "kirsch" et ces attaques de roues de gruyère.  

In "Badman III: Badboyz are Back", you can play either with Badman or Rubishbin (who you saved in "Badman II: Out of This World") in three insane environments: the Cheese zone, the Toy zone and the Ice zone. Each character had unique abilities giving them access to hidden areas. Rubishbinn, for instance, can do a spin-jump that destroy some blocks below him while Badman can dash under low roofs. I also reused the technique developed in Badman II for creating shooting bosses. The result was near to an unmanageable nightmare that turned short as I entered university: with only 5 playable levels, Badman III games already lists 44 'levels' in the game editor. 

Ce serait à refaire, je prendrais le "ratman" initial comme PNJ genre "Je suis le seul maître légitime de la Lune Fromagère, et je délivrerai mon monde de la tyrannie des BadBoyz ... Enfin, si tu veux m'acheter des grenades Petit-Suisses ou des Camemberts lacrymogène, ... " Et oui, le volet 3 de Badman était franchement inspiré de la mécanique de jeu de Megaman ... Suit l'Ice Zone, dont les monstres sont pas mal inspirés du niveau des glaces de Prehistorik II (auquel je rejouais cet été-là -- juillet '97 selon le .zip -- en version complète). 

On y retrouve donc un le fameux pingouin et un eskimo dont je n'étais pas peu fier à l'époque et un "lemmings xmas" qui était là juste pour le fun. Ce genre d'apparition était d'ailleurs assez habituel dans la série des Badman : le bonhomme-promo de Belgacom, Moktar sur son tapis volant, une bestiole rampante "façon Commander Keen", des p'tits robots tout ronds "façon twinbee land", une souris bleue mécanique "à la sauce Alfred Chicken", etc. Vous remarquerez aussi "Rex", le chat (private joke) utilisé dans des "cut-scenes" façon "Kirby's dreamland". Le mamhout vous paraît bizarre ? logique. 

Le game maker de Recreational Software ne supporte qu'une seule taille pour les monstres: 20x20. Un monstre plus gros est indestructible par nature et construit à l'aide de plusieurs monstres que vous tentez de déplacer de manière synchronisée ... ce qui se traduisait généralement par un désastre complet. Allez, je vous mets aussi Badman "himself" et son compagnon d'aventures "Rubish bin" ... On est plus très loin d'un extracteur de niveaux complets, avec les autres infos dont je dispose déjà 

PS : mon frère possède aussi une mine de petits "trivias" sur le développement des épisodes de Badman, qu'il reconstitue a partir des commentaires de ses .S3M ... Si vous êtes fan, bonne lecture.

Thursday, February 12, 2009

Script powaa!

Bon. Ouvrez un p'tit terminal (tcsh), on va s'amuser ...

display fairy.jpg
setenv FAIRY `eesh -ewait window_list | grep Magick | cut -f 1 -d :`
randomize `find /pingu/photos/ | grep -v thumb` |\
fe - "display -window $FAIRY '%' & sleep 8"
C'est ma manière à moi de me faire un petit diaporama de mes photos sur mon laptop, mode "discret: je travaille mais j'ai besoin de voir un peu mes proches".

J'vous explique ? Bon, tout d'abord, vous devez penser à tous ces programmes comme des "filtres" qui reçoivent des données par un côté (l'entrée standard) et qui en produisent de l'autre côté (la sortie standard). Un élément de base pour interconnecter les programmes est le tube ("unix pipe") représenté par la barre verticale. program1 | program2 attache les deux programmes de sorte que la sortie de program1 est utilisé comme entrée pour program2... Visualisez une usine avec des robots qui bricolent des pièces qui défilent sur un tapis roulant et vous n'êtes pas loin.

Comme certains programmes ne sont pas prévus pour recevoir leurs données sur l'entrée standard mais plutôt comme des arguments sur la ligne de commande, j'utilise aussi les guillemets arrière qui remplace dans une commande une expression par le résultat de son évaluation. Si add et mul étaient des programmes pour additioner et multiplier leurs arguments, on pourrait faire des expressions un peu plus compliquées à coup de add 5 `mul 2 3` qui serait transformé en add 5 6 avant d'appeler le programme add.

I love how scripting expands the possibilities of programming. Maybe I could have experienced something similar with Visual Basic, but that tool has never happened to be available on my Windows systems afaik. The code you see above is a script I use to periodically change one part of my screen's background as if it was a diaporama.

display FILE will just create the window and show one file. then the line with eesh will capture the identifier of that window into some variable and calling display again with -window $FAIRY will make it paint on the existing window instead of creating a new one.

That's already pretty neat, but I can push it further, like scanning through my pictures repository with find, filtering out the thumbnails with grep and randomize the output with a Perl script of mine that isn't even aware it is processing picture file names.

This is possible thanks to the unix pipe | and shell sub-expressions `sub expr` that gets a program called and its output injected as parameter for another program.

Bref, les programmes utilisés ici:
  • display, le programme d'affichage du projet ImageMagick hyper-standard. Par défaut il ouvre une nouvelle fenêtre pour la nouvelle photo, mais avec -window , il modifie l'image de fond d'une fenêtre existante. En l'occurence, cela me changera l'image affichée.
  • eesh, le kit du bricoleur pour enlightenment, utilisé ici pour récupérer la liste des fenêtres. Si vous n'utilisez pas enlightenment, le package wmctrl pourrait faire l'affaire ...
  • grep, le filtre passe partout, en standard dans toutes les distributions Unix, utilisé aussi bien pour retrouver la fenêtre dont le titre contient "Magick" dans la deuxième commande que pour retirer toutes les miniatures dans la deuxième commande
  • find, également un outil standard, liste tous les fichiers à partir d'un répertoire donné
  • cut : pour extraire un champ d'une ligne du type "fichier CSV".
  • setenv <var> <val>: pour donner un nom au résultat d'une exécution (en l'occurence, enregistrer le n° de la fenêtre d'affichage dans la variable $FAIRY)
  • randomize <args> : un p'tit script perl à moi qui renvoie ses arguments mélangés, ligne par ligne.
  • fe - "commande" : un autre petit programme à moi ("foreach") qui applique une commande à une liste d'arguments. Les puristes auraient utilisé xargs ou find -exec.
  • sleep <secondes> : pour marquer une pause entre 2 images, bien-sûr
Chouettos, non ? Allez, les amateurs de VBA. Vous mettez combien de temps pour faire ça ?

Wednesday, September 03, 2008

.spr

Okay. Let's say you've downloaded the latest SEDS version and gave it a try. You loved the pixel art you've drawn and hopefully pressed START + R + A to save them on your media card. Then you either transferred them with runme or simply used a media card reader to retrieve them.

SpriteA.spr at the card's root. Most likely to be your drawings. As a matter, it is.

But what are you going to do now with that .spr file that your file explorer doesn't know and that do not open in Graphics Gale, Photoshop or whatever other spriting program you could think of.

If you are a "power user", you may already have
perl installed or find it not that complicated to install. In that case, you're suggested to install the Image::Imlib2 package as well so that you can run spr2png.pl conversion script directly on your machine and have your sprites converted in a more user-friendly format.

If you're just a regular user, or if you haven't used SEDS often enough to find it is worth that much installation trouble, you still have an escape route: the brand new online conversion tool that can convert your art into a regular .png file with just the help of a regular web browser. Just select the picture with the "browse ..." button, click "post" and wait a couple of seconds to have the script doing the conversion and replying with the picture.

Have Fun ... i also submitted a "job offer" on sourceforge to find someone willing to write a batch conversion tool for Windows ... wait'n'see.


Costz dit : Mais on peu récup les sprites dans un autre format que le tien ?
Je veux dire y a un convertisseur pour que l'on puisse avoir au final une .png ou .gif ?


Oui, tout à fait. Il y a tout d'abord le script spr2png.pl qui, moyennant installation de perl et du module Image::Imlib2, permet de convertir tout ça localement sans soucis.

Et pour ceux qui auraient du mal à installer tout ça sur un Windows (sous linux, c'est juste apt-get install libimage-imlib2-perl), ou qui voudraient tout simplement essayer le sprite editor sans se prendre la tête, j'ai bricolé un convertisseur en ligne: tu uploades ton .spr et tu reçois le .png en échange.

PS: j'ai les sources en Perl du convertisseur et une esquisse du format de données avec le convertisseur en ligne. Je cherche quelqu'un qui connaisse la programmation windows (C, C++, VB, C# : tout est bon) pour écrire un convertisseur "user friendly" pour les wutilisateurs.

Si vous êtes partant, contactez-moi : pype_1999.geo@yahoo.com.

Friday, July 25, 2008

Encore une victoire de Canard !

Yes! j'ai trouvé le moyen de produire une animation Gif à partir d'une de mes planches de sprites. C'est encore fastidieux, et il faudra scripter ça, mais au moins ça marche (enfin, sous FF en tout cas). Accrochez vous à vos baskets, voilà ce que ça donne :
# convert .spr file into a tileset image (64xn*16)
perl DS/SEDS/spr2png.pl biloucoin.spr bcoin.png
# extract the 64x48 region where we have our coin
convert bcoin.png -crop 64x48+0+656 -repage +0+0 coinb.png
# extract individual frames for the animation
convert coinb.png -crop 16x16+16+0 -repage +0+0 coin1.png
convert coinb.png -crop 16x16+32+0 -repage +0+0 coin2.png
convert coinb.png -crop 16x16+48+0 -repage +0+0 coin3.png
convert coinb.png -crop 16x16+0+16 -repage +0+0 coin4.png
convert coinb.png -crop 16x16+16+16 -repage +0+0 coin5.png
# etc.
# produce the animation using the sequence 1-2-3-4-5-a 1-a-8-b-8-9
convert -loop 0 -dispose 2 -background darkgrey -delay 10 coin1.png 
  coin2.png coin3.png coin4.png coin5.png coina.png coin1.png coina.png 
  coin8.png coinc.png coin8.png coin9.png -loop 0 -delay 10 mycoin.gif
# here we are...
Howdy! I managed to produce an animated .gif out of my sprites. That's the first step towards an "beam out animation" feature in SEDS ;)

Thursday, February 14, 2008

[todo] runme reloaded

"Runme", c'est ma "combox" à moi. Entendez par là un petit outil pour la DS qui permet de se passer de linker et d'accélérer le cycle développement. Il est capable de transférer des fichiers d'un PC vers le répertoire "moving" de la DS à 90KB/s, techniquement capable (également) de transférer des fichiers de la DS vers le PC, mais pour l'heure, je me suis limité au choix des 4 fichiers édités par le Sprite Editor. Côté PC, il faut un programme spécial (petit script perl ou un programme java) pour "offrir" un fichier au téléchargement.

"Runme" is my all-in-one transfer and testing tool on the nintendo DS. The kind of "get-rid-of-your-linker" or "i-lost-my-media-card-reader" tool that is intended to boost software development on the console. It's my favourite way of transferring content from a PC to the console through WiFi at speeds approaching 90KB/s.
With the proper program running on your PC, it can also beam files out of the console (though i don't have a user-friendly interface for this atm).
Over time, it has gathered module player and bare game engine facilities, but it still lacks a couple of features to get a release of its own as "runme: reloaded".

Bref. Il serait temps que je fasse quelque-chose de "releasable" à partir de ce projet . Genre:

  • [wish] faire une version java qui intègre upload et download sur PC.
  • [done] permettre de choisir n'importe quel fichier pour l'exporter hors de la DS
  • [done] choisir le répertoire dans lequel les transferts s'opèrent sur la carte flash (pour l'instant, tout ce passe dans /moving)
  • [wish] prévoir un type "répertoire" pour l'importation vers la DS. Il apparaît comme une simple entrée dans la liste des transferts, mais quand on l'active, il crèe un nouveau répertoire sur la DS, recontacte le serveur et lui demande les fichiers un par un ... Ce serait bien pour tester VGDMS ^_^ (edit: remplacé par un server.pl qui présente les fichiers les uns après les autres).
  • [wish] intégrer les stubs "auto-update" dans la PAlib pour conquérir le monde...
  • [done] m'assurer que le démarrage d'un autre programme marche même lorsque les patches DLDI entrent en jeu.
edit: j'ai re-testé les patches DLDI ce midi. Au moins, le patcheur embarqué est cohérent avec lui-même et le fait que le "stub" qui passe d'un programme à l'autre soit en mémoire vidéo n'affecte pas son bon fonctionnement. Cherchons ailleurs ...
So the todo-list for the runme software include mostly integration of browsing widgets (to pick the import
directory or the exported file), integrate downloader and uploader in a single java program. I also need to support a "directory" transfer type which would make the DS ring back the PC and perform bulk transfers of many files at once (e.g. to test VGDMS).
The ultimate killer feature, though, would be to provide a twisted version of PALib that would be compatible with runme's program booting mechanism, but this means i first need to fix DLDI patcher embedded in the software.

Monday, October 22, 2007

tiles extraction ...

Un autre petit outil en Perl (basé sur la bibliothèque de manipulation d'images Imlib) qui décortique une image et identifie les tiles uniques (8x8) et le nombre de couleurs utilisées...
Il ne fallait pas grand chose pour en faire un convertisseur .gif->.spr un peu plus automatisé. Je m'y suis attelé ^_^. L'outil en question s'appelle "imlib2spr.pl" et est disponible dans le CVS du projet 'runme'.

I've been working on a new small (PERL) tool for SEDS/runme. "imlib2spr.pl" is using the "imlib" package to open your .gif, .png ... pictures and identify uniques tiles and colors so that it can then convert them into .spr files.
It also builds a map of how to reuse those tiles to get the initial image back.

Mais pourquoi chercher à transformer une image .gif en un tas de tuiles, me demanderez-vous. Okay, certaines images contiennent des zones un peu répétitives et pourront donc prendre moins de place en VRAM... et c'est tout ?

Ooh non! Notre DS est effectivement capable d'afficher directement des images 'bitmap' (c'est ce que je fais quand vous envoyez à runme un fichier .pcx), mais avec une taille maximale de 256x256 ou de 512x512, selon la configuration d'écran choisie. Impeccable tant que vous voulez une image fixe, mais imaginons que je veux faire scroller horizontalement une image de 320 pixels de large, je fais quoi ?

Je passe à 512x512 ? le bitmap fera alors 256K, presque la totalité de la mémoire vidéo!
Je tronque à 256x256 et je redessine une colonne chaque fois que je me décale d'un pixel ? Bonjour le code!

Maybe you wonder why i'm trying so hard to split a picture into small tiles while i've shown with runme that it was fully possible to display a .pcx (and thus .gif and .bmp aswell) image straight on the screen. Well, the reason is scrolling. You very well can show a 256x256 image on the DS screen (which is 256x192) and side-scroll it again and again (using the 'scrolling wrap' hardware option). That will take you 64K worth of VRAM. Now if you want instead to side-scroll a 320x200 image, you'll get into trouble unless you're agree to devote 512K of VRAM just for your background image.

On the other side, once you have 'tiled' your background, you can easily repeat it as many times as you want: it's merely a matter of a few KB, and you can easily rewrite offscreen parts of the map as the scrolling goes so that you keep showing the right stuff at the right time, with a 64:1 reduction of the stress on VRAM.
Since we are running on gaming hardware, i think we should make the best possible use of it, shouldn't we?

Well, demo and code for that will follow once the 7.11.7 day is over.

Sous GBA, pas tout ces soucis: l'écran faisait 240 pixels de large et le mode bitmap 256x256 aussi, donc on avait tout loisir de redessiner des blocs dans la partie complètement masquée de l'écran, puis de scroller un peu, puis de redessiner, etc.

Eh bien, si l'on prend la peine de convertir notre bitmap en "tiles", on peut continuer ce petit jeu: une fois les tiles en mémoire, une "carte" peut très bien contenir deux fois l'image initiale sans nécessiter d'avantage de mémoire vidéo (allez, quand-même 1 ou 2K de plus, mais c'est quand même mieux que de passer de 64 à 256K, non?)

Bref, c'est Cyril qui sera content. Lui qui me proposait y'a pas 48 heures d'ajouter un mode "construisons notre map" dans SEDS ... On en est plus très loin ;)


à la base, c'était ça:
#!/usr/bin/perl
use Image::Imlib2;

$image = Image::Imlib2->load($ARGV[0]);
print STDERR "$ARGV[0]: ".$image->width."x".$image->height."\n";
while ($ty<$image->height) {
  $tx=0;
  while ($tx<$image->width) {
  foreach $y (0..7) {
    foreach $x(0..7) {
      ($r,$g,$b,$a) = $image->query_pixel($tx+$x,$ty+$y);
      $r=pack("C1",$r);
      $g=pack("C1",$g);
      $b=pack("C1",$b);
      $colors{"$r$g$b"}=$ncolors++ if !exists $colors{"$r$g$b"};
      $tile.=$colors{"$r$g$b"};
    }
  }
  $tiles{$tile}.="($tx,$ty)";
  $tx+=8;
  $tile="";
  $ntiles++;
}
$ty+=8;
print STDERR ".";
}


print scalar(keys(%tiles)) . "unique tiles (/$ntiles) detected\n";
print scalar(keys(%colors)) . "unique colors detected\n";

exit 0;
note: il nous faudra installer le package libimage-imlib2-perl pour faire fonctionner le tout.


rem: pendant ce temps-là, Globoeil nous faisait une release de son "virtual game maker DS" ...
à découvrir sur globoeil.fr/vgdms ...

Wednesday, October 10, 2007

SEDS: user guide 0.1a

Puisque le développement de mon sprite editor peut reprendre (ça y est, il a sa fonction "wifi update" lui aussi), autant que j'en profite pour documenter son interface qui peut sembler a priori un peu rébarbative (oh, le doux euphémisme).

Je généralise l'utilisation du bouton "L" pour faire les "clics droits", permettant notamment de transformer le crayon en pipette, etc, et bientôt de faire un "flip" ou un "rotate" plutôt qu'un classique "scroll".

My sprite editor's development has been resumed thanks to the "wifi update" feature. So it is a good day to give a first userguide draft (the picture above). Note that the whole GUI uses the concept of "aLt-click", which is touching the screen while holding the L shoulder button. that's how you can pick a color in the grid rather than painting a pixel, or save your work in the spritetable. later on, it will als be used to flip the tile rather than scrolling it... Very soon, you will be able to switch between runme (the file transfer utility) and SEDS without power-cycling the console. stay tuned.

Si vous aviez déjà installé runme, vous pourrez bientôt basculer entre l'éditeur et le programme de transfer. Notez que la version SEDS-dkp20 est déjà en ligne (wifi update oblige) et que vous pourrez trouver un package complet sur sourceforge.


Utilisation simple:
copiez le fichier seds.nds sur votre carte mémoire, bootez-le, cliquez dans la grille pour dessiner vos pixels et référez-vous à la fausse-photo ci-dessus pour les autres actions. sauvez vos pixels dans le fichier A,B,X ou Y en tapant START-R-(ABXY), récupérez-les avec START-L-(ABXY). Tapez START-R-R pour sauver rapidement le fichier en cours d'édition.

Mise à jour par wifi

Note: Pour utiliser ces fonctions, il est nécessaire d'avoir installé exec_stub.arm7 et exec_stub.arm9 à la racine de votre carte flash.

Dans SEDS: Appuyez sur START puis SELECT pour lancer la sélection du point d'accès (automatique si vous avez déjà utilisé MarioKart ou un autre programme du genre avec ce routeur, manuelle sinon. Je ne pense pas que les clés WEP soient supportées pour l'instant).

Le programme se connecte alors à mon site pour récupérer la dernière version stable et l'enregistre sous "sedsw.nds" à la racine. note: c'est ce fichier que 'runme' tentera de lancer lors de l'utilisation du bouton 'edit' après un import de fichier .spr

Dans runme: Assurez-vous que vous avez bien copié dslurper.cfg à la racine de votre carte flash. Une fois connecté au réseau WiFi, appuyez simplement sur SELECT pour télécharger la dernière version runMEw.nds (également stocké à la racine). C'est aussi la version mise à jour que SEDS utilisera quand vous cliquez sur 'QUIT'.

Transfers par Wifi

Copiez les deux scripts server.pl et sink.pl
sur un PC qui est sur le même réseau WiFi que la DS, "server.pl" pour envoyer un fichier vers la DS et "sink.pl" pour recevoir un fichier. Comme ce sont tous les deux des scripts perl, il vous faudra d'abord installer perl sur votre machine (il est déjà là si vous avez Linux, facile à ajouter à cygwin, sinon, le projet ActivePerl devrait faire l'affaire).

Mettons que je veux envoyer xdad.spr, livré avec le software, que ma DS a reçu l'adresse IP 192.168.3.4 et que le PC, lui, a l'adresse 192.168.3.2, la commande à entrer (dans un shell) sera:

Code:
perl server.pl xdad.spr 192.168.3.4 192.168.3.2
Lançons maintenant runme.nds, on choisit son point d'accès (automatique s'il a été réglé avec mariokart ou un autre) et on voit apparaitre le fichier dans une liste. En cliquant dessus, on commence le téléchargement. C'est tout. En appuyant sur le bouton "A", on peut voir le fichier, écouter le .mod/.s3m/.xm/.it etc.

Supposons maintenant que je veux le récupérer sur le PC (oui, c'est idiot, mais c'est pour l'exemple), il me suffit de lancer
Code:
perl sink.pl other.spr 192.168.3.4 192.168.3.2
Ensuite, cliquons sur "beam out" ou l'on voit que le PC est prêt à recevoir un fichier et l'enregistrer sous "other.spr". Reste à cliquer sur "Tileset in Memory" puis sur 'other.spr' et c'est parti à nouveau.

note: cette technique ne marche qu'avec des fichiers de moins de 512Ko, ce qui n'est pas un problème pour vos sprites.

Saturday, December 31, 2005

coding [t.a.g.]

How brave you are! Truly !

I mean ... You made it! You've been reading through the *whole* set of "coding"-related topics. They weren't just todo lists, but true stories about behind-the-scene hacks, fixes, eurekas and such that turn dreams into reality.

You definitely deserve


     *
      }( 1 ){
        \ /*
       o[ ]o
     ___  ___
    /   \/   \
    /  ^   ^ \
    /__ooOOoo_
The Ultimate Ascii aRt Trophy of Awesomeness!

Franchement, je suis impressionné! Lire tous les posts de la catégorie "coding", c'est du costaud. Si ça n'avait été que des toudou-listes, mais non. Les hésitations, les bidouilles en coulisses, les correctifs, les eurekas, les victoires. Bref, tous ces petits moments numérisés qui ont conduit à réaliser un rêve ...


NB: I guess you have noted that I use tag cxx for things about c++, since blogger doesn't seem reliable in whether it supports '+' in tag names or not.