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)

Touche finale sur les pentes

Totalement par hasard, alors que je m'installe un petit "cubicle" de 8m³ à la maison pour y poser mon portable, je retrouve ce tutoriel de Florian Hufsky sur les pentes (le site original a disparu). Je lui chippe donc une de ses illustrations pour vous parler d'une des petites choses qui me restent encore à régler par rapport à la gestion des pentes dans Bilou. L'algorithme doslopes permet de suivre une pente, mais les états "standing" et "falling" ignorent encore presque complètement l'existence des pentes, ce qui donne des effets parfois curieux.

It looks like i've sketched the UI for monsters placement on a lost print-out of Florian Hufsky's tutorial on slopes. I'll then reuse one of his pictures to illustrate a last problem I need to take care of : landing on a slope. So far, the GravityController has not been modified to be aware of slopes (only WalkingController follow slopes with the doslope algorithm), but when the update will come, I know I'll have to ensure I prevent sprites from digging in the slope without making the slope "magnetic" to the point it attract sprites on the ground as soon as they enter the tile.

Il faut être prudent dans ce genre de situation, à éviter de positionner trop tôt le personnage à son emplacement d'arrêt sur la pente s'il n'y est pas encore arrivé. Sans ça, les pentes vont avoir un effet "magnétique" plutôt désagréable qui donne l'impression d'un moteur de jeu amateur.

Bon, ça ne peut pas être pire que le RSD game maker de mon adolescence qui ignorait purement et simplement l'existence des pentes. Le seul moyen de les simuler consistait à mettre un tile en gravité négative ... une approximation pour le moins bancale puisque le personnage se mettait à "osciller" autour de la position souhaitée :P

Il y a Janvier, et Janvier.

Nous voilà en 2010. L'an MMX. Bonne année et meilleurs voeux à tous.

• Janvier 2000, et sa lettre de voeux à Gedeon datée de 1900, clin d'oeil au bug de l'an 2000 ...
• Janvier 2001, et une petite tentative d'imaginer Bilou sur GBA pendant que je prépare l'exam oral de réseau.
• Janvier 2002 ... en pleine lecture d'Hyperion, tranquille chez mes parents (?)
  
• Janvier 2003, à l'appart, de retour de Zurich, j'explore les possibilités de mon Sharp Zaurus, malheureusement terriblement pénible dans ses communications avec le PC.
  
• Janvier 2004, toujours à l'appart, mais cette fois-ci de retour de Kyoto. Où on ne m'a même pas emmené voir les locaux de Nintendo, tiens. Mais peu importe: je tiens le sujet de ma thèse de doctorat ! Et une fois encore, c'est un processeur ARM qui équippe les IXP2400 que je commence à étudier.
• Janvier 2005, plein feux sur Clicker32 dont la release 0.9.0 contient un petit Bilou en guise de curseur souris ... qui fait un gros effet sur la communauté osdev... un rouage s'enclenche, il y a de plus en plus de "BangBash" dans les codes hexa de mon débugging...
  
• Janvier 2006, ma première "planche de BD électronique" à partir de mon carnet de croquis met en scène le crayon jovial et la gomme endormie. Depuis, le mini-récit complet est disponible dans le "Bilou's Book". Et je viens d'avoir ma DS (je crois).
  
• Janvier 2007, prêt à déménager. premier "mockup" un peu complet (les étagères de la School Zone) prend forme par copier-coller depuis SEDS tournant dans desmume. Heureusement, depuis, j'ai un outil de conversion automatisé et l'export des fichiers .spr par runme... Et LEDS pour construire directement le niveau sur la DS.
• C'est en janvier 2008, justement, que je commence sérieusement le travail sur LEDS, mon éditeur de niveau... Entre Zelda: Phantom Hourglass, la lecture de la trilogie des joyaux (Eddings & Eddings) et un re-cablage de mon ancien C64.
• Janvier 2009, à Bâle, entre Johnny Biscuit et Giana sur DS, je me re-cible sur Bilou, mettant au garage mes "projets" de portage de Biokid et autre Seafox sur la DS. Et pour contrer le manque de connexion internet, runme peut passer la main au programme .nds qu'il vient de récupérer par "Wifi local".

Happy new Year MMX everyone. As you have noticed, I tell above the story of those previous January 200* ... A new technique for slopes in 2000, investigating the Gameboy Advance in 2001. I've already detailed this to you.
2002-2005 are more "mysterious" years because I was fully focusing (that is, programming-wise) on Clicker32, my operating system. Yet gadgets (the Sharp Zaurus) and thesis project made me slowly prepared to face cross-compiling and ARM-based embedded systems so that when I buy the Nintendo DS for Christmas 2005 I know I'll be able to program it as soon as I'll get a linker.
January 2006 see the first releases of the "Bilou, Bouli, the Crayon and the SharpenHer" on my former blog. This marks a new start of a new hobby-era that I'm still presently in. January 2007 seen the first "fake level screenshot" with tiles drawn in SEDS, since work on the level editor only started on January 2008 t... and you certainly remember of January 2009, when I was in Basel, deciding that "whatever the game, I stick with Bilou ..."

Edition des monstres ...

