libFAT : hide and fseek ...

Well, initially I thought that the performance issue of TCP transfers would be worth another investigation-novel-styled post, but being somewhere between Christmas and New Year's Eve didn't allowed me to do so. Or maybe just digesting the source code of libfat, figuring out what kind of access pattern made it so slow and what more subtle access pattern was making my new cache policy go wrong was already demanding enough.

The patch is not ready for inclusion in libfat according to devkitpro's standards. Yet, having a look at it is the only way for you to have an idea of what can be changed to fix the performance issue.

The core idea of this patch is to allow pages in the cache to reflect only partially what is (should be) on disk. The new readable field gives the position in the page where we leave 'valid' data and enter uncharted, here-be-dragons, area which content shouldn't be relied upon. I proceeded with additional extensive checks (64M movies transfers, md5 checksum verification and fsck on the media card) and fixed one last bug affecting end of files. The patch released on Tuesday is thus invalidated.

Remember, kids: FAT is the worst filesystem ever.

Oh, and btw, server.pl, the PC-side data source for a PC-to-DS wifi transfer can now be invoked so that it will cycle within a list of files, allowing one to efficitently transfer the files one after the other, e.g. :

server.pl neoflash/*.nds [DS_IP_ADDR [PC_IP_ADDR]]

libFAT cache-cache

Après avoir instrumenté un brin le gestionnaire de cache de la libFAT, j'ai droit à une belle série de statistiques qui montrent que pour réécrire ~400K sur ma carte mémoire, il me faut au préalable lire à peu près autant (968 secteurs) ... En fait, puisque j'écris chaque paquet (~550 bytes) au fur et à mesure dans le fichier, et puisque le cache travaille par "page" de 4K, toutes les écritures sont partielles et le cache lit d'abord le contenu du disque avant de commencer à écrire la bonne valeur). Le hic, c'est bien sûr que dans mon cas, les anciennes données ne seront jamais utiles, puisque je les écraserai toutes :-P

J'essaie donc de modifier "cache.c" pour forcer une politique de "lecture paresseuse" où l'on ne remplirait une entrée du cache avec le contenu du disque que si une tentative de lecture a lieu. Il est donc possible de "préparer" progressivement un contenu à écrire et ne l'écrire qu'une fois complété. Bon, maintenant, il va falloir débugguer ça. A moi desmume, ddd et strace ...

Tout semble fonctionner sur émulateur, mais sur la DS "Phat" de ma fée, j'ai juste droit à un "FATinit failed" ... qui s'avère être dû à un petit problème de DLDI sur SuperCard SD. Après quelques hexdump et diff supplémentaires, je peux enfin vous proposer ma libfat revue et corrigée, jusqu'à 3 fois plus rapide sur les écritures de fichier.

PS: il restait un bug, donc voyez le post du 31 pour la version définitive.

Speed Limit: 32

Now, that's fairly annoying. It looks like the TCP WiFi transfers with the "devkitpro r32" is roughly 3 times slowlier than its r21 counterpart (in purple) for the same receiving code. That's especially annoying since it significantly increase the duration of a self-upgrade cycle during development.

The new performance (in black, as reported by wireshark) is impaired by regular "waits" of ~200ms before the PC retransmits some data. And I'm doing the test with a local server here. A larger RTT would likely reduce the performance even more. Retransmissions happen form the start, and that's fairly normal for a wireless transmission. I ran some early code comparison between the ARM9 TCP code of the two dswifi versions, but I couldn't spot any major change that could explain this behaviour.

J'ai finalement suffisament rafistolé runMe pour qu'il puisse de nouveau faire sa mise à jour automatique -- la clé de voûte de mon cycle de développement sur DS. Je pouvais déjà jouer à redémarrer sous Moonshell, puis passer dans le menu R4, utiliser le vieux runMe "21" pour télécharger le nouveau tryMe "32", retourner à Moonshell puis au menu R4 pour démarrer le programme tryMe. Pas extraordinaire. Problème: les transfers par WiFi sont devenus nettement plus lents. Jusqu'à 3x plus lents si j'en crois mes captures wireshark (ci dessus, runme-21 en mauve, runme-32 en noir).

Pourtant, à en croire le code de TCP dans libdswifi9, rien n'a changé ... ou presque. Rien en tout cas qui puisse expliquer ces pauses de 200ms récurrentes dans le deuxième scénario. J'investigue un peu plus grâce au zoom infini de WireShark pour découvrir que la DS annonce juste avant cette pause une fenêtre de réception de plus en plus petite, qui finit par atteindre une taille nulle. Et ça, en langage TCP, c'est le signe que le récepteur ne suit plus: les buffers saturent.

One intriguing thing is that, somewhat prior one of these long wait is that the receiver's window size is reduced from 1400 bytes to 1127, then 591 and finally 55 bytes ... It will then remain with a 0 receiver window for a few packets and then move back to 1400. In TCP language, this is an indication that the receiver struggles to process the received data on time. But the code that invokes "recv()" hasn't changed either ... that sounds like a problem coming from the "write-to-filesystem" side of the program ... from the libFAT.

It looks like libFAT has received more substantial changes, especially regarding the cache management. I used runMe's "receive to memory" mode, which is limitted in file size, but still operated at the usual peak speed. If a sequence number graph doesn't talk to you, the performance monitor just on the right should. The first "bridge" bar is the transfer to disk, the second "tower" bar is the transfer to memory. I haven't figured how to fix that yet, but at least I am in position to say that TCP is clear of charges.

Puisque le code qui transfère les données de dswifi à libfat n'a pas changé d'un iota, le problème est plus que probablement dans la libfat, qui a subi des modifications relativement importantes -- notamment au niveau de la gestion de son cache. Et vu que les données arrivent par le réseau à une taille qui n'est pas la taille "naturelle" pour écrire sur disque, un petit défaut dans la libFAT pourrait facilement avoir un effet conséquent sur les performances. Dernier petit test pour me convaincre de continuer dans cette direction : un transfer Wifi en mémoire (et non pas vers un fichier), fonctionalité un peu désuète de runMe mais qui tombe à pic ici. Résultat sans appel: on retrouve la vitesse à laquelle runMe m'avait habitué.

C'est donc un dswifi blanchi qui quitte la garde à vue tandis que je m'apprète à jouer une âpre partie de cache-cache avec le gros lard louche connu sous le nom de libFAT.

* Merry Christmas *

Joyeux Noël. je vous invite à prendre livraison des sources du jeu de l'année 2010 : Apple Assault.

Merry Christmas, everyone. I managed to clean up and comment the source code for Apple Assault, which you're now welcome to download. See you in 2011 ^_^

* Merry Christmas *

Pendant que Bilou et Bouli se font une bataille de boules de neige, je vous invite à prendre livraison des sources du jeu de l'année 2010 : Apple Assault.

Merry Christmas, everyone. Bilou and Bouli are currently having a relaxing snowball battle on planet 2412.0 ... Meanwhile, I managed to clean up and comment the source code for Apple Assault, which you're now welcome to download. See you in 2011 ^_^

PS: les p'tits graphismes de Bilou et Bouli viennent d'un vieux PCX datant de ... hooouuuu ... 1999 ? Je voulais faire un Worms avec des boules de neige ;)

So long, exec.cpp

Since August 2007 the exec.cpp file from GrizzlyAdams has been a corner stone of my activities on the Nintendo DS. It allowed me to launch NDS files from other NDS files -- a functionality that was missing of the "standard" features of libnds by then. Combined with dswifi and a small HTTP retriever, it allowed me to introduce a "self-update" feature that replaced the media card mounting/unmounting that was previously taking most of my development time. Since I mostly work on my DS project on lunch time or in the evening, it had a major impact on my ability to keep going on.
En août 2007, mes projets sur DS ont pris un grand tournant avec l'ajout d'un morceau de code de DsChannel de GrizzlyAdams, qui permettait d'enchaîner un NDS vers un autre. Combiné à un petit code HTTP, je devenais capable d'écrire des programmes se mettant à jour eux-même. Et il n'y a pas à dire, celà a nettement boosté le travail sur le Sprite Editor, le Level Editor, la lecture de modules et plus tard, le moteur de jeu à la base d'Apple Assault ...

But here we are, 3 years later, at devkitArm revision 32, with all the libraries changed. The handling of FIFO code, among other things, received a major revision, that breaks the compatibility with the custom loader. Meanwhile, too, Wintermute included a similar feature in HBMenu and made several part of the libnds dependent of its own approach. Reseting the ARM7 on request from the ARM9, for instance, is directly located in fifosystem.c, and a C++ exception will try to return to the launcher of a program. Rather than fighting against this, I decided to try and see to what extent the bare bones of "HBmenu" can be converted to support runME.

Mais voilà. Ce code utilisait le FIFO -- pratiquement inutilisé du temps du devkitArm 21 -- qui entretemps a subit une refonte importante, et Wintermute et ses accolytes ont cherché à intégrer une fonction similaire dans la libnds. L'astuce, en fait, c'est que la fonction n'est pas directement offerte aux programmes, mais intégrée dans HBmenu, qui laisse une partie de son code à un emplacement "persistant" qui (si je comprends bien) est uniquement capable de revenir au programme qui a installé ce programme persistant. Plutôt que de me battre à essayer de faire cohabiter le code de GrizzlyAdams dans le nouvel environnement, j'ai donc repris la base de HBMenu pour reconstruire runMe par-dessus. Ca marche plutôt bien, dirait-on, même si je n'ai pas encore fini le portage ... mais curieusement, ça me fait un peu chose de laisser tomber cet "exec.cpp" qui m'a soutenu tout ce temps ...

The result is encouraging, although I've got a small tear in my eye for that piece of software that I analysed and debugged to make it fully support DLDI ... Although the code from the devkitpro project shares many similarities with "my" previous approach, a larger part of the stub executes from the ARM7 (as far as I understood), meaning that it's not possible to perform debugging for it. The new code consists of

• nds_loader_arm9.c, acting as a library and directly linked to your program (runme or HBMenu), that mainly ensure software reset of the two processors and DLDI patching of the loader
• bootstub.bin, installed from the end of the ARM9 memory (the upper 48K of the 4MB area) by installBootStub() function in the "library" file
• loader.bin, copied in VRAM by runNdsFile(). It contains its own (stripped-down) FAT access, the DLDI patcher.

PS: loader.bin and bootstub.bin are thus by-products of HBMenu compilation. To get them, you need to gather the latest sources from SVN, compile them (make all is enough provided that you have devkitpro installed with the appropriate libraries), and find them in the hbmenu/data directory.

Debugging sessions darker than night

Beyond Infinity, a fellow OS hobby developer back in 2002 used to twist Gandalf's quote into "I see debugging sessions coming, darker than night itself" ... I guess that could apply to the last week. After identifying the reason why DDD wasn't operating properly (not showing machine code) anymore and quickly applying a patch, I started investigating the internals of desmume's gdb stub ... the part of the emulator that allows one to perform source-level debugging as if it was a locally running program. With zeromus, we identified a couple of curious things in the emulator-debugger communication, and although we don't agree yet on how it should best be fixed, I managed to patch the emulator as well so that it behave the way I need.

J'aimais bien être développeur d'OS sur mega-tokyo. Une chose sympa avec les développeurs d'OS, c'est que comme on en prend tous pour 20 ans, on apprend à se connaître, à construire ensemble, etc. "Beyond Infinity" était l'un de ceux-là, geek de première dans sa manière de détourner les 'quotes' des grands films et livres. C'est à lui que je dois le parallèle entre les "jours plus sombres que la nuit elle-même" du Seigneur des Anneaux et ces scéances obscures de debugging ou plus rien ne semble marcher comme il se doit au point qu'on finit par débugguer la machine virtuelle et/ou le débuggueur lui-même.

D'une certaine manière, voilà qui colle parfaitement à mes activités homebrew de la semaine dernière ... Et après avoir surmonté des lignes de code sans nombre, triomphant de bugs inouïs, de haute lutte j'ai frayé mon chemin jusqu'au stub par-delà localhost:9999 pour reprendre la condition de course qui s'était infiltrée. Vouaip. Et du coup, je suis enfin en mesure de chercher pourquoi certains décors ne s'affichent pas dans Apple Assault sous "dkp-r32". Vous vous tenez bien les côtes ?

Bon, bin voilà: le comportement de fread() a changé. Il n'est désormais plus possible de transférer des données directement entre un fichier et la VRAM si la position dans le fichier n'est pas un multiple de 4. Quand on sait que la VRAM ne peut pas être adressée par bytes (mais uniquement par mot de 16 ou 32 bits) et qu'on a désassemblé quelques memcpy dans sa vie, on se dit "bon sang, mais c'est bien sûr" ... mais on a quand-même passé des heures dessus >_<

I am thus (at last) in position to think about why some of the background in AppleAssault don't show up anymore. It looks like something has changed either in newlib or in libfat that altered the way non-aligned memory transfers are handled by fread(). The problem is I regularly transfer tiles data straight from the file into the VRAM, but that the VRAM only support 16-bit or 32-bit wide writes. It is typical for a memcpy implementation to fall back to byte-per-byte copies as soon as a mis-alignment condition is detected, but in this case, it kills the whole transfer. I need to patch some pictures so that they have an even number of colours.


Là-dessus, maintenant que mon code est revenu à un état plus rassurant, il va falloir que je réattaque vaisselle et ménage ... Ma fée a beau avoir une patience d'ange, 'y'a des choses qui ne se font pas toutes seules.

cd /home/kitchen
make mrproper
/etc/init.d/dishwasher reload
cat /tmp/laundry > /dev/drier

It works ! I can't believe it !! ...

Wo, dudes. It sure has been an odd week at work, but it was even weirder after office hours when I tried to figure out what prevented Apple Assault to work... I wish I had actually typed "svn copy trunk branch/dkp-r32" before I started "fixing" the code for the new release of devkitarm.

After spending hours contemplating fifosystem.c and other hours digging into the source of DesMuME, I found no heroïc bug to fix, gained more confidence in the new tools and finally figured out that some of the assumptions I was working with (e.g. "thou shall call irqInit() before you invoke swiWaitForVBlank") were no longer true in the latest release ... and actually weren't true anymore for a while.

Migrating to the new libnds requires you to switch to the new everything ... including the latest desmume where the way to support "emulated filesystem" had changed. After I inserted a fake register whose content is dumped immediately on both ARM processors (I'm pretty sure there is similar features already, but it's faster to redo it than to locate it :P), I got capable of tracking the execution of the program ... Another modification enabled register dump after haltemu was called, which "explained" that the emulator shutdown was due to a new policy for handling not only exit(), but also abort() -- and C++ exceptions, which I had used in a tweaked way with the "devkitarm-21-based" setup I used so far.

The good news is that I now have Apple Assault running -- in a degraded mode, but running. And I have plenty of developer-friendly stuff added to my emulator to help me fix (hopefully) quickly the remaining things... It was about time : I nearly got discouraged yesterday.

Vous avez vu ? j'ai réussi à réavoir de l'Apple Assault qui s'affiche. C'est pas encore complètement rétabli, mais ça remarche de nouveau. Tout le reste, vous l'avez déjà lu dans les posts précédents :P

edit: I even managed to get sound running, although TrackSequences aren't working yet (missing the get-current-position ? no : curpos() do not rely on FIFO : it's just shared memory ... Or maybe I should ensure the oops[] array is accessed through un-cached addresses it looks to work fine the way it is, but it constantly compares against "pos == 0" ... ) That means the "trunk" is now definitely for "devkitpro-r32" (whatever it means) and that the devkitpro-r21 old things are archived once for all in tags/apple-assault-release.

SYSTEM POWERED OFF VIA ARM7 SPI POWER DEVICE

sauf erreur de ma part, je parviens maintenant à avoir le code de runme qui tourne sur desmume (version 0.9.6-SVN) quand il est compilé avec en mode "dkp-r32". Par contre, si j'essaie d'utiliser les même outils pour AppleAssault, j'ai droit à un magnifique "SYSTEM POWERED OFF VIA ARM7 SPI POWER DEVICE". Je soupçonne desmume de couper froidement toute communication avec GDB quand ça se produit, ce qui, du coup, m'empêche d'en chercher la cause >_<

IPC9@201564a send FIFO < 0x480A725C -- size 000 (l 0x8505, tail 00) (r 0x8501, tail 05)
-- IRQ delivering.
IPC7@37ff16a recv FIFO > 0x480A725C -- size 000 (l 0x8401, tail 05) (r 0x8504, tail 01)
IPC9@201564a send FIFO < 0x04010040 -- size 000 (l 0x8505, tail 01) (r 0x8501, tail 08)
-- IRQ delivering.
IPC7@37ff16a recv FIFO > 0x04010040 -- size 000 (l 0x8401, tail 08) (r 0x8504, tail 02)

Evidemment, la version "standard" de desmume (0.9.5, livrée par Ubuntu), elle, coince à l'initialisation du Wifi, et ça ne vaut donc même pas la peine de continuer à chercher. Je vais donc devoir aller ajouter l'équivalent-émulateur d'un gurumediation dans le code de emu_halt(), voire y ajouter un DEBUG_dumpMemory() ...

I think I can now get runMe running under desmume when it is compiled with my 'dkp-r32' install. If do try to use the same tools for AppleAssault, I end up with an error message suggesting ARM7 powered off sometihng. I bet the emulator doesn't try to talk to GDB any further when that occurs. Let's see if I manage to get more information by adding something helping guru meditation in emu_halt() ... and later a 'magic' fake register that allows me to track evolution.

After exploration, it turns out that something is calling `abort()` before my exception catch-and-report code could kick in. And abort() may shut power down. All this occurs because I forgot command line argument --gbaslot-rom to let DLDI code access files.

Après modification, et si j'en crois mon nouvel outil, c'est au niveau de libnds_exit.c que le processeur ARM9 s'est arrèté, juste après un appel à powerOn, qui aurait été appelé quelque part à partir de fifosystem.c (dans la fonction waitBlock, ce qui me paraît on ne peut plus louche ...) Le processeur ARM7, lui, s'est bloqué au niveau de writePowerManagement appelé depuis powerValueHandler. Ca, au moins, c'est cohérent. Le dernier message transmis de l'ARM9 vers l'ARM7 est (poétiquement) un 0x04010040, ce que je peux décoder en:

• 0xxx.xxxx : Channel 0 : power management
• x4xx.xxxx : Immediate value (type=4)
• xxx1.xxxx : PM_REQ_ON
• xxxx.0040 : PM_SYSTEM_PWR (?...)

Ma foi, ça me semble être tout à fait la situation découlant d'un appel à systemShutdown, dernière opération de __libnds_exit() lorsque le "retour à hbmenu" a échoué :P Bref, heureusement, je m'étais donné un "faux registre" 0x04042000 pour envoyer des mots de 32 bits hors de l'émulateur ... ce qui m'amène à la conclusion que mon interception des exceptions C++ s'est fait court-circuiter par un appel "abort()" qui a ordonné la fin du programme ... grr. ... et derrière tout ça, l'oubli de --gbaslot-rom, désormais indispensable pour EFS sous desmume >_<.

atof("3.14") == 0

J'avais donné le code suivant à mes étudiants:

int i = atoi(argv[2]); printf("[2] = '%s'\n",argv[2]);
float f = atof(argv[4]); printf("[4] = '%s'\n",argv[4]);
char* s = argv[6];

printf("%i %s %f = %f\n",i,s,f,f+(float)i);

Et l'un d'entre eux vient me trouver en disant que, chez lui, le code affiche toujours "42 plus 0.00000 = 42.0000" quelque soit la valeur donnée à l'argument '-f'. Je récupère le fichier je compile ... ah flûte: pas de devkit SDL sur la machine qui sert à projeter les transparents pendant les répèts. Hop, je commente "#include output.h" je compile je teste ...

Et là, bardaf. pas moyen d'avoir une valeur correcte... Un p'tit coup de manpage Warf. atof renvoie un double là où j'ai utilisé un float ... et printf("%f") suppose aussi la présence d'un double -- un nombre réel à haute précision, et prenant donc 2 fois plus de place ... vu que ça risque de poser des soucis (utilise une valeur tronquée, tout ça), je s/float/double/g tout ça je recompile et ... bin non. Toujours pas.

Tout ça accroupis dans l'auditoire. Je ne me démonte pas, je démare ddd ... qui persiste et signe.
Il aura fallu que je sois de retour sur ma devstation dans mon bureau, à l'aise, pour mettre le doigt sur le bug ... grâce à gcc -Wall, soit-dit en passant. Je vous laisse cogiter, puis passez voir la réponse dans les commentaires: c'est bête comme chou.

7 of 9 -- personal Log

27/11 : quelque soit le code ARM7 que j'utilise (le mien modifié, celui de Tobias ou le code DefaultARm7), runme ne passe pas le cap "sync with 7" sur l'ARM9 ...
28/11 : avec le code ARM7 de Tobias et le code ARM9 de l'exemple httpget.c, je parviens à avoir une transmission WiFi fonctionnelle. C'est donc (contre toute attente) le code ARM9 qui foire.
29/11 : la présence d'IrqInit() dans le code de GuiEngine::prepare() était clairement une des causes d'erreur, mais je ne sais pas encore dire si c'était la seule. Je vais devoir continuer à importer petit à petit les fonctionnalités de runme sur cette nouvelle base pour mettre le doigt sur les éléments perturbateurs.

Seven's log, stardate 201011.27 -- I am trapped in my ARM7 cortical implants. Although I could potentially still communicate with the WiFi collective -- if any was at short range -- I have lost connection with the ARM9 behaviour controller that would allow me to communicate with the crew of the Voyager. I have analysed the defect starfleet fifosystem.c that the Doctor installed to replace my damaged borg implants that is the root cause of my malfunction. The only tool I have to operate is a standard DESMuMe tricorder from the federation filled with irrelevant features, and that reaches only 67.3% of the efficience of a corresponding Borg nanoprobe.

Seven's log, supplemental -- A double initialisation of my interrupt mask might be the cause of this FIFO dysfunction. Deeper inspection of the starfleet FIFO protocol revealed a rigid structure with 16 virtual channels and imperfect typing of messages into one-word addresses, one-word value and external larger dataquads. I will resume my investigation when my refresh cycle is complete.


PS: curieux qu'avec le couple de processeurs ARM7 et ARM9, personne (que je connaisse) n'ai fait le rapprochement entre la DS de nintendo et le borg converti "Seven of Nine" de Star Trek : Voyager, vous ne trouvez pas ?

Note: j'aimerais bien également en savoir plus sur le support des fonctions FIFO dans desmume ... je note par exemple dans la fonction _MMU_ARM9_write32

case REG_IPCFIFOSEND :

  IPC_FIFOsend(ARMCPU_ARM9, val);

  return;

Mais aussi (dans le même fichier FIFO.cpp) des fonctions GFX_FIFOsend, apparemment utilisées par l'implémentation des fonctions 3d -- et qui n'a donc probablement rien à voir dans le cas qui m'intéresse.

PS: to the devkitpro and desmume teams : no offense intended. That's Seven's "personality". Watch season 4 of Star Trek Voyager if you haven't yet: you'll know what I mean.

PPS: here's a patch against svn revision 3601 of desmume that enhance debugging of FIFO by
1) enabling per-direction logging of writes to FIFO registers through the DESMUME_FIFOLOG environment variable
2) uses location 0x04042000 as REG_DEBUG : everytime you write some 32-bit word there, it will be dumped -- together with processor no and PC value -- on STDERR.
I don't think I have "fixed" anything, so it looks like r3601 of desmume-cli already supported the full FIFO features (even though generation of interrupts are a bit obscured and could use some more documentation), but it could certainly help people understanding or validating the fifosystem.c of libnds, or other ARM7 initialisation code.

#undef DSMI

La bonne nouvelle avec le passage au DKP-r32, c'est que du coup, j'ai les bonnes bibliothèques et outils pour compiler le projet NitroTracker d'0xtob ... et donc, que je suis potentiellement un peu plus proche d'un portage de mon support des effets de la libNTXM vers son projet d'origine ... On verra ça ;)

Il se pourrait bien, par contre, que les sources d'0xt0b soient autrement précieuses, puisque mon code ARM7 custom a du mal à passer à la vitesse supérieure, alors que le code d'0xt0b, lui, est déjà prêt à l'emploi. Finalement, il me resterait "juste" à lui ajouter le support de l'exécution d'un autre .nds pour revenir sur les bases nécessaires pour mes outils...

the good thing with the switch to "release 32" of the devkitpro is that I'm now able to compile the Nitro Tracker project -- the one where theNTXM sound library I use originates from. That brings me one step closer to backporting of my own NTXM extension to its seminate project, but also, it means that recycling the ARM7 code of 0xt0b could be more efficient than trying to upgrade my own custom ARM7 code, since Tobias has included support for the WiFi as well.

source setup-r32

Bion, un package sources pour Apple Assault, c'est sympa, mais si le code pouvait être compilé avec les versions en date du devkitpro, ça ne serait pas plus mal, hein ? Il faut dire que j'étais resté à la version r21 qui doit dater d'octobre 2007 et sur laquelle j'ai pas mal bricolé entretemps.

I guess it'll make more sense to do a source release if you're able to compile Apple Assault from the source, right ? That's where you'll need devkitpro, the open-source cross-compiling and core-libraries project for homebrew console development ... as it was back in October 2007. Sticking to a working -- but obsolete -- development kit helped me during 3 years to stay focus and work on my tools rather than doing pointless bugfixes, but now it's time to move on. I fear it won't be an easy task, though, as I use a custom ARM7 and so on ... Hopefully, again, the ease of branching with subversion should help a lot.

• gcc 4.5.1 râle sur char * x = "hello" et insiste pour qu'on ait const char* x = "hello", histoire que la chaîne (normalement considérée comme une constante) ne puisse pas être altérée par le programme. Dans l'absolu il a raison et c'est facile (mais chaint) à corriger... d'autant (C++ oblige) que le code de la bibliothèque doit lui aussi être recompilé pour bénéficier de l'update :P
  
• IPC n'existe plus ou a été modifié. Je m'en servais pour gérer la mise en veille de la console ... 'faudra trouver autre chose. Plus gênant, mon code custom pour le côté ARM7 devra sans doute être mis à jour lui aussi, et de manière substancielle.
  
• SUB_DISPLAY_CR a été renommé, de même que BGx_CR, BGx_X0 et leur variantes SUB_xxx (pour assurer la cohérence avec GBAtek, ce qui n'est pas plus mal, soit dit en passant). Pas vraiment gênant pour l'exécutable lui-même, mais ça va être pénible pour la mise à jour de mes bibliothèques

Bien sûr, mélanger les libgeds.a ou libpppnds.a de devkitpro r21 avec AppleAssault.o compilé pour devkitpro r32 (libnds 1.4.8, libfat 1.0.7, dswifi 0.3.13) serait voué à l'échec. C'est donc l'ensemble du projet qui a besoin d'être migré >_<

L'alternative, c'est de fourguer libnds, libfat et dswifi précompilé dans le "package sources", mais ça me tente tout de suite moins :P

PS: "source setup-r32" parce que j'ai pris l'habitude d'avoir un script shell nommé "setup" à la racine de chaque projet qui configure toutes les variables d'environnements (CLASSPATH, LD_LIBRARY_PATH, CFLAGS, voire même PATH pour utiliser des cross-compilers) ce qui me permet d'utiliser la commande shell source pour "activer le mode OMNet++" ou "activer le mode devkitpro". En l'occurence, pour devkitpro, j'ai un setup-rxx selon que je veux utiliser la release 19, 20, 21 ... ou maintenant 32.

Last Minute Panic...

Mouais. Pas si finale que ça, finalement, la version 1.4 d'Apple Assault. En tout cas, elle mériterait bien un bugfix. Un conseil si vous devez faire une pause, fermez la console un niveau, pas entre deux niveaux. Disons que le suivi d'un pattern pour déclencher des actions sur certaines lignes n'aime pas trop qu'on laisse le pattern tourner sur l'ARM7 pendant que l'ARM9 est mis en veille.

It looks like the final release of Apple Assault might need some more tweaking, finally. Anyway, if you need a break during the game, close the lid within a level and not between two levels... You've been warned. Well, let's say the TrackSequence that follows an XM pattern launching actions such as clearing the screen and loading a new level isn't that happy when you suddenly freeze the ARM9 that executes commands while the ARM7 keeps playing the music :-/

I tried a trivial workaround, that slightly improves the situation. But it's not improved enough : there is an interference remaining between fading-out and fading-in actions that may leave the screen partly obscured for the next level >_<

Je croyais contourner le problème facilement mais ce n'est pas si évident: la preuve, le jeu n'est plus bloqué, mais il y a eu interférence entre les opérations avant-veille et après-veille ... et du coup, l'écran reste à moitié noir :P

Par contre, j'ai pu faire une petite démo à Pierrick et Parmy ... et ça, c'était bien chouette ^_^

edit: corrigé

The bald's guy game

Vous vous souvenez peut-être d'Arne, le pixel artist qui nous avait fait de sympathiques faux-écrans d'un remake inexistant de Miner Willy ?
On lui doit aussi plus récemment une réinterprétation des graphismes de Super Mario Bros 1 absolument adorable.

Arne a un sacrément bon coup de crayon, aussi, comme en témoigne son projet de HDification du jeu C64 "exile" ... et il est apparemment assez prolixe en concepts de jeu qui n'aboutissent pas. Si bien qu'en février 2007 -- en pleine cave-story-mania -- Derek Yu lance sur le forum TIG un projet de convertir un des design originaux d'Arne en un vrai jeu. Oui, oui, on parle bien du Derek Yu à qui on doit le très réussi Spelunky (un croisement entre Boulder Dash et Rick Dangerous où chaque partie se déroule dans un niveau unique et aléatoire), et plus récemment Aquaria à la bande-son envoûtante.

A l'heure actuelle, "Balding's Quest" est toujours en développement -- au point qu'il vous faudra taper le nom d'un fichier .bqMAP pour pouvoir le tester -- et, chose peu courante, le développement est communautaire, chacun apportant sa petite touche perso (un niveau, une animation, un tileset, etc.). Pour rendre tout ça possible, BmCC, le programmeur en chef, s'occuppe du moteur de jeu central qui est scripté en Lua... j'ai d'ailleurs l'intention de creuser un peu comment ils s'y sont pris.

Le résultat est des plus sympa, avec un côté résolument 8 bits 1/2 ... mais attendez vous à mourir. Beaucoup. Mais toujours avec le sourire.

"Another visitor ... stay well ... stay forever !"

Par contre, le code a beau avoir l'air relativement générique et très customisable, quand je vois des choses comme ce paquet de if (...or...or...) je me dis que j'ai bien fait de suivre l'approche "proriétés des tiles et fonction cando()" de Xargon, tiens.

liens en vrac:
original design : http://www.itchstudios.com/psg/platform/platform2.htm (archive.org'd)

making it a sketch :

making it exist : http://forums.tigsource.com/index.php?topic=71.0

download : http://forums.tigsource.com/index.php?topic=4015.0

Methodology : Engine + LUA scripts for objects, bonus, etc. + BQanim text files

open-sourcing apple assault ...

The engine behind apple assault is open source from the start: this is my (modest) gift back to the world for having provided wonderful open tools such as Firefox, Linux, gcc and devkitpro. The problem so far is that pixel art, on its side, required a lot of work from myself, and I consider it as my own intellectual property that I want to keep under control. As a result, Apple Assault itself was closed source so far: publishing source without the art would not have run properly.

Le moteur d'Apple Assault -- tout comme l'ensemble des outils que j'ai développé pour DS -- est Open Source. C'est ma manière de récompenser tous ceux qui ont travaillé à d'autres produits open source que j'utilise tous les jours. Pourtant, jusqu'ici, il n'était pas possible d'avoir les sources complètes du jeu lui-même, notamment parce qu'il aurait de toutes façon été impossible d'obtenir une version fonctionnelle du jeu à partir de ces sources sans que je ne vous donne également les planches de sprites utilisées par le jeu. Et ça, je n'y tient pas: elles m'ont demandé des heures de travail créatif et acharné. Je souhaite qu'elles restent ma propriété intellectuelle.

Mais le petit script "8-bit-ify.pl" écrit ce midi devrait prochainement changer la donne: j'ai la possibilité de réduire la qualité des graphismes (leur donnant au passage un petit look 'C64' assez rigolo) tout en conservant l'entièreté de la fonctionnalité du jeu, et sans devoir passer par des phases de conversion de données fastidieuses. Avec le passage vers SVN comme outil de contrôle des version en prime, je devrais pouvoir vous proposer une version "commentée tutorielle" du jeu d'ici la fin du mois ^_^

Hopefully, I wrote a quick "8-bit-ify" script that convert the art (mostly killing details) such that it is still possible to compile and experiment, but not to fork a new project reusing the original sprites and tiles. Together with a switch to Subversion rather than CVS as the project revision control, you can expect a full open-source Apple Assault to come out soon as tutorial to the usage of my tools and libraries.

Somehow, it's fairly odd to play with those C64-feeling graphics at full framerate :P

source released on 24.12 MMX on Sourceforge.net

vsnes à la rescousse...

Bion, nous y voilà: à gauche la version SNES, à droite la version GBA. Même lieu (le boss du chaudron), Dixie sélectionnée et Diddy en mode "suiveur" dans les deux cas. Ambiance sombre et dantesque sur SNES, grosse bouillie rougeâtre à droite. Qu'il s'agisse du sol, du décor de fond ou de la lave, on a l'impression que la version GBA n'a eu droit qu'à un seul dégradé ... Je pourrais refaire la même analyse avec plein d'autres screenshots, je pense.

Face to face, the SNES and the GBA version of Diddy Kong's Quest (DKC2). I'd like to find out whether there was a technical subtle difference between the video hardware of the two that would explain why the GBA version is so ugly to my eyes... something like "DKC2 used an infamous 256-colour mode thanks to an on-cartridge bank switching device" or whatever... I used vSNES to analyse the use of video resources by DKC, but I couldn't find an evidence of such a techical explanation. So my only guess so far is that the colours have been changed *on purpose* to meet the rendition capabilities of the backlight-less screen of the GBA. Hover the screenshots below for english comments.

Avant de commencer à dire ce qui aurait été faisable ou non sur GBA, voyons un peu de quoi étaient faits les jeux de RARE sur la SNES.

J'ai trouvé un outil assez ultime pour ça: vSNES, un analyseur de cartouche et de savestate ... Comprenez : je démarre la ROM dans l'émulateur zSNES, je presse F2 pour sauver l'état, je quitte, et vSNES va interpréter l'état sauvé (contenu de la VRAM, notamment) et me permettre de visualiser les couleurs utilisées, le tileset (avec les différentes palettes disponibles), le rendu de l'écran dans les différents modes (DKC en mode 7 donne un résultat assez ... inattendu)

Première observation: 64K de mémoire vidéo pour la SNES, tileset et sprites partagés, les deux travaillant avec 16 couleurs par pavé de 8x8 pixels (les "tiles", vous vous souvenez). Chaque sprite et chaque pavé sur la map peut choisir la palette de 16 couleurs qu'il utilise, ce qui explique que j'ai des bananes oranges et un donkey correct à gauche, et des bananes correct avec un donkey psychédélique à droite.

Deuxième observation, les couleurs sont bien en R5G5B5 sur SNES, tout comme sur GBA. On aurait donc en principe pu reprendre les images de DKC (et de DKC2, vu que je n'ai pas de raison de penser que cette partie-là du moteur de jeu a été modifiée entre les deux épisodes) et les afficher telles quelles sur GBA. On a 3 plans dans le jeu SNES, la seule subtilité est que la priorité des tiles (devant ou derrière les sprites) peut être manipulé tile-par-tile sur SNES (comme sur la SEGA Genesis, donc) alors qu'il faudra obligatoirement passer par un layer supplémentaire sur DS ou GBA.

J'espère trouver un outil similaire pour GBA (no$gba sous Wine, peut-être) pour faire la même analyse sur la version portable du jeu. Ma seule hypothèse jusqu'ici est que l'écran de la petite portable (sans rétro-éclairage) aurait conduit à un jeu inutilisable si les graphismes avaient été conservés tels quels. Si je remets la main sur la DS Phat de ma fée, je pourrai peut-être me faire une meilleure idée...

Bleeps and Bloops...

Je dois avoir découvert Donkey Kong Country II chez un gamin en '96 ou '97, qui m'avais demandé de lui passer un de ces niveaux au-dessus de la lave dans le Chaudron du Croco. Le jeu m'avait fait une forte impression et je sais l'avoir fini sur SNES avant de me lancer dans la chasse au 103% avec ZSNES. Mon frère l'ayant dégotté en GBA -- alors qu'il n'a jamais été très Donkey --, je lui chippe une petite semaine. Hélas, le portage n'est pas à la hauteur de l'original: son "rabotté" qui sonne "début des années 90 sur Amiga" et des graphismes curieusement pauvres en couleurs ... Le gameplay semble être resté assez bien le même, mais garder le bouton 'B' enfoncé pendant tout un niveau se révèle pénible sur DS lite avec mes paluches d'adulte. Déçu, donc, mais intrigué de savoir pourquoi Captain N a ainsi décidé de massacrer un chef-d'oeuvre d'immersion sensorielle pour le faire tenir sur une console près de 10 ans après sa sortie sur SNES ... Voilà ce que j'ai trouvé au niveau du son.

My brother dug two GBA cartridges that we tested last week-end : Donkey Kong Country 2 and Super Mario World -- two major SNES hits that were converted to "prime" the new console. Both turned out to be fairly disappointing, esp. DKC2 that sounds and look like a cheap clone. This post collects pointers to the audio specs of the original Game Boy, the Gameboy Advance and the Super NES in an attempt to explain why the "cool sound" of the SNES couldn't be retrieved and why the SNES tunes usually sound more like MIDI than like tracked music, although the hardware 'looks' tracking-compatible.

Game Boy :

2 square waves, 1 programmable 32-sample 4-bit PCM wave, 1 white noise, and one audio input from the cartridge.[25] The unit only has one speaker, but headphones provide stereo sound (for further information, see Game Boy music)

En clair, au niveau rhytmique, on est proche de ce que fait le beat-voxing: un son masque complètement le précédent. Et celui qui veut faire dire "Ghostbuster ... wha hahahaa !" a sa console doit reprogrammer à la volée le buffer de 16 bytes jusqu'à ce que l'ensemble du sample ait été joué. Oui, quand ils disent "32-sample", ils parlent bien de 32 bytes si le son avait été 8-bit, et de 16 bytes vu qu'on a que 4 bit par échantillon. Rien à voir donc avec le "sample" d'un soundtracker.
Autant dire que quand "Zelda: Link's awakening" nous chante une mouette qui passe, le "z80" ne doit pas être loin du 100% d'utilisation de ses 4MHz tout mouillés (en fait, non. La mouette est faite à coup de square waves, et pour le reste, c'est surtout la technique des wave tables qui est utilisée).

SNES et son SPC-700 -- une sorte de System-on-Chip intégrant un CPU de C64 (6502), des unités de conversion Analogique/Digital, de l'ADSR en hardware, lecture de samples à vitesse variable et mixage hardware pour 8 pistes. 64KB de RAM dédié au contrôle de tout ce petit monde (et aux samples, évidemment) grâce à un programme pour SPC qui aura été "uploadé" depuis le CPU principal de la console. Ca me rappelle un peu le tandem ARM7/ARM9 de la DS, mais en horriblement plus custom :P

GBA :

The GBA supplies four 'analogue' sound channels for Tone and Noise (mostly compatible to CGB sound), as well as two 'digital' sound channels (which can be used to replay 8bit DMA sample data).

La réalité me semble un peu plus tordue: deux canaux de "square wave à timbre programmable", avec enveloppe simplifiée (linéaire, quoi), et un de ces canaux est capable de "portamento" en hardware. On a un canal de bruit (canal#4) et un "chipsound programmable" similaire au canal 3 du bon vieux gameboy. A côté de ça, deux canaux jouent ce qui sort de la ROM (ou de la RAM si on veut faire un modplayer) à grand renfort de transfer DMA -- exactement comme une Sound Blaster 8 bit, donc. De quoi expliquer le "look" si particulier de la bande son de Zelda: Minish Cap qui mélange "sons gameboy" avec des strings orchestraux et des voix numérisées pour les personnages. Pour jouer un .MOD de 4 pistes sur cette console, il faudra faire le mixage et le traitement de la hauteur de la note entièrement en software sur le processeur ARM à 33MHz. Si c'est techniquement possible, on aura sans doute plus grand-chose comme puissance de calcul à dédier au jeu lui-même qui devient une sorte "d'annexe au modplayer" façon Crazy Brix. Il faut aussi rappeler que le GBA a relativement peu de RAM (32K, plus de la "EWRAM" à accès probablement plus lent, mais dont je n'ai pas saisi le rôle précis jusqu'ici), et que si le SPC de la SNES pouvait laisser la lecture des samples au hardware dédié, avec un mixage en software, ça passera forcément à travers le même bus que le reste des données...

I'm pretty sure you remember your good old 486 DX 33 and his soundblaster, right ? That computer had the guts to do software rendering of a multi-track sample-based tune, but still, 90% of the games you can find on any DOS museum site will use AdLib (or clone) for the background music. And for a good reason: doing software real-time mixing of the samples will consume a good deal of your CPU's power. Yet, that .MOD tune you're struggling to play was likely written on an Amiga 500 clocked at 8MHz -- but that had dedicated hardware for bending, shaping and mixing samples. The very same thing occured between GBA and SNES : the GBA inherited from the sound system of the original Game Boy and has a stereo DMA channel to stream something else -- including something that is mixed in real time -- where the SNES had a slower clock speed, but hardware sound mixing.

plein d'infos sur le son du GBC (sauf à quel point celà diffère du GB :P) On notera sur GB et GBC la présence d'une ligne "audio IN" de la cartouche vers la machine. Pas souvent utilisée commercialement, mais ça ouvre la possibilité de monter un soundchip ADlib sur une cartouche GBC pour se faire un remake ultime de Fury of the Furries ;)

Download AppleAssault 1.4

-- Oh wait. You could download version 1.6 instead !

Voilà, ma petite puce m'a enfin laissé assez de temps pour passer le dernier coup de polish sur Apple Assault que je peux du coup vous proposer en version "1.4". On y retrouve le "super-poing", des transitions entre les niveaux, correction de quelques bugs d'affichage dans l'écran-menu, support de la musique multi-piste amélioré. Je crois que c'est tout. En principe, ce sera la dernière version: je prépare un package "sources" et je passe à la suite.

See this post for the latest update on Apple Assault featuring the berry bat and revised apple rate.

Here you go: Apple Assault in its final "1.4" version. You keep fighting against apples, using your punch, big-punch, shuriken and evasive moves. This release introduce transitions between levels, improves support for multi-part soundtrack, and fixes minor graphical bugs in the menu screen. I don't plan to evolve this game further on : it's time to move to other Bilou games as soon as I have a source package released.

Introduction
Bilou et Bouli viennent juste de se crasher sur une planète étrange. Pendant que Bouli répare l'écran protecteur de l'Astrocruiser, Bilou doit faire face à une horde d'applemen déchainés !
Le jeu se joue sur 4 secteurs (nord-sud-est-ouest) que vous devez nettoyer avant de passer au suivant. Sautez d'abord sur les applemen avec (A) pour accumuler de la force de frappe que vous utiliserez pour les expédier au loin avec (B). A chaque vague d'assaut, les applemen sont plus nombreux. Jusqu'où tiendrez-vous ?

Bilou and Bouli have crashed on a strange planet. While Bouli is repairing the Astrocruiser's repellor shield, Bilou (the blue ball) has to keep hordes of crazy applemen away ! The game feature the four fields surrounding the cruiser that you must clean up so that Bouli can finish his job and provide you a safe retreat for further exploration. Stun the applemen by stomping them (A). That will provide you more punch power to dispatch the assaulters further away (B).
In each assault wave, the applemen will come back with reinforcement. How long will you stand ?

trucs & astuces

• pour faire progresser la barre de punch plus vite, rebondissez sur les pommes (en réappuyant sur A au moment du choc)
• les petits vers ne peuvent pas être éliminés, mais vous pouvez aussi rebondir dessus pour augmenter votre punch sans pour autant approcher les pommes.
• dès que votre barre de punch est remplie (elle vire au jaune et une musique spéciale se fait entendre) , Bilou peut lancer un shuriken dévastateur. Par contre, celà vous videra de tout votre punch de moitié.
• plus vous enchaînez les rebonds sans toucher le sol, plus votre score grimpera vite !
• choisissez votre niveau de difficulté en mangeant des pommes dans le menu.
• Funky Funghi, le champignon du niveau 4 est invulnérable. A contourner soigneusement.

Bug connu: bloquage du jeu possible si vous fermez la console pendant un chargement de niveau. Investigations en cours ...(corrigé dans la version -ld)

gameplay tips

• you can build up your punch power faster if you press (A) again when bouncing on applemen
• yellow worms can't be dispatched, but they can "help" Bilou building punch power while staying at safe distance from apples
• once you've gathered enough power (your punch bar turns gold and the music change), you'll shoot a devastating shuriken instead of merely punching.
• the more bounces you chain without touching the ground, the more you'll score.
• check out the gameplay teaser video if you still can't beat level 2.
• grab apples on the menu screen to select harder game difficulty.
• Funky Funghi, the mushroom of level 4, cannot be defeated. Focus on the apples and don't mess with him.

If you think the gameplay choices are odd or bizarre, think of Apple Assault as a game in the lineage of Mario Bros. -- the initial, non-super one or Bubble Bobble

Historique sur dev-fr.org
Le projet sur Sourceforge

reported to work succesfully on R4, SuperCard DSTWO (Cid) and Acekard2i (Cid).
Fixed Bug: closing the lid just while the game (re)loads a level no longer leads to a livelock.

Special Thanks:

• Pierrick H. for initial gameplay concept and contribution to Bilou's character
• Crazy Kirby Kid for his detailed gameplay consulting
• Ged and Cyril for additional gameplay review
• Lestat, Alekmaul and Morukutsu for quality revision
• Wintermute and the devkitpro team for making it altogether possible
• Rémi, Thomas, Nathan et les filles for testing
• My fairy, for providing me the time to hack this together
• You for playing and buzzing ;)

Stuck again >_<

A peine avais-je corrigé cette histoire de "blocage en tombant au sol" que je me rends compte que Bilou peut à nouveau se retrouver coincé dans un mur >_<.
J'ai un peu pataugé pour trouver le soucis (de nouveau lié au changement que j'ai introduis il y a une ou deux semaines), entre autres parce que je cherchais au mauvais endroit. La dernière fois qu'une telle chose s'était produite, c'est le "StopController" qui ne vérifiait pas que Bilou ne rentrait pas dans les murs. Mais cette fois-ci, rien.

Himmel! Just after I fixed the land-and-got-stuck case I mentioned last week, I got a phone call from GuiEngine, asking me to find out who smashed Bilou into a wall up to the point that he became definitely stuck! Once again, I suspected a side-effect of the new way events are managed, and investigated collision checks in StopperController who were involved in similar cases a while ago.

J'ai finalement repris les choses à la base, avec la fonction "pas à pas" de l'InspectorWidget -- maintenant totalement rétabli, pour me rendre compte tout d'abord que c'était bien pendant que Bilou marche qu'il heurtait les murs, mais aussi que le problème ne venait pas d'un signal FAIL mal traité, mais du fait que les contrôleurs (en l'occurence la gestion de l'inertie) générait des EVENT à tort et à travers, court-circuitant certains tests.

But the stopper was innocent this time. I was sneaking on the wrong guy. I was walking down dark, cobble streets, under pouring rain with hope that one of my contacts would sing me a clue... in vain.
I sat down and opted for another strategy, reviewed the facts and the pictures shot by Inspector Widget one after the other, and the truth at last appeared to me in a flash: Bilou was walking when he got embossed into the wall. It turned clear that DDD had lied to me and that he should be paid another visit. "You asked me about FAILures!", he said crawling on the ground, "I told you all I knew about them !..." - "You did", I replied, "and still you knew there was more to tell. Where can I find DPAD and Momentum ? They're hinding since the start of this case!". Panting and flickering, it didn't take long for DDD to sing after I pointed my breakpoint at him. Before the end of the hour, I had Momentum tied on the back seats of a car: he'd never forge fake speed limit reports again.

Apple Assault = ?€

If you're reading this with an RSS reader, chances are that you've missed the "You would buy Apple Assault for ..." poll that will close within 10 hours. The idea is simply to help me figuring out the new trends as I've never been that much into buying ringtones or logo myself, under the hypothesis that Apple Assault was available, polished in its ideal final version, e.g. on the DSi. So far, the poll suggests that 1€ would be a bit too high, and that ~40% of this blog's audience isn't ready for pay-download-and-play systems.

Voilà, si vous voulez participer à l'enquête "combien vaut Apple Assault", il vous reste encore 10 heures pour faire entendre votre voix. On parle ici d'un Apple Assault finalisé et hypothétique qui serait à la disposition des masses sur DSi Ware, par exemple, ou un "game store" similaire pour une autre console.
edit: poll closed, figures updated

Got Stuck ?

Hover me

Dans un vrai développement, introduire quelque-chose comme les transitions en cas d'évènement liés aux contrôleurs alors qu'on est en phase pre-alpha n'est pas souhaitable. J'aurais été au boulot, j'aurais au moins fait un "svn copy trunk/ branch/..." avant de m'y attaquer. Mais voilà: c'est un projet-hobby et la liste des choses à faire entre une version et la suivante n'a plus grand-chose d'excitant...

This is something you'd never see occuring in a "real" project, but this one is a hobby project. I may know very well how to use SVN to create branches and avoid that an experimental feature triggers a bug in a pre-release, and I do it on regular basis for work. I just don't care too much about it when it comes to hobby project: I do what I wish yo do when I feel so. And so I may end up with Bilou curiously getting randomly "stuck" again when he hits the ground, not responding to DPAD anymore, etc. It doesn't even get hurt by Applemen, as you can see...

InspectorWidget, functional, but not fully restored yet

Bref, je me suis retrouvé à avoir Bilou bloqué de temps en temps au moment où il touchait le sol. Fort heureusement, InspectorWidget n'était pas bien loin, sans aller jusqu'à dire qu'il soit complètement opérationnel avec ce changement d'écrans ... Mais je ne suis pas mécontent d'avoir passé du temps sur ce petit débuggeur intégré l'été dernier: alors que j'avais sèché sur le script "bilou.cmd", il m'aura suffit de reproduire le problème et d'appuyer sur [START] pour découvrir que ce n'étaient pas la chute, mais bien les manoeuvres d'évasion qui étaient en cause.

This is where InspectorWidget turned handy again. I was cautious enough when I disabled it for AppleAssault, and it wasn't very far away. It's tempting to claim "all I had to do was to change bool InspectorWidget::FullyQuiet = truefalse; in main.cpp, but the recent swap of screens required a bit more tweaks and cleanup. And as shown below, it's not yet fully recovered :P
Yet it was sufficient to point me at those evasive moves for further investigation -- I was searching for bugs in the regular "falling" states until then -- and the fix should now be trivial.

/* fixed: la plupart de ces bugs d'affichagent étaient dûs à la redirection de la console (consoleInitDefault() vers l'écran du bas qui détruisait les caractères personnalisés par Engine::createChar() :P */

