couldn't list the directory.

For some reason, recent desmume (0.9.11) shipped with my Ubuntu distro cannot list files in directories passed as --cflash-path.
and this time, my 'old version' of desmume binaries are 32-bit while the system is running a 64-bit OS. I had multiarch-support package installed, but not libc6:i386, nor libstdc++6:i386, and as a result, and I just had a weird message about the 'file not being found', while it was obviously there. Once those core packages had been installed, I got more coder-friendly error messages mentioning which library was missing, so I could just find the corresponding package with apt-file and install e.g. libsdl1.2debian:i386, libglib2.0-0:i386 and the like.

And eventually, I could run a copy of desmume-cli so old that --version isn't even supported :P 0.9.6 svnr3873 dev+, it says. And that one granted me with proper file loading, so I'll be able to investigate whether my edits on the extended monsters editions are OK or not ... next time.

(and no, this time adding --load-type=1 did not help)
(bug confirmed with filesystem/libfat/libfatdir example from devkitpro)

Iconoclasts

I could hardly point you to the old "wish-to-play-that-game" blog post about Konjak's "Iconoclast" game, because I've been post-poning writing that post since 2011, hence the "#veryOldDraft" tag. 

From the very first notice on the tigsource blog, I've been in love with the pixel art used. I loved the gameplay as well, which I managed to get running through Wine on my old laptop ... but It wasn't comfortable to go much further than the first true boss.

But yesterday, I just noticed it was available on the Nintendo Switch, so this is my second indie download, and it's a marvel to experience the game at full frame rate with responsive and friendly controls. Plus, the switch has a "snapshot" button, and a separate galery mode, meaning that I'll be able to do pixel studies when I'm not playing it.

Bon, il y a 8 ans que j'aurais dû commencer cet article, parce qu'il y a 8 ans que Iconoclast de Konjak m'avait tapé dans l'oeil. Il y a même 8 ans presque que j'y ai joué pour la première fois, dans le salon de mes beaux-parents sur un portable Linux tournant laborieusement Wine. J'avais apprécié, mais l'expérience n'avais rien de comparable à avoir la chose au milieu de son D-PAD et calibré pour tourner à pleine puissance sur la Nintendo Switch. Je ne regrette pas l'attente et je ne regrette pas la dépense (vu que la version PC avait été gratuite :P)

La bande son est de toute bonne qualité aussi (sans pousser jusqu'au niveau d'un Shantae ou d'un Fez quand même), et je suis assez surpris de constater qu'elle est signée également Konjak! "Pixel" avait fait de même dans "Cave Story", mais ça reste suffisament rare pour le mentionner.

Bon, je vais quand-même faire une petite intro du jeu pour ceux qui le découvriraient ici: Robine est une jeu passionnée de mécanique. Elle n'hésite pas à donner un coup de clé à gauche ou à droite pour dépanner les gens de sa colonie. Elle se débrouille aussi assez bien avec un flingue, et ça va lui venir bien à point, parce que dans son monde, le carburant est considéré comme une manne divine et seuls les prêtres assermentés peuvent intervenir sur les équippements alimentés en carburant sans être pourchassés par les agents du Projet et "jugés" pour hérésie.

Je pourrais être tenté de dire qu'on est face à un métroïdvania, vu qu'on se déplace librement dans des niveaux un poil labyrinthique, qu'on débloque des mises à jour de ses armes pour continuer à progresser dans le jeu et qu'on dégomme tout ce qui bouge sauf si ça nous adresse la parole avant de nous charger. Mais ce serait une insulte de ne pas préciser la présence d'une forte composante RPG, étant donné la quantité de PNJ qui nous distillent leur connaissance du monde, de ses intrigues et des relations curieuses entre les différentes factions. De nouveau, c'est de Cave Story qu'on se rapproche le plus ici.

Encore que Konjak a veillé à choisir des mécaniques de combat qui permettent aussi des phases de puzzle entre les séquence de combat pur -- chose qui colle tout à fait au caractère du personnage, ce qui ne gâche rien.

touchInit()

J'espère que ce sera la dernière surprise dans la branche "mise à jour de mon kit de développement DS"... Après avoir enfin réussi à avoir des programmes qui tournent à nouveau sur la DS (et dans l'émulateur, au passage), je finis par me rendre compte que plus aucun de mes widgets ne fonctionne. Au point que j'en viens à soupçonnner quelque-chose dans le code qui relaie les mesures depuis le composant SPI en charge de l'écran tactile à travers le processeur ARM7 pour être exploité sur le processeur ARM9. D'autant que tous mes programmes utilisent un code ARM7 "custom", chose qui ne sera forcément pas testée lors des mises à jour de libnds, devkitARM et leurs sbires.

Mais mon code ARM7 voit toujours bien son gestionnaire d'interruption appelé, recompiler un des programmes d'exemple avec mon code ARM7 au lieu de la version officielle marche toujours ... Ou en tout cas, c'est l'impression que ça donne au premier regard. En débugguant de plus près, je constate que mon code sur l'ARM9 reçoit bien des 'touchPosition' en bout de chaine, mais chose curieuse, deux paramètres (px et py) sont toujours nuls. Il s'agit des valeurs traduites en pixels, à l'aide des paramètres de calibrage. Et le programme d'exemple fait pareil: il ne nous donne que les valeurs "brutes".

En réalité, il faut maintenant appeler une fonction "touchInit" pour appliquer les données de calibrage, et la version du devkitpro que j'avais installée avait fait la mise à jour correspondante dans le "code ARM7 par défaut", mais pas encore dans les programmes d'exemple utilisant du code ARM7 custom ... On va finir par y arriver.