Petit moment sympa pendant le congé de Noël : j'essaie d'imaginer la manipulation des monstres sur la map dans le Level Editor... En général dans ces cas-là, j'essaie de me servir au maximum des contrôles de la DS pour garder le maximum de l'écran pour la "zone de travail" (en l'occurence la map).

Somewhere between shovelling of the driveway and wrapping up of gifts, I sketched up a possible user interaction for monster edition mode in my level editor ... I thought you might find it funny to see. My aim was to keep mostly the screen clear of buttons, and use the natural control (that is DS buttons and DPAD) to keep the touch screen purely as a "workbench" to select and move monsters.

This completes a former document that was more of an overview of the monster management process.

Dans le même genre,mais un poil plus ancien, une réfléxion plus complète sur "comment savoir quel monstre mettre où", etc.

sgIP_TCP: either buggy or awkward

L'implémentation de TCP sur DS me surprend un peu, et pourrait bien expliquer les "fuites de données" observées pendant les transfers DS->PC. Ou les "deadlocks" qui se produisent en cours de transmission". Sur la sellette, la gestion des ACK, ces signaux qui indiquent qu'un paquet a bien été reçu.
I've never seen a TCP implementation behaving like dswifi, and chances are that it might explain the "data losses" and deadlocks I'm experiencing with runme uploads recently. I've compared my version (2005-2006) against the latest version in devkitpro and did not noticed significant changes in the TCP protocol handling.
What looks odd is the management of ACKnowledgements, those little packets that just tell the sender that "okay, i've got your data, go ahead". First, the DS seems to acknowledge everything, including ACKs from the PC. Moreover, it doesn't look to take all ACKs into account when sending a packet, but only the oldest one ...

• d'abord, la DS émet un ACK même pour un paquet qui ne contenait aucune donnée (un ACK du PC, par exemple)
• ensuite, elle ne semble pas tenir compte du dernier ACK reçu au moment de renvoyer des données, si bien que la DS réémet des données que le PC a déjà acquittées.
  

Mon analyse est encore un peu imparfaite (la DS a-t-elle ou non reçu les ACK du PC ? difficile à dire)
En regardant les lignes 4060 et 4061 de la capture, il est évident que la DS a reçu un ack du PC, puisque le n° de séquence évolue pour la 1ere fois depuis la ligne 4050, mais alors que le PC vient de valider tous les bytes jusqu'à 101796 (compris), la DS retransmet tout de même à partir de 100633 (ç.a.d. seulement 256 bytes plus loin que le packet précédent).

Je travaille toujours avec la version 2005-2006 de la bibliothèque dswifi de Stephen Stair. Je devrais sans doute tenter une mise à jour.

edit: the third pass on my own code revealed a subtle error on how I handled "EWOULDBLOCK" when uploading from a file. sgIP_TCP thus did not lose any data and is just a bit awkward. Sgstair himself took the time to point me out that there are much more levels of queueing in the DS networking stack (including hardware buffers), which sheds another light on the problem ... I think I can live with small performance issues. But I'll keep on investigating the issue anyway.

FileWidgets

Let's welcome FileWidgets.cpp in libgeds and appropriate DirShow + TypeWord widgets on the beam-file-out-of-DS page of runme. Snapshot will come out later : it's past my bed time, already.

Bin voilà. Finalement j'ai pu transférer les FileWidgets depuis le LevelEditor dans libgeds, ce qui m'a permi du coup de les utiliser dans runme pour le choix du fichier à exporter. Mais là, je vais aller dormir :P

runme feature request

Le problème d'un petit outil bricolé à la demande, c'est justement que les fonctionnalités sont bricolées à la demande. Ainsi, runme est devenu assez fort pour recevoir des fichiers depuis le PC par wifi, à condition de préférer une connexion rapide à un nom de plus de 8 lettres ...
Pour ce qui est d'émettre des fichiers, par contre, je suis à la traine. C'était un ajout destiné à permettre le backup des fichiers créés par mon Sprite Editor, avec donc 4 boutons "A-B-X-Y" correspondant aux quatre fichiers de travail spriteA...spriteY eux-même liés au fait que pour sauver son travail dans SEDS, on fait START-R-[ABYX] pour choisir le fichier à écraser ou START-R-R pour "sauver le fichier en cours". Idem START-L-[ABYX] re-charge un fichier. Pas de boite de dialogue, donc. Du code assez simple pour une fonctionalité assez simple, parce que de toutes façons je n'avais pas besoin de plus (et je n'ai toujours pas eu besoin de plus jusqu'ici).

Runme's upload features (that is, DS-to-PC transfers) are still fairly limited, and become a boulder in the path of coding. All it offers is to pick one of the 4 spritesheets edited with SEDS, and that's all. How about the map i've just edited ? how about Bilou and foes state machines? how about any other file on my .nds i'd love to beam back on rotating magnets (that is, HDDs :P) ?
It's somehow getting a priority. I'm not hot about integrating those Directory-selection widget of LEDS into rumne, but I guess it's no longer an option. I hoped the PC-side could tell us the name of the file to pick, but it also look like the objects of my code are oriented in another direction. OOPs >_<.
Mais depuis, j'ai aussi un éditeur de map et si les fichiers .cmd qui définissent les niveaux sont toujours rédigés à la main sur PC, ils ne sont pas forcément sur ce PC. Bref, il me faut plus de souplesse dans le choix du fichier. Quelque-chose du genre du choix de fichier dans LEDS. J'avais pensé contourner le problème en sélectionnant le fichier à partir d'infos envoyées par le PC par Wifi, mais malheureusement, l'organisation POO du code s'y oppose.

Je pourrais aussi repécher les derniers fichiers ouverts lors du parsing des scripts, tiens.

Affaire à suivre, parce que du coup, le temps imparti est écoulé. Et je n'aurai pas pu aller bricoler Bilou pour qu'il saute moins haut quand on relâche le bouton...