/etc/init.d/biokid reload

Eh voilà. Deux minutes de relâche et Biokid refait à nouveau son apparition. Aderack le présentait comme "jeu le plus représentatif de l'époque PPP Team", mais surtout, avec mon nouveau thème de recherche, des histoires de sécurité, de DDoS, de vers qui se propagent, d'agents intelligents, de systèmes de défense, détection d'intrusion et compagnie, j'en consomme jusqu'à saturation.

Working on intrusion detection and network resilience these last weeks make Biokid pop up again in my mind and on my sheets. Or maybe is it because Aderack pointed it out as the most representative game in PPP's library ? Let's see whether buffer overflows, traffic shapers and worms spreading turn into nice level design ideas ...

Je vous laisse donc ce petit scan d'exorcisation, et on verra bien si le fil se poursuit et s'il en sort quelque-chose... transformation des buffers et autres processus de résolution d'adresse en élément de level design ?

Je suis revenu à un gameplay plus "plate-forme" que la tentative de shoot-em-up de 2008, en tout cas.
todo : non-square sprites in SEDS. 32x40 would be a good template for Biokid.

Tous les croquis

Dis-moi qui tu hantes et je te dirai qui tu es.

En vrac, mais à peu de choses près dans l'ordre chronologique où je les ai découverts, voici les jeux qui m'ont séduit ces dernières années. Je ne suis certainement pas objectif, et j'éviterai donc d'essayer de leur attribuer des notes. Je me contenterai donc de relever les points forts et les points noirs de chacun d'entre-eux.

