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

Ready ? Set ... Go !

Pour un vieux de la vieille comme moi, ce genre d'image a quelque-chose de totalement surréaliste ! Sonic sur la nintendo DS ou la GBA, on en était déjà tout paf, mais bon, on a fini par s'en remettre. Un combat à mort entre Kirby et la princesse Zelda, on est surpris un instant, mais quand on a réalisé qu'il s'agissait juste d'une grande rencontre entre tous les personnages de Nintendo, bon, pas de quoi s'affoler.

Mais ici, on touche au délire qualifié d'irréalisable il y a 15 ans par nos parents: un décathlon où Mario et Sonic peuvent s'affronter (et comme ils ont tous eu pleins de potes depuis, Daisy vs. Knuckles ou Bowser vs. Dr. Eggman est aussi envisageable ^_^)

Tout ça sur la Wii, comme nous l'annonce Edgar de "4 colors Rebelion". Donc, on pourra même se faire un 400m sans démolir nos paddle comme du temps de Summer Games Challenge sur C64.

Je jette l'éponge.

Un peu de rangements dans le living, ce week-end. Je suis retombé sur deux petits croquis préliminaires de "Bop L'éponge" qui doivent dater plus ou moins du déménagement. Du coup, je les ai rajouté au post initial du 21 février. L'occasion de se faire une rétrospective de la section level(/game/monster) design ?

Ce qui est sûr, c'est que ce sera plus fun que le coup des messages d'horreur ou du débugging de mikmod :P

was busy tidying up the living-room this last week-end (new fairy's desktop is here, shelves had to move to give it more room. And while moving stacks of sheets, i located a couple of preliminary drawings for "sponge bop". I'd say they're likely to date back from march when i was moving in our new house.

Well, anyway, i just added them to the 21th february's last post. Maybe it could be a good reason for reviewing the "level/game/monster design" section of the blog ? Well, i guess it will be funnier than those last post about C++ Horror Messages or deep-debugging of the libmikmod.

libmikmod deep test

I turned down the volume of my PC yesterday and let the DS be the music center, using a couple of updates on my "file server" (mostly truncating filenames and ungzipping on the fly submitted files). That was a fun time, but it revealed several oddities in the playback, so i have decided to delve deeper in the mikmod player library this lunch time to see whether i could improve playback.

The whole story is atm. only detailed in french, but to put it shortly, i mnaged to play a couple of .IT files from my brother thanks to a small patch (skip rendering in the first few ticks). I wish i could have opted for hardware playback, too, but this one seems completely buggy atm (understand: it completely locks down the system :P)


Hier, j'ai baissé le son de mon PC: c'est la DS qui a pris le relai, moyennant deux ou trois petits ajouts au programme servant de "serveur" côté PC (notamment, décompression à la volée et troncage approprié des noms de fichiers).

C'était sympa, mais le player a méchamment tendance à bugger, notamment au démarrage. J'ai essayé d'y voir un peu plus clair dans le code de mikmod (cf le post plus long). Il y a pas mal de positifs (j'arrive à jouer "Prehis2.it" de mon frère, par exemple ou la "pipe zone"), mais je crains que le player software ne devienne vite trop gourmand. Et le player hardware ? bin il crashe tout. oui, ma bonne dame.



note that while the job of hardware driver's update is straightforward, the software driver will actually try to fill the playout buffer at each step.



Software Mixing

Bon, le mixage hardware plante tout. comme ça au moins, c'est réglé. Dommage: le mixage software va être beaucoup plus tordu. Ici, le fonctionnement du mixeur est guidé par le playout buffer, une zone de mémoire dans lequel notre processeur principal construit un "wav" que le processeur secondaire (ARM7 et les circuits de la DS) transmettent vers nos oreilles.

Tout ce joue à l'aide de deux indicateurs de position (les "curseurs" dixit la bibliothèque mikmod) qui repère où en est l'écriture et où en est la lecture dans ce qu'il est commun d'appeler un buffer circulaire. Notre driver software va donc, à chaque appel de sa méthode Update(), calculer le nombre de bytes libres dans ce buffer et faire appel au virtual channel qui est chargé d'avancer dans le pattern et de produire des bytes.

#if 0
if (isfirst) {
isfirst--;
return;
}
#endif

il y avait dans Player_HandleTick() ce curieux bout de code avec comme commentaire "don't handle the very first ticks, this allows the other hardware to
settle down so we don't loose any starting notes". En clair, le "#if 0" désactive le bloc en question, qui avait pour effet de ne pas générer de données sur les "isfirst" premiers appels à HandleTick(). Comme quasiment tous mes mods démarraient de travers, je l'ai simplement réactivé, et je ne suis pas mécontent du résultat.


Mikmod_Update()

while(1) {
ge.handle();
MikMod_Update();
ge.animate();
}

Bion. Donc chaque appel à MikMod_Update(), pour la version "software mixing", le player va estimer combien de bytes du buffer ont déjà été joués et les remplacera par des nouveaux. Reste à quelle fréquence on va appeler cette fonction (plus elle sera appelée souvent, plus son temps d'exécution sera court, du coup).
La méthode la plus directe (et utilisée dans Tetris Attack) consiste à la placer après le traitement d'une nouvelle image.

Dans cette approche, le programme va alterner les tâches suivantes:

1. lire l'état des boutons, de l'écran tactile, etc. et réagir en conséquence
2. attendre le prochain rafraichissement (d'écran, hein. pas un soda-glacé)
3. remettre à jour les tables de sprites (non, c'est pas non plus un rafraichissement. m'enfin)
4. appeler mikmod_update pour produire plus de son dans le buffer
5. traiter les animations

A première vue, c'est sous-optimal: on voudrait avoir le rendu du son comme tâche de fond, p.ex. pendant que l'on attend le rafraichissement d'écran (tant qu'à attendre, ...)