SEDS 32x32 needs you

Les béta-testeurs sur les forums sont assez unanimes sur un point: 16x16, pour l'édition, c'est un peu juste.

Je m'attaque donc au support de blocs plus grand (32x32 pour commencer, mais de manière à pouvoir supporter les résolutions classiques des sprites GBA/DS, à savoir 32x16/16x32 ou 16x8/8x16 également).
Ca fait pas mal de chose à réviser dans le code (d'autant que je ne peux pas garder le même type d'affichage de grille à un autre niveau de zoom: on ne verrait plus rien), mais j'ai déjà pu faire quelques essais de tracé dans la grille 32x32 ce midi.

L'ennui, c'est que le touchscreen de la DS ne permet pas un tracé suffisament précis à cette résolution. En clair, ça ira pour donner les "grandes lignes" d'un dessin, mais pas pour une édition au pixel près :(

SEDS has been now officially advertised on some NDS forums, and i got plenty of feedback from beta-testers. Among other things, for many guys, 16x16 canvas is just too small, so i'm now trying to have 32x32 edition to work. That makes many things in the code to be adjusted, including reviving the alternate grid display -- and those are getting in place.
The one thing that is more annoying is that 'pixels' are then only 4x4 wide if i want the full 32x32 sprite displayed -- and imho, 4x4 areas are too small to be accurately enough plotted directly with the stylus. It sounds thus that i'll keep this experiment for "rough sketches", but that we will still have to work with a higher zoom level of a sprite sub-region.

A re-réfléchir, donc...

Dans le même ordre d'idées, la palette n'est pas toujours évidente à utiliser. Dans ma manière d'utiliser l'éditeur, ce n'est pas bien grave parce que je travaille essentiellement avec les flèches (couleur suivante/couleur précédente) ou la pipette, mais je dois reconnaître que cobain a mis le doigt sur un point noir. Et déplacer la palette plus loin du bord n'a pas arrangé grand-chose: cliquer dans une case 4x4 sans en sortir, ce n'est pas une mince affaire sur le touchscreen de la DS.
Le mieux, ce serait sans doute de "doubler" la palette d'une zone agrandie des 16 couleurs autour de la dernière couleur choisie ...

Similarly, the palette isn't that easy to use accurately for people who haven't fine-calibrated their stylus input. I don't care too much myself since i'm not that much using the palette directly -- i make wide use of "next/previous color" with the Dpad and the "color picking" on the grid... The best alternative i can think of would be to offer both the full palette with 4x4 per color, and a "quick pick" area where you have access to the 16 colors around the one you just clicked, but with e.g. 8x8 region per color.

pre-release 0.1 beta-test for download here

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

SEDS Multipage

ah, y'a pas à dire: c'est agréable d'avoir un environnement de développement capable de mises à jour rapides ... En quelques coups de cuiller à pot, j'ai pu, hier soir, goupiller la première version de SEDS capable de gérer des fichiers .spr multipage. Enfin la possibilité de dépasser 48 sprites en un fichier (ça devenait vraiment problématique) et de réorganiser mes petits dessins par thèmes (un seul fichier pour toute la forêt, avec une page contenant les blocs de terre, une pour les arbres, une troisième pour les pommes, etc.)

Wow, needless to say, it's really a good thing to have software update to speed up application development. Just a couple of edit-compile-update loops were enough to brew the first version of SEDS that can manage multi-page .spr files (which had been tested in runme a couple of weeks ago). That means i can at last break the "48 sprites per file" limit and reorganize my own tiles theme-wise, e.g. grouping all the forest-related tiles with one page for dirt blocks, one for the tree trunk & roots, anoter one for in-progress tree tops, one for the apples, and so on.

C'est aussi un premier pas vers la possibilité de mélanger des blocs 16x16, 8x8 (pour les pieds et les mains de bilou, entre autre) et 32x32 (l'encrier).

Bon, ceci dit, pour l'instant, les réorganisations sont pénibles au possible, mais c'est juste parce qu'il me manque une interface pratique pour ce genre de tâche :P

Et il a fallu faire tout celà sans que les aventuriers qui avaient téléchargé la release d'hier ne se retrouve temporairement avec un programme inutilisable suite à un update malencontreux... ce qui n'a pas été sans mal :P

This is also the first step towards the ability of mixing 16x16, 8x8, 32x32 (and other sizes coming) resolutions in a single editor/spriteset, which will be crucial to go on working with Bilou's world. Well, right atm. "reorganization" is as tedious as moving files using MS word, but that's still better than no reorganization at all :P