There are a lot of games I've played during the year -- sometimes for several weeks, others for a few minutes -- which I couldn't find the time to speak about. Here's a quick dump to show you what I could have been chatting about (most of them being neatly covered by experts anyway).

Space Invaders Extreme

(trouvé à 15€ chez Free Record Shop)
+ L'aspect visuel "neo-oldschool" réussi
+ Je fais le D-J en jouant
+ la sensation de puissance quand on enchaîne les powerups
+ la fin du jeu (en mode easy)
+ sur DS, et donc "on the road"
- je coince sur le même niveau depuis des mois
Loved the revival as much as I hated the original. The gameplay is smooth and power-ups (via special rounds) really give me the thrill.

Shatter

(essayé sur la PS3 de mon frère)
+ L'aspect visuel épatant
+ La bande son extra -- et téléchargeable
+ Le jeu passé sur Steam
+ Réinvente le casse brique au lieu de le réchauffer
- Steam = Windows, non ?
Another game genre reinvented, with a stunning soundtrack. I hadn't time to master the game.
Finally got it with my bro's old PlayStation (2? 3? dunno). A great example of readability and likely reached final levels

Loco Roco

(essayé 15 minutes avec la PSP d'un collègue)
+ le côté "mimi-cracra" du graphisme
+ les personnages qui chantent stupidement façon "les engrenages du professeur machin"
+ le jeu physique, les mouvement du blob.
- je n'ai pas de PSP, je n'ai pas l'intention d'en acquérir une juste pour un jeu.

I was a huge fan of The Incredible Machine. The cute look reinforce my wish to throw the game a try. Finally played it a bit more, but it turned disappointing after a few hours. I don't regret not picking a PSP for that one alone.

World of Goo

(dévoré la version démo Linux après avoir bavé devant des vidéos vues sur des blogs d'indie)
+ puzzle à la "The Incredible Machine"
+ des bestioles ridicules à la Worms
+ graphiquement et musicalement accrocheur
+ variété de comportement apparaissant progressivement
- pas toujours évident de reproduire l'effet désiré
- pas disponible sur DS.
I really enjoyed the demo, but that's something I'd rather play on the road, not on my laptop.

Professeur Layton : la boîte de Pandorre
(acheté après avoir dévoré le village mystère)
+ le côté dessin animé et Sherlock Holmes
+ des puzzles sympa pour les soirées en solo
+ ma fée aime aussi
- version française uniquement sur ma cartouche
- voix françaises sans véritable charisme
- j'accroche moins à l'intrigue sans bien savoir pourquoi ...
A deceptive purchase... I only got the "french dubbed" version, which somehow ruins the experience

Maestro: Jump in Music
(découvert dans le magazine IG, trouvé en rayon à la médiathèque du coin)
+ très chouette graphismes "pixel art"
+ le côté "humour décalé"
+ le premier jeu où je regrette qu'un niveau soit fini à la fin du niveau
+ le mélange rythme/plate-forme réussi
- les tutoriels à chaque nouvelle technique
- introuvable dans le commerce
- si je le trouve, je devrai refaire le jeu entier au niveau "easy" avant de réattaquer les niveau "normal" et "hard"
- certains instruments criards, notamment dans les morceaux plus Rock.
- les "combats" contre les boss répétitifs et parfois "injustes".

Soul Bubbles

(essayé chez mon frère)
+ le côté visuel et sonore enchanteur
+ le côté puzzle, régulièrement renouvelé
+ la progression non-linéaire qui incite sans contraindre à l'exploration
- une seule sauvegarde
- des niveaux très longs
- petits artefacts visuels sur le décor qui nuisent parfois à la crédibilité de l'environnement.
every play is an enchantment, but it requires lots of free time just for one level.

Pixel! -- Pix'n'love Rush
(trouvé sur le site de Pasta games en cherchant plus d'infos sur Maestro)
+ L'animation épatante du "chat"
+ un bon vieux platformer tout neuf
+ le coté retro-new-look très réussi
+ la dynamique apparament sans défaut
- je n'ai pas d'iPhone, et je n'ai pas le projet d'en acheter.

got it on my bro's old playstation as well.

Giana Sisters (DS)

(croisé sur la couverture d'un magazine dans le trans-alsace express)
+ Brothers are history !
+ une animation épatante et des graphismes réussis
+ des niveaux, encore des niveaux, plus de niveaux
- système de power-ups complétement corrupté
- manque de challenge par rapport à l'original
- virtuellement introuvable dans le commerce

My Bro finally found it, but I confess the level design and the collect-a-thon aspect disappointed me. I may have went further in the "Twisted Dreams" episode, despite the readability and gameplay issues.

Frogatto & Friends

+ de la plateforme, de l'action, de l'aventure
+ du pixel art de haut niveau
+ tourne sous Linux
+ Open Source, pour ne rien gâcher...
+ ce que Frog Story aurait dû donner
- les dialogues que je vais devoir me retaper parce que je me suis bloqué dans le jeu
- la version installée qui plante quand je meurs.

completed.

Worms Reloaded(pas encore essayé : pas encore rebooté sous Windows)
+ worms
+ action 2D comme dans worms
+ worms
? la corde ninja sera-t-elle au rendez-vous ?
+ worms
- windows
(je ne suis peut-être pas tout à fait impartial)

still not played so far.

Shantae : Risky's Revenge

(à essayer chez ma belle-soeur ?)
+ graphiquement parfait
+ apparemment le genre de gameplay qui m'accroche
- uniquement sur DSiware ... je n'ai pas de DSi

PS: quand je dis , c'est que j'ai atteint une des fins du jeu (pas le game over, quand même). Pas forcément la meilleure ni au niveau de difficulté le plus élevé.

Owned. One of my references.