--load-type=1

It seems like I finally figured out why I had so much trouble with desmume on my new Linux. It's nice from desmume developers to warn me that DLDI would not work. Maybe it would have been nicer if using --cflash-path had automatically modified the load-type so that the tryPatch wouldn't segv while trying to operate on a NULL pointer...

Now, I'm ready to resume checking whether my mode-switching code is worth a push.

Bien ... il suffisait donc d'ajouter --load-type=1 sur la ligne de commande pour pouvoir utiliser l'émulation de carte mémoire avec desmume. Je suppose que j'aurais dû pouvoir le trouver sans faire de back-tracking à partir d'un émulateur en train de planter, mais c'est mon côté guru: plus à l'aise dans les sources que dans la doc.

Au fond des pyramides ...

J'ai enfin un deuxième élément pour meubler la "pyramide infinie", prochaine idée de jeu que je voudrais utiliser pour Bilou. Une sorte de mélange entre les blocs-l'hermite de Toki Tori 2 et les crabes de Donkey Kong Returns...

I'll need some monsters in addition to traps if I want to make an interesting pyramid/labyrinth. But I also still want to feel alien, and not just "oh, this is Egypt in 2000.A.D.". This crawler is not yet named, but I like the look of it. Codename 'InfinitePyramid' starts here

Si on relookait la Green Zone

Bon, vous vous demandez peut-être pourquoi avec un moteur de  jeu fonctionnel et des pixels tout prêts il n'y a toujours pas moyen de s'essayer aux niveaux dessinés par Piet dans les années '90...
Il y a la raison du jeu: sans les 6 mondes qui suivent, la green zone n'offre pas, à mon avis, un challenge intéressant. On pourrait se promener dedans,oui. On pourrait y assommer des pommes et y chercher des vies, mais quel intérêt si il y a de toutes façons suffisamment de vies pour terminer les niveaux sans ça ?

Ensuite, il y a la raison du relooking.

I suppose I could be spending my time crafting levels that mimmic the BASIC version of Bilou's Adventure, since I have pixels for the Green Zone and a working game engine. But I question the fun of such a package. The Green Zone doesn't feature sufficient diversity (imho) and is mostly hunting for secret 1-UPs here and there. But what's the point of 1-UPs when you have only 4 levels to explore ?

Je n'ai pas forcément envie que la nouvelle green zone ressemble exactement à la version Basic. Des clés, des portes, des tuyaux et des bumpers ? Bilou ressemblerait alors à un mélange entre sonic, Mario et keen. Je voudrais qu'il ait plus son identité propre. Un napin qui aide à sauter, un mécanisme pour ouvrir le passage... Le genre de chose que Piet aurait mis en place si je n'avais pas dû simplifier pour que ça passe en Basic.

The second reason I'm not jumping into that is that I still would like some revamp of the mechanics used in those levels. If I stick to floating platforms, bumpers, colored keys and locked doors, Bilou's Green Zone would just look like Sonic * Mario * Commander Keen cross over, which imho wouldn't be interesting. I'd like to have crabit featured as moving bumper, for instance.

I must not put it on hold for too long, though. J.l.n just turned 4 years old and he starting to have the basic skills to jump over pipes and stomp goombas...

class LayersConfig

All my DS tools share the same "GUI engine", but all somehow have custom requirement on what the hardware compositing engine -- the "layers" system -- should do.

Yet, so far, they do that by peek/poke-like custom lines of code hacking into the video registers of the Nintendo DS. Because the hardware is so elegant, I had no real appeal to hide it between an abstraction layer, but now I run into issues where console can't be read anymore.

So let's try to make it more structured. Capturing all code that access the layers control register into one class would be nice. I think that class -- let it be "LayersConfig" -- could be associated with *Windows classes that define the different "modes" of the application. Switching between the drawing-on-grid and the Palette-edition of the Sprite Editor implies changing the active window. Same for swapping between files picking and map editing of LEDS or swapping between downloads and playtesting in RunME.

I think I should stop trying to optimize which character is updated on such window switches and consider that there should be a clearscreen followed by a full repaint, if that's not yet the case. That could make Window::clearscreen an interesting place to do tricks like letting only some part of the console show through, for instance.