Allez, ça mérite bien une "0.2"

SEDS revived.

un bouton "quit" pour revenir de SEDS à runme, la fonction "auto-update" sur SEDS (donc, si je corrige, je recompile, je pousse 'start/select' et je redémarre le programme remis à jour), un bouton "edit" dans runme qui me permet de basculer vers l'éditeur avec la planche de sprites qui vient d'être téléchargée ...

Hit on "edit" in runme, and you are forwarded to SEDS that will start editing the tiles you have previously downloaded. Hit START-SELECT, and you upgrade your copy of SEDS via the WiFi. Click on "quit" and you'll return from SEDS to runme, ready for beaming out...
In other words, all the pieces of the jigsaw are starting to fit together. I shooted a video to show off on youtube the whole process, but i couldn't wait for the 111 MB to get uploaded :P so you instead get that picture of "spector" i sketched during the first tests of WiFi-enabled SEDS (which wasn't able to save anything by that time). If you need help, feel free to describe what you're trying to do and where you're stuck in a comment, so that i can start a sort of FAQ for the soft.

bref, tout ce petit monde s'organise et commence à interagir. J'ai même pris une vidéo pour essayer de vous montrer tout ça... ouais. on ne sait rien lire des boutons sur lesquels je clique, et on voit surtout ma grosse tête en miroir, le pull de ma fée et ma cuisine méticuleusement rangée. Le tout prenant 111Mo ... j'ai interrompu l'upload pour vous resservir un 'spector' gribouillé du temps où rien de tout celà ne voulait marcher.

edit: petite release reprenant tous (j'espère) les fichiers utiles: seds-n-run.zip.

Vos commentaires sont les bienvenus pour construire une petite FAQ.

/dev/tcp ou netcat ?

En réaction au blog de bodman, qui nous présentait une manière élégante (tirée d'un autre blog: unixjunkie) capable de lancer des requêtes HTTP armé du seul shell "BASH":

exec 3<> /dev/tcp/www.google.com/80
printf "GET / HTTP/1.0\n\n" >&5
cat <&5
exec 5>&-

qui se soldait sur mon ubuntu invariablement par un "bash: /dev/tcp/www.google.com/80: No such file or directory". Intrigué, j'ai un peu cherché sur les forums, puis j'ai téléchargé les sources, et dans le README, je trouve ceci:

9. Why is bash configured with --disable-net-redirections?

It can produce completely unexpected results. This kind of
feature should not be part of a shell but a special. tool. And
that tool has existed for years already, it's called netcat.

aha. man netcat, alors ...

netcat is a simple unix utility which reads and writes data across net-
work connections, using TCP or UDP protocol. It is designed to be a
reliable "back-end" tool that can be used directly or easily driven by
other programs and scripts.
In the simplest usage, "nc host port" creates a TCP connection to the
given port on the given target host. Your standard input is then sent
to the host, and anything that comes back across the connection is sent
to your standard output.

ma réponse de TCSHeur sera donc:

debian> echo "get / http/1.0\n\n" | nc www.google.com 80

Je vous laisse juge ^_^

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.

The Coding Front

Quelques nouvelles en vrac du développement DS:

• les composants "wifi/update" ont été extraits vers une bibliothèque (c'est ma toute première bibliothèque en C/C++ ;), ce qui devrait simplifier leur intégration dans SEDS.
• j'ai maintenant un transfer bi-directionnel wifi entre "runme" et la station PC: on peut par exemple "downloader" un fichier .pcx, faire sa capture de sprites ou de tiles puis "uploader" à nouveau le fichier ainsi produit
• le développement sur SEDS reprend. Première version avec le "nouveau" devkitpro (donc le même que "runme") mais ça plante encore dans tous les sens, bien-sûr ^^"

Et pas encore de photo pour illustrer tout ça: mon appareil trouve ma console trop sombre et trop palote.

raw news from the coding front:

• components for WiFi and software update have been extracted into a library, which should ease their integration into SEDS
• I now have bi-directional Wifi transfer between 'runme' and the PC. We can for instance download a .PCX file, grab sprites or tiles and then upload the resulting spriteset back on the PC.
• That means i have started working on the sprite editor again: i compiled today the first version using the "new" devkitpro release, which of course is still crashing all the time :P

(ps: l'image vient du projet dslinux. c'est scandaleux, je sais, mais comme je suis occupé à transférer des fichier entre mon linux et ma DS ...)