SchoolRush NY2018

Happy New Year Everyone. I've got a new build of SchoolRush uploaded. Hope you'll enjoy it. For those of you who mastered the game, you'll discover the credits level and the hint towards the secret, vertical level that I've been working on half this year.

Prêts pour la nouvelle année ? Voici une version de Bilou: School Rush avec un niveau secret terminé, des images de chargement qui racontent l'histoire du jeu, la séquence de crédits ... Et pour ceux qui n'arriveraient pas encore jusque là, deux modifications qui rendent le jeu moins impitoyables: on peut "nager" hors de l'encre (encore faut-il pouvoir trouver une plate-forme où atterrir) et on grimpe automatiquement dans les encriers quand on tombe dessus, même si on tenait un taille-crayon entre les mains.

For everyone, you'll enjoy the "swim up for your live" mechanics that will let you go forward even if you missed a jump and fell into the ink. Well, you cannot recover *every* missed jump that way, but it's already much more forgiving than it used to be.

You'll also enjoy how jumping into an Inkjet now automatically let you in, dropping the Dumb Blador you're carrying, if any.

Story and gameplay migrated to latest release post
how to play
Get the .NDS image and play it on your homebrew-ready console or in an emulator, such as DeSmuME. See latest post if you need extra explanation/instructions for running homebrews.

[done] fargrounds

Eh bien, ça en aura fait des rebondissements pour débloquer le "super décor du dernier niveau"! Mais on y est. Du coup, les derniers éléments sur la "todo list" de School Rush, je vais les rassembler ici façon "bullet journal"

• [done] la séquence de fin pour de vrai
• [cancelled] le niveau bonus
• le mécanisme pour se rendre dans le niveau bonus
• une éponge qui monte-et-descend à la surface de l'encre, svp ?
• [done] un affichage du nombre de vie (intégré aux images de chargement ?) 

At last, I have proper background graphics for my final secret level. The time is right to review the to do items, close some and bring here what will have to be done to get the game completed, bullet-journal style (as I don't have phabricator-for-sourceforge).
None of the things that are still on the todo list for School Rush could really be completed by the end of the year. But none is blocking a release either. I think we can call the vertical level .done. That took almost half the year, but I think it worked. Enjoy your season holidays.


Rien de tout ça ne semble faisable en quelques jours de super-papa-bros, donc on va emballer ce que j'ai pour boucler 2017 et prendre le temps de faire le reste correctement en 2018. Bonnes vacances.

Ce niveau vertical aura occupé une grosse partie de l'année donc, du mois d'Avril à la fin décembre, mais au moins il est testé et validé. Il reste sans doute un peu mystérieux à la lecture de ces lignes ... forcément, c'est quand-même un niveau secret ;-)

Refactored, but freezing

ok donc, j'ai eu du code qui compilait en un rien de temps, malgré un refactoring plutôt osé. Par contre, plus moyen d'atteindre la fin du premier niveau: le jeu freeze, à peu près tout le temps au même endroit, juste avant de m'afficher les premiers "inkjet" mobiles.

Good joke! How useful is it to get refactored code compiling if you cannot reach the exit of level 1 anymore? The game now freezes every time roughly at the same spot, just before the first moving inkjets. I will need my mercurial time machine...

Je prends donc ma machine à remonter le temps (comprenez mercurial) ... le bug semble aussi se produire avant la refactorisation ... j'évite donc de passer pour un clown qui fait des effets d'annonce sur son flux twitter, mais je n'ai quand même pas du code qui marche. J'ai noté que A. avait réussi à rejouer aux premiers niveaux après avoir fini le niveau vertical, donc il existe un point pas trop éloigné dans l'espace-temps où j'ai du code qui n'a pas ce problème.

"Good" news is that the bug wasn't introduced by the refactory -- at least, my twitter-honor is safe. But honor does not make code run. I know that A/S-team could beat levels 1 and 2 during the last playtesting session, so the bug must have been introduced fairly recently. If I could find the last working commit, that would help understanding what went wrong and how to fix it.

Reste à le trouver pour comprendre ce qui cloche. Pour ça, j'ai maintenant mon programme automatique de "unit-testing" qui simule un va-et-vient dans les niveaux.
Et le programme de test en question crashe, lui. Un beau gros "segmentation fault", dû à un débordement de pile. Et la fonction "backtrace" capable de m'indiquer où s'est planté le programme et comment on en est arrivé là prend un plombe à s'exécuter (en fait, j'ai intérêt à l'interrompre):

• CompoundGob::collide(#288)
• BlockArea::collision(#1934)
• InfiniMap::getflags(#350)
• GameObject::cando(#1786)
• CompoundGob::loadAnim(#178)
• CompoundGob::setstate(#52)
• CompoundGob::collide(#288)
• BlockArea::collision(#1934)

Hopefully, I now have an automated test that moves back and forth through the levels. And that test program crashes (big segmentation fault) when running one failing build. The backtrace function of my debugger takes ages to point out where the crash occurs (and how the program reached that state). When I interrupt it, I see no memory reference on the "call" instruction. All registers have valid values, no invalid opcode to be spotted around. The only suspicious thing is the fact that there seems to be a repetitive pattern in the function calls.
Then I checked the value of the stack pointer and Captain Obvious knocked on my head.

Oui, vous avez bien vu: on tourne en rond. Et le code fautif serait apparu pendant que j'essayais de corriger le problème des personnages qui jouent à Philadelphia Expérimental avec le plafond.

Mais comme j'ai une release à assurer demain au boulot, je vais pas la faire trop longue. On sait où chercher. On cherchera pendant les congés entre les paquets de Noël et les cotillons ;-)

This is a stack Overflow, caused by something in the new code that enforces alignments when resizing bounding boxes. It is obvious because the stack pointer has the lowest allowed value, given the area allocated as stack according to /proc/self/maps. It is too late to start searching what and why, but at least I know what to look for and roughly where.

edit: trouvé en 20 minutes de "cybook" pendant que *deline travaillait sa danse. Corrigé en à peine davantage. On va pouvoir reprendre le travail sur les plans de scrolling ;-)

got it located while *deline was having her dancing lessons, fixed in about half an hour. I thought it would take me at least a week-end. Good. I'll be able to go on with the rest (todo: figure out what still has to be done)

Refactoring de dingue!

J'hallucine. J'ai pris une de mes plus vieille classes -- InfiniMap, responsable à la fois du scrolling et des collisions sprites/map. J'ai renommé ça en "CommonMap", appliqué les changements partout sauf aux sites de construction. J'ai ensuite déplacé le code utile dans un nouvel InfiniMap, déclaré l'une ou l'autre méthode comme purement virtuelle dans CommonMap ... et recompilé.

I can hardly believe it. I picked of my oldest classes -- InfiniMap, that controls  scrolling and  -sprite-vs-world collisions -- and renamed it common map, everywhere but on lines of code building some instances. I then moved the "real" code into a new InfiniMap, mentioned a few ."pure virtual" markers in common Map, and rebuilt...

Et ça marche ! C'est du délire à l'état pur. Ok, j'avais une classe iWorld mais je ne m'attendais pas à ce que le truc ne réclamme aucune autre intervention. Nada.
Allez, demain, je déplace le maximum de variables membre.

And it works! I can't beleive it! (dott). I knew I had some interface class already, but I wasn't expecting it to work that easily, not requiring any fix or whatever !

branches, reviews and cannelloni

The idea is hanging around. It has been for some times, now. Possibly since I re-started exporting code to e-book readers through Doxygen, or since I tried to use apple assault as a tutorial to libgeds. I'd like to go for some in-depth review of my engine code. I'd like to use powers of code versioning system to slice code into readable, purpose-supported chunks, which would help the reader which components bring what feature and how they interact together.


Plus les choses avancent, et plus j'ai envie de pouvoir proposer quelque-chose de plus didactique pour encourager d'autres amateurs de développement de jeu à s'essayer à la plate-forme NintendoDS. Pour ça, il me faudrait pas mal de réorganisation du code, et (idéalement) une branche mercurial qui approcherait les techniques nécessaires une par une, mieux documentées et testables. Et là, maintenant, c'est parti.

But now, I started it. I've got a "bare minimum" DS application with corresponding library code (mine or 3rd-party), and its build system.
[done] found the source of Noda's EFs tool again.
[done] have it built as part of the dsgametools host-tools binaries, buildroot-style.

Far ground

Je tente d'intégrer mes bouquins-totems comme décor de fond du niveau vertical ... après quelques essais/erreurs pour faire le bon montage, qui ne consomme pas trop de mémoire vidéo, quelques corrections pour que le moteur de jeu puisse utiliser effectivement les 256KB dont il dispose plutôt que de s'auto-brider à 128K, je commence à avoir quelque chose... Enfin presque. L'état du code pour la gestion du décor en parallaxe n'est franchement pas terrible

I'm trying to integrate the tiki-books as the background of the secret vertical level. it took a few trials to get something that fits in the renaining video memory, which is much easier after I grant access to the full 256KB allocated. well, sort of ... Unfortunately, the code for parallax scrolling is carrying lots of legacy, hard-coded settings suited for 512x256 -picture, while this new level needs it the other way round. The wale also picks camera coordinates directly, leading to a. weird offset on screen.

• le code qui effectue le chargement de l'image ne supportait que la taille de 512x256 pixels alors que je veux maintenant utiliser le système en 256x512.
• le code de scrolling utilise directement les coordonnées de la "caméra" en les divisant par deux, de sorte qu'il me décale le décor de 64 pixels sur la droite
• on dirait que seul un des deux "écrans" est utilisé, en boucle, plutôt que d'avoir un décor deux fois plus haut que large ... à l'exception de certains endroits où le décors est sans dessus dessous.

Il va y avoir un peu de travail pour corriger tout ça.
plus, l have only half the picture showing up, rather than two sets stacked onto each other. And at some place, the scenery is completely messed up. it will take some work to get all that fixed. Maybe if I hack some forced, auto-scrolling, the defects will become clearer.

edit: je devrais essayer de mettre un auto-scrolleur sur le plan de décor, tiens... ça simplifierait les tests.
edit2: en effet, ça simplifie.

• [done] le coup des décors sans dessus-dessous vient probablement du fait que je ne chargeait que la moitié de ma map (eh oui, il faut 2 bytes par pavé, pas un seul)
• [done] par contre il y a clairement quelque-chose qui annule l'effet du réglage "32x64" (l'ordre d'appel des fonctions, en fait). 
• [done] Et pourquoi ai-je un VBL handler appelé deux fois, pour deux maps différentes, et qui modifient les registres des deux plans ? 

cando grow?

Not so easy to fix the state machine bug about Bilou entering ceiling And that is mostly because it is not in the state machine itself. It happens because Bilou has two sizes, and the "HIT" state is one where he is big. Since"HIT" is a state that you can reach from almost any other state, we can't really "fix" the problem by conditional transition.

So I took my code back and started looking around the call to CompoundGob::setbbox() for inspiration.
1. the "grow'shrink." mechanism can be nicely separated along axes. I shall try it on the vertical axis alone so far.

2. I should use cando() function to detect potential issues with virtual movements before I actually change the size. That should be much easier to have something where we check whether we could move up by dy (actually grow upwards) and align coordinates if we can't.

Corriger le problème dans la machine d'état de Bilou pour lui éviter de se manger le plafond se révèle plus compliqué que prévu. Et pour cause: le bug n'est pas dans la machine d'états. Du point de vue du moteur de jeu, Bilou a deux tailles (de bounding box) différentes, et l'état "touché" est un des états où Bilou est grand. Du coup, puisqu'on peut se faire toucher dans à peu près tous les états, il n'est pas vraiment possible d'éviter un changement de taille par une transition conditionnelle.

Il faut donc que je révise plus en profondeur le système de changement de taille (setbbox). Heureusement 1) je peux traiter les axes horizontal et vertical séparément; 2) je peux me servir du système "cando()" pour sonder le terrain avant de procéder au déplacement. 3) si je sais corriger jusqu'à la prochaine frontière de tile, je peux itérer pour étendre à des redimensionnement plus conséquents (à vérifier plus tard).

3 . That will work for small resizing, and .can be extended to duck/stand for.human-sized characters  with a simpe - iteration. I haven't tested that, because all shrink/grow changes in Bilou change size by a mere few pixels. And I presume it wouldn't be completely satisfying for something like granting mushrooms for Super Mario. For one thing, the code assume that it is possible to grow. It won't catch the situation where small Mario would get a mushroom in a narrow corridor of bricks.

Tout ça m'aura demandé pas mal de gribouille pour m'assurer que je comprends bien tous les cas de figure et éviter de devoir mettre un grand nombre de tests excessifs pour traiter plusieurs micro-cas (parce que certaines valeurs sont nulles dans certains cas). Peut-être même que je n'ai plus besoin, désormais, du système qui transmet des consignes d'alignement (avec le centre, le bord supérieur ou inférieur) ... mais ça, ça demande à être prouvé, et on verra plus tard.

It took quite some sketching to find the right adjustments and avoid ending up with tons of tests to find all corner cases, but instead do the right computations, taking advantage of the fact that some terms are just zero in some cases. I think I might even no longer need hints about which side we should align against, but I prefer keeping them at the moment, until I get the proof that they indeed turned useless.

fix

spriteram vs . Resource

Using InspectorWidget to understand buggy situations has become abnormally hard. Just look at the picture we got earlier this season. Compare that to what it used to look like. I've got the "boxes" area all messed up. Of course: in School Rush I now have two things trying to use the sprites of the bottom screen: Inspector Widget and the HUD.

I needed to change a bit the code for the HUD (which uses a SpriteRam to load hud.spr) so that it tells the GUI engine that it used some resources, which are thus no longer available to the InspectorWidget... and let the Engine give some other tiles to Inspector Widget.

One thing I had overlooked is that I devoted up to 256KB of VRAM to background tiles on the main screen, leaving only 16KB for HUD sprites. At 256 bytes per 16x16 block, that means I can have at most 64 different blocks at all. I have 20 different sprites used, 44 left.

Inspector Widget uses 1 such block for "box-borders" (with 4 different flips), and then it has 4 areas-reporting sprites (made of 64x64, 16-color sprites that get scaled up and down to match the effective area shape). That's 32 "tiles" count each for the engine, or 8 of the "blocks" I've used above. So with proper values, I can get it right.

MMU9 write32 to undefined register 04001058h

While working on a solution to get-into-walls bug, I had a ugly alignment bug to fix. I have many debugging tool, but none was really helpful (once again), partly due to my lovely HUD that now takes the bottom of the screen...

InspectorWidget est en vacances,
iprintf en arrêt maladie,
ddd fait la grève du code optimisé,
Qui reste-t'il pour sauver la journée ?
Qui, sinon 0xbadb07 !

Ouaip, y'a une adresse-mémoire qui provoque un message sur le terminal quand l'émulateur la rencontre, avec la valeur posant problème, et même l'emplacement dans le programme. Alors j'ai rajouté comme un malpropre des accès direct à cette adresse pour envoyer un diagnostic d'erreur à travers le subespace de l'émulateur.
Du coup, je peux corriger mon code. Ciao.

And then i've seen that error message from desmume while launching the system: something in the boot code tries to write at some place where NDS documentation doesn't claim any register. A non-fatal condition. But that means I have a way to export a series of values as the program is running. Crude debugging, non-portable and likely to be broken at the next desmume update, but debugging nonetheless.

The fix is thus made. I can commit and go to the bathroom ^_^

power-button bug

On the game design axis, I am quite satisfied with the final level of school Rush and how it integrates with the earlier levels. It took A. (from the S-Team) Some 30 attempts to beat it, but she hasn't turned mad or bored, and even enjoyed being wrapped to level 1 afterwards.

On the technical side, my latest personal tests hit me with a bug I thought I fixed long time ago: getting stuck in a ceiling, There are few places where this can happen in the game, but if it happens, you will remain stuck, possibly forever unless you use the power button to trash all your progress and reboot. Would a player feel like starting the game again in such conditions? I don't think so.
 
The thing is, the basis pretty hard to track, a bit tedious to reproduce and all my attempts to fix it have failed ... so far.

What I truly need is a tool that will allow me to identify the sequence of state transitions that led to the offending state when I finally manage to reproduce it. Another debugging tool that would complement Inspector widget for cases that cannot be solved by single-stepping on setting breakpoints.

edit: let's stop rambling, let's start cracking ...

Bug is tedious to reproduce

Then let's make it easier to reproduce. Let's have e.g. a build of the game with much more lives, more hitpoints if needed, that drop you in a place where it is easy to try reproducing the bug. Let's go to that level with the DS, too, and try to get into the wall in as many ways as possible (runMe is neat for that because it let me launch any level), to get a better understanding of the conditions that make it happen.

Moreover, we're running on an emulator, here. And emulator typically have a free save-state mechanism. I'm unsure whether it works flawlessly with desmume, but it's worth giving it a try.


Bug is hard to track

Then let's make our best to get as much information as we can from a succesful run.

Granted, the ideal would be to have a curve plotted, annotated with state changes, in readable colors and where I could get any set of gob variable at any time by just pointing at a spot on the curve. But we don't have that. Granted, last time I had to use both ddd breakpoints and Inspector widget, but that doesn't mean I cannot do better this time.

So the ideal would be a time machine that let me replay things if I ever manage to produce the bug, and view what happened in slow motion, eh ? Wait ... that tool exists already. That tool is ... recording game + Inspector widget as an animation and replaying it!

Bug couldn't be fixed so far.

I thought I knew what happened by looking at the code that makes Verso bounce, because I know I had to fix the problem for Verso (the bouncing eraser). And the solution was to detect the impact's vertical speed to tell ceilings apart from floors, and prevent the 'fail [assuming on the ground]' from happening when what really happened was 'fail [on the ceiling]'.

So after I located something similar with the "HIT" state of Bilou, I thought I got rid of the problem. But since I don't have well-isolated test cases for the state machine (yet), seeing the bug again doesn't mean that the fix wasn't effective: simply that it might not be an isolated case.

To be continued ...

most vexing (gobscript) parse

My scripting language is far from perfect, but this one is really the most vexing issue I have encountered so far. I mean, it is hard to debug, counter-intuitive, and it feels more like a question block turned into a thWomp and smashed you. It gave no clue, no warning, you did nothing wrong, but still get smashed.

The core of the issue lies in how collisions are handled:

• There is always an active "collider" and a passive "collided" object. 
• collider area is allowed to expand to any size (within int size limits). 
• collided area will only be checked if the object's boundary box intersected with the active area.
  

The third constraint comes from performances considerations. But unfortunately, it means if you create a passive area larger than the object's own size, nothing will complain, you will see boxes intersecting, bar no collision will ever occur.

I'll need to take some time to add warnings

Qui est volontaire ?

Je voudrais pouvoir faire une série "tutorielle" pour introduire progressivement les concepts de mon moteur de jeu et fournir une base de travail à d'éventuels game-makers amateurs qui voudraient s'essayer sur DS. Je voudrais aussi qu'ils puissent avoir quelques graphismes de référence, y compris les personnages.

ç'aurait pu être la bestiole de Pipemare (RSD), mais j'ai du mal à me l'approprier. ça ne peut pas être Jack Boost, Badman, Spector, parce qu'ils ne m'appartiennent pas en tant que personnage. Je n'ai pas envie que ce soit Bouli ou Biokid parce que j'y suis trop attaché, alors qui ?

For ten years now, I've been developing a game engine for the Nintendo DS. It isn't perfect but it already allows to do interesting things. And while most of the homebrew we've seen in the golden era of NDS development were using static screen, with GEDS, we have the full power of large maps and parallax scrolling.

Yet so far, I have failed to offer a workable starter kit for the libgeds and dsgametools. Apple Assault source code is mostly obsolete. Discovery packs for LEDS and AnimEDS weren't really helping to kick into game development. And my tilesets are too complicated for a 8-years-old to start sketching levels.

I'd like to take some time to craft something better. A small tileset inspired by Kenneth Fejer mockups. A generic-enough-but-yet-inspiring character that could be sent onto a Commander Keen / Nicky Boom-like adventure.

J'ai envisagé de commencer par un exemple basé sur Out'm'Up, SeaFox ou Crazy Brix, mais aucun n'est vraiment pratique pour montrer ce dont le moteur GEDS est capable (scrolling multi-niveaux, animation modulaire, etc). Non, il me faut une aventure à la Nicky Boom ou Commander Keen.

Reste les personnages secondaires que j'ai développés. Nono le gamin malchanceux (une version anonymisée de Badman, en sorte), Mo le sorcier maladroit, Mol la taupe punk ou Mike Boost, le talentueux mais ténébreux. Ou alors affubler spector d'une tête de souris ?

Rien de complètement convaincant. Reste la possibilité de faire des pixels sur mesure. Voici donc "power kid", qui a l'avantage d'être un perso rigolo.

Of course, given the amount of games I have contributed to together with other PPP Team members, it may sound weird that I'm on a quest for a character to drop to the public domain. The thing is, most of them were designed by other members (Badman, Jack Boost, Biokid) or collectively... or were pastiche of copyrighted characters (Calimero, Xeen, Frogger). My best candidate would be the punk mole I inserted in Badman II and who was playable in my brother's "4 to save Toon Land", althoug -- as you can see from the sketches -- it is definitely not the only option.

Rendez-vous avec la S-Team

Ah. Enfin l'occasion de faire tester mon niveau vertical à la S-Team au grand complet! Et de plus entouré de p'tits n'veux de 8-10 ans qui ont fini par venir s'agglutiner autour de L (la benjamine) tandis qu'elle s'entrainait à aller le plus haut possible dans le niveau final. Les ainés auront eu du mérite puisqu'ils se sont accrochés pour aller jusqu'à la dernière section (rouge) malgré un kolossal bug qui permettait aux pendats de laminer Bilou en un seul contact, faisant fi de ses 5 points de vie ...

A défaut de la photo de famille, donc, un petit aperçu des différentes sections du niveau en question. Mon frangin, hier, avait réussi à frôler le dernier écran et approuvé la difficulté avec la mention "vache, mais pas trop". (il avait atteint le haut de la zone jaune et je l'y ai ré-emmené pour qu'il voit la fin)

Un playtesting bien utile puisqu'il m'a permis d'identifier quelques coins piégeux de la map: images qui font penser qu'il y a une plate-forme alors qu'il n'y a rien, voie à suivre peu claire qui a conduit A (la cadette) à se lancer dans l'encre à plus d'une reprise, trop confiante de la distance que Bilou pourrait parcourir en un saut sans se douter que le bon chemin était en réalité derrière elle. Après 3 ou 4 essais, elle parvient au passage critique "des gommes" (zone jaune) où il faut enchaîner les rebonds avec très peu de "filet". Heureusement, en général, à ce stade-là, on a pris suffisamment d'avance sur l'encre pour pouvoir réessayer quelques fois. Et à mon grand soulagement, elle a passé ça en une seule vie. Ni elle ni L n'aura eu de difficulté avec le duo d'éponges de la section orange (re-ouf).

I got the opportunity to have the final level of School Rush heavily play-tested (at last) and got many small things (and other-not-so-small) fixed. It is always a pleasure to see kids and teenagers challenging each other on my game. I'm impressed they kept doing their best despite I had an awful bug that allowed pendats to one-shot the player almost everytime. Nonetheless, the best trained of the testers managed to climb almost to 3/4th of the final level, beating the "bouncing erasers climbing" part at her first attempt.

Thanks to those playtest, I had fixed some phantom platforms here and there, ensured idle inkjets (those that don't shoot by default, as on the title screen) always notice you when you jump into them, allowed to swim-up to escape the ink even when you don't end up in the final depth of the ink, got the "torchlight feature" rendering correctly ... And before you ask, yes, I took the week off ;-)

Même N. s'y sera réessayé, alors qu'il avait plutôt snobbé Bilou au profit de ses jeux sur smartphone ces dernières années (bah, il a genre 17 ans, l'ainé, maintenant). Un cycle de 3 vies lui aura été nécessaire pour reprendre un peu le jeu en main, mais après ça, il atteignait sans problème la zone verte avec 2 power-up mais n'aura pas poussé jusqu'au jaune, L. insistant pour faire un nouvel essai.

Par contre,

• [done] il faut obligatoirement que je corrige cette histoire d'encrier qui ne se déclenche pas d'office
• [done] il faut obligatoirement que l'on puisse "partir en nageant" même si on arrive sur du sol dur, pas uniquement quand on touche le "fond de l'encre".

.fr ?

Bon, je ne vais pas y aller par quatre chemins: animer ce blog en bilingue devient trop lourd pour moi. Entre le boulot qui me tient beaucoup plus devant un écran, les trajets en tous ssens pour les activités extra-scolaires des loustics, et -- avouons-le -- un laptop moins convaincant dont l'écran n'a jamais la taille qu'il faudrait, je peine déjà à rédiger ce qui me passe en tête quand je gribouille une page de notes sur ma tablette-liseuse-scanneuse.

Alors le faire en deux langues, ça devient vraiment infernal. C'est aussi au détriment du projet lui-même. En théorie, la France arrive toujours en n°2 dans les statistiques. Ai-je encore des lecteurs francophones ? (ai-je encore des lecteurs tout court ?)

N'hésitez pas à vous faire entendre: le sondage "English /Français" court toujours.

Panic! GameInfo reading out of buffer!

Pretty weird error message. I don't know what triggers that. It doesn't interrupt the emulated program but kills the emulator itself, even when we're running in gdb-debugging mode. It happens while parsing some line of text in my "wave.cmd" script unless I invoke GobAnim::setWindowed() on an animation earlier on. The object parsed when the crash occurs has no relationship with the GobAnim that gets windowing-enabled.

• Panic! GameInfo reading 302251 out of ROM (302254)! 
• halting emu: ARM9 PC=020406A0/02000F0B, LR=0204069C 
• ARM9 halted 
• halting emu: ARM7 PC=037F9B84/037F9B7C 
• ARM7 halte

The crashing address happens to be within memcpy.

  break *0x20406a0 if $r3 + $r0 > 0x300000 && $r0 < 0xb000000

could be working, except that GameInfo doesn't start at offset 0, but apparently rather at offset 0x08000000.

A bit more digging (setting the right breakpoint, using one more desmume patch to reveal registers R0 through R3) finally allowed me to get a stack trace....
And the offending memcpy was part of a buffer refill for waves.cmd file. For some reason, by incrementing the size, I hit a threshold where one more copy is needed, but then the very last bytes can't be read because the emulator believe they should always pick a 4 bytes from the current position (instead of an aligned 32-bit word holding the byte). Simply adding a zz.zz file that will come past the waves.cmd file make the code work again.

Finishing steps for School Rush

• [true] ensure the music track for the last level is different
• [done] bring in the amazing books as the background for the final level
• [>>>] make a funny "true ending" sequence
• [done] draw something for the missing loading screen(s?)
• [done] inkjets start aggressive in hard mode
• [wish?] page-swap bonuses as player progress into the levels to m4ke him b3liv3 th3 m4th 4r3 t4king 0v3r th3 w0r1d (originally mentioned here)
• [done] resume the normal level order/spawn points.

And I still don't have vertical movement for floating spongebop.

Yup. No code tonight. Just took some time to crawl through the old "todo" posts and collect a list of things that are still pending. As I can allow less and less time at once on my hobby project these days, I need to organize myself more ...

To be honest, I'm starting to be attracted more and more by things that aren't related to School Rush and less and less by finishing School Rush itself. Possibly because we're approaching a big release at work ... possibly because the Internet seems not to care a lot about the idea of rushing School Rush.

I wanted to temporarily disable the "window" feature on the torch-light GOB (just to check it has the shape it should), but when I do so, I get a cryptic "Panic! GameInfo reading out of buffer!" message from desmume... I'll have to investigate that.

edit:

• [done] With the window disabled, it looks like the OAM flipping isn't working for my torchlight-sprite. I'll have to understand why
• [done] While hacking the get-ready-to-swim fix, it looks like I broke a rule in the Bilou-got-hurt rules, allowing pendats (which are both hurting and solid) to combo-kill you

.

out'm'up

The inscene'99 visit had been quite as success, especially regading the 100K game competition. My brother and I then tried to figure out what we would do on the next instance - obviously, our chance of making a good game were higher than making a big demo like the one envisioned for "samedi, tous in my home".

A comment by my peer "Gedeon" about how it was a shame that crazy brix was only using boxes for collisions pushed me towards the implementation of some pixel-perfect collision routines. I remember I wanted to do some pinball game, but after all, it was decided to go for a shoot-em-up. Our secret "games to do" folder had a long list aborted shmups, from the "Polycosmos" conversion of "space Mission", the failed "cosmowars" on RSD Game-Maker, and the aborted "Bilou sky quest" ... Nothing getting any close to our childhood golden award "Warhawk". So I picked the "Tyrian" palette and started to pixel some ships.

Retournons au passage à l'an 2000. La Inscene '99 avait plutôt été un succès en particulier pour mon jeu 100K, Crazy Brix. Deux choses étaient claires: 1) on y retourne l'an prochain et 2) on a plus de chances de parvenir à refaire un p'tit jeu en 1 an que d'aligner une mégadémo sur le thème "Samedi tous in my home"... Gédéon m'avait motivé à dépasser le simple test de boîtes de collisions pour le prochain titre. ça pourrait convenir pour un pinball ou un shoot-em-up. 

Des shoot'em'up abandonés, j'en ai déjà une belle liste derrière moi, à l'époque: le Space Mission pour C64, la BD impliquant le polycosmos, le "Bilou Sky Quest" annulé par un verre de Franta et le Cosmowars foireux sous Game-Maker. Pourtant j'aime ça quand c'est bien fait. Que ce soit Warhawk ou Tyrian si il y a des étoiles et des barres de vies, je suis partant. Et comme j'avais la palette de couleurs de Tyrian sous la main, justement, je me suis lancé.

The assembly code for crazy Brix was quite horrible, and I remember taking care of increasing the quality of the organisation for out'm'up. Especially, frames-to-aminations, level layout, and to some extent the sprites behaviour were described in a "data-oriented" macros system that looked a bit like game script, but converted straight into binary pointers and values -- something that was apparently common in MegaDrive games development.

The second key development was to support a dynamic list of sprites, allowing fancy explosions, lots of shots and even powerups where crazybrix couldn't even accomodate for anything but a ball and a paddle. Two lists, in fact. This engine was the first time I decided to split objects in two separate casts to reduce the amount of collision checks required.

While the level design wasn't very inspired, the game received a brilliant soundtrack, a classic but good-looking starfield effect and Out'm'Up won the first place - although mostly due to the lack of significant competition.

Même s'il a disposé de 3 fois moins de temps que Crazy Brix, Out'm'Up a eu droit au niveau programmation à tout ce qui faisait défaut à son prédécesseur: des effets d'explosions, des power-ups, des sprites ennemis, des niveaux programmables.

J'avais même une structure 'scriptable' pour permettre à mon frangin de passer au level design une fois le travail sur le son terminé, mais il n'y a jamais montré beaucoup d'intérêt. L'aventure s'arrêtera donc une fois la première place de la Inscene y2k empochée. Ce sera mon dernier projet en VGA + S3M. mon dernier projet MS-DOS.

drop your weapons

One of the most vexing gameplay bug I can think of in School Rush is that you can't enter inkjets when carrying a dumblador. That can easily lead to moments of panic for most reactive players and frustrating death for others.

I now have it fixed, by dropping the requirement of NO_WEAPON when entering inkjets, adding a "THROW" test area when being in the inkjet and ensuring that we DROP_WEAPON if this area ever gets triggered.

C'est probablement un des bugs les plus agaçants de School Rush: impossible d'entrer dans un encrier avec un taille crayon dans les mains (ouais, essayez donc vous-même, vous verrez). En phase de playtesting, ça donne lieu à des moments de panique frustrants pour les joueurs. Je corrige donc en retirant une contrainte sur une transition et en ajoutant un nouvel effet de bord.

What took me a bit too much time to figure out is that the impulse to drop an inkjet must be define as you enter the state with a F_THROW test area, and not on the found-matching-object transition expression (likely because the blador-side of the expression evaluation happens before the bilou-side expression).

OBJ-WINDOW: Look through the ink

The DS video is made of multiple layers -- this should be no news for you. One of the video registers define which of these layers should be shown on screen, but that register also enables and disable a more obscure feature of the NDS: the windows -- that is, the ability to define multiple regions on screen and give them different set of layers to be shown. When the ink raise in School Rush, I'm not simply painting black squares over the scenery: I actually reduce the window through which the scenery can be seen (with a setup where nothing at all can be seen out of that window).

Petit tour d'horizon dans le document "gbatek" pour voir comment fonctionnent les sprites/fenêtres, une petite particularité de la console DS qui permet de basculer entre deux réglages de visibilité des différentes couches graphiques du jeu. Jusque là, je l'utilisais d'une manière assez simpliste pour dessiner l'encre ou les "rideaux" qui ferment la scène à la fin d'un niveau.

Un simple rectangle dans ce cas-là, qui permet de voir toutes les couches à l'intérieur de la fenêtre et aucune à l'extérieur.

The use I have so far of the "window" feature is pretty basic, but a recent talk with Adrian (GBA developer) made me realise that it would be just perfect to allow the game to give us a hint on where Bilou is when he's swimming up the ink to safety. The trick is that some sprites can be used to create another kind of window. Rather than being rectangular, it can have any shape ... and will be much easier to use than reprogramming the size of the window as we get horizontal interrupts amiga-style.

Pour que l'on puisse voir Bilou nager dans l'encre, il me faudrait donc une deuxième configuration qui laisse voir une partie du niveau tout en gardant assez de noir. Il devrait suffire pour ça de changer un simple bit dans la configuration.

J'hésite un peu quand à la manière d'implémenter ça ... Plus précisément, sur la manière d'indiquer depuis les scripts du jeu que l'on souhaite passer un certain sprite dans le mode "fenêtre". L'idéal serait probablement que l'information soit retenue dans les animations elles-même, mais sans nécessiter de modification de AnimEDS.

En même temps, l'utilisation d'AnimEDS n'est nécessaire que si j'essaie de micro-optimiser et d'éviter un sprite 32x32.

There are a few implementation details I'd like to sort out before implementing that. I already figured out that it should be under the responsibility of *Gob + GobAnim classes, the *Gob being the only class that can manipulate OAM entries (including the OBJ_WINDOW_MODE bits) and GobAnim being a natural place to setup flags indicating that "this appearance of the sprite should be a window (or alpha-blended, or rotated)". I might give it a try with a single 32x32 sprite and dedicated "flags xxx" script entry before I go for something more integrated that could replace the Flicker command currently in use by e.g. inkjets... 

edit: got it working. (by Oct. 14th) Some pixels to edit, now.

Thanks, ::Twig

On y est presque. Un mois après l'arrivée du Boox comme remplaçant du Cybook, j'ai réussi à faire un petit script Perl convertissant la sortie de Doxygen pour que le e-pub reader le plus puissant de l'appareil (point de vue navigation) parvienne à afficher correctement les extraits de code. Et ce grâce à l'aide d'un petit module plutôt bien foutu -- XML::Twig -- permettant d'écrire dès règles du style "si tu rencontres
<div class="line">...</div>, remplace par <tt>...</tt>".

Yo! One month later, I finally have a nice Perl script for converting stylesheet-heavy doxygen output for the super-navigating (but style-agnostic) reader application embedded on my Boox device.
The XML::Twig package I used for the job seems pretty powerful -- and much easier to use than XmlStylesheetsTransformationLanguage, as far as I am concerned.

I can't help but dreaming about pushing it further and have blog excerpts integrated with code snippets on an enlightening document that would progressively turns the readers into code writers that would contribute to dsgametools ...

Il serait très tentant d'utiliser ça pour faire aussi un peu de fusion blog/doxygen, d'ailleurs. histoire de reprendre les schémas UML dans le code navigable.

NExt (last?) steps on School Rush

No real "todo item" identified from last week-end' playtesting session, except one funny idea of using a special feature of the NDS' sprite hardware so that we can see Bilou while he's swimming up the ink.

I've got a few other things to do, though. Some editing on the map, some debugging on the inkjets, but mostly, a way to animate what the pipes when Bilou disable them.

Je me suis retrouvé un peu "tout bête" à ne pas avoir de véritable chose à corriger après la petite scéance de playtesting de du week-end dernier. Qu'à celà ne tienne: il y a quelques détails qui restent encore à améliorer sur le dernier niveau, et en particulier faire en sorte de pouvoir animer l'arrêt du flux d'encre quand on rebouche un bouchon. Je pense bien utiliser les polygones: ça fait parfaitement l'affaire. tout ce qu'il me manqu(ait), c'est un bout de code qui dessine un rectangle noir entre deux objets du jeu, et un peu de script pour lier le tout.

So let's go for a new "GobController" that renders some polygons between two objects and don't do anything else. Ideally, the "circular" controller used to swing spongebops could be cleaned of OpenGL instructions and once I'll have a 3D object editor, I'd be able to name which 3D object should be used as the link between any two attached objects. But we're not there yet.

Ce n'est pas franchement le genre de programmation qui fait plaisir: assez bien de copier-coller, pas franchement le bon rôle (c'est un contrôleur, et on fait de l'affichage >_<), etc. Je reviendrai là-dessus quand j'aurai bouclé le jeu et que j'aurai un peu avancé sur mon projet d'éditeur d'objets 3D sur la DS.

Ah oui. Il y a un autre élément qui serait sympa: faire en sorte qu'on puisse voir Bilou nager hors de l'encre. Point de vue technique, j'ai ma petite idée, mais ce n'est franchement pas prioritaire.

edit: good news, if you want an invisible sprite for some reason, you don't have to devote another blank tile for that. Just 'naming' an empty slot of any SpritePage will do. For some reason ... which I'll have to understand ^^"

Ink pit : play-tested

J'ai eu l'occasion de faire tester le niveau vertical de "school rush" à L., 11 ans maintenant et qui essaie maintenant occasionnellement les niveaux de Bilou depuis 2009 2013. La fonctionnalité-clé est validée: "j'aime bien qu'on puisse nager pour ressortir de l'encre", affirme-t'elle, alors qu'en pratique, elle n'aura réussi que quelques fois à se tirer du mauvais pas, et généralement si affaiblie (enfin, Bilou, hein. Pas ma testeuse) qu'elle n'ira guère qu'un ou deux écrans plus loin.

L./S-team is 11 years old now. She's been play-testing School Rush since 2013 and she just validated a new mechanics I added to the game: "I like it that I can swim out of the ink, now". In practice, it only saved "her" (well, actually Bilou) a couple of time, and usually so weak that she can barely go a few screen further before re-starting. But the psychological effect is there: she keeps playing that vertical level, keeps improving so that she frequently reaches 1/4th of the level and 1/3rd from times to times. Quite an achievement for me too, given that she initially played in "easy mode" only, and did not really bother to reach any goal but the one she set for herself.

Mais l'effet psychologique prend. Elle s'accroche et s'améliore peu à peu, jusqu'à atteindre régulièrement 1/4 du niveau et occasionnellement 1/3. Au-delà, les choses se corsent et il faut régulièrement courir pour franchir les sauts, ce que L. ne maîtrise pas encore véritablement.

Celà dit, comparé au jeune premier, L. a immédiatement senti l'urgence de l'encre qui monte, remarqué qu'il fallait se méfier des encriers endormis et qu'en sautant un petit coup supplémentaire une fois arrivé dedans on les réveillait (oui, c'est un vrai bug que je dois corriger, pas un choix de gameplay douteux), repéré les horizontales dans les les livres et les utiliser comme plate-formes, etc.

A younger cousin of L. did try the game as well, but unlike her, he didn't seem to get any feeling of emergency from the raising ink. L. also noted how a small jump can prevent an inkjet from keeping asleep (a true bug I still have to fix) and she is now super-fast at spotting those horizontal "decoration" on books that can actually be used as platforms.

Come back from the ink ?

Bon, entre les programmes d'activité des loupiots qui grandissent, les centrales vapeur qui tombent en panne et les interventions de réparation dans la maison, je me prends une petite paire d'heure pour essayer de corriger un couac avec le passage à un niveau vertical dans "School Rush": s'assurer que le jeu relance bien le niveau si l'encre nous rattrape.

Je dois  notamment éviter que Bilou ne puisse rester indéfiniment dans un encrier sous l'encre. Etre invulnérable dans l'encrier, ok, mais pas retomber immédiatement dedans quand il nous projette jusqu'à la fin de la batterie.

It is time to check what the vertical level looks like when we add rising ink in the mix. And the first tests show that there's quite some tuning required. The first mis-steps that my last playtester did led Bilou to be stuck in the ink, invulnerable, but also unable to keep on playing. One of them involved cycling between in-inkjet and hit.

I'm trying to make the state machine detect that we're in the ink and switch to a "swim up" state that would give the player a chance to get out. This is possible because ink has an additional flag that makes it possibly different from a regular hazard. All the engine requires is that the test on "hurts and is ink" precedes the test on just "hurts".

Se faire projeter par l'encrier, c'est "$HJUMP". L'encre, c'est à la fois F_HIT (blesse Bilou) et F_ISINK (fait flotter les éponges). Une réaction "normale" pour le personnage qui tombe dans l'encre serait d'essayer de nager pour en sortir. En particulier s'il atteint quelque-chose qui peut le propulser hors de l'encre. Ce sera "$SWIM", dans lequel on est insensible à l'encre mais qui repasse faire un test périodiquement et continue donc à consommer des points de vie tant qu'on est dans l'encre.

Il faudra aussi que je complète ce "swim" lorsque Bilou arrive hors de l'encre.

Doxygen on Onyx

I don't exactly know what I have changed, but using the "Neo Reader" application on the Boox today, my doxygen-to-epub-through-calibre file now renders as expected. I thought that could be linked to the disabling of "cache reflow bitmap" cryptic option in the advanced settings (see the small icon pointed by the stylus on the picture), but re-enabling it doesn't change anything (or it only has an effect when restarting the application ?)

Qu'est-ce que j'ai changé ? Je n'en sais plus trop rien. J'ai "torturé" le morceau de code qui apparaissait dans la version e-pub de mon blog pour essayer de trouver ce qui faisait la différence entre un rendu correct (white-space: pre-wrap ? utilisation de
<pre>plutôt que <div>? de <tt> plutôt que <span>?

Rien n'a semblé avoir d'effet. Puis ce midi, en jetant un coup d'oeil à mon code converti par doxygen et calibre, surprise! tout est impecablement rendu.

Plus de numéro de lignes indésirables, changements de polices, traitement correct des espaces ... tout y est.

Est-ce que ça vient du réglage "cache reflow bitmap" que j'avais changé ? difficile à dire. Le désactiver ne semble pas avoir d'effet immédiat, mais ils auraient pu omettre de dire qu'il fallait redémarrer l'application ...

One major drawback, though: Neo Reader application is the only one for which I find no way to hop back to the place I was before following a link in the epub document. And that will make navigation extremely annoying, I'm afraid.
Neo Reader v2.0 had nice backtracking feature, and that one gets interesting behaviour on my test epub document.

• When using <span> or <div> with the CSS classes associated with working 'code-style' elements, nothing happens
• When using <pre> or <tt> with the same elements, code is rendered as it should (as printed on dot-matrix ;-)
• The style applied to "English section" (using <en>) doesn't go italic, while emphasis directly using <i> in the French part goes italic.
• skipping CSS classes altogether has no impact (given that you're using
  
  pre/tt tags)
• embedding the whole stuff in "blockquote" doesn't seem to have much effect
• trying to use tables with colspan and some cells containing only a few whitespaces failed miserably. I think all cells are just sitting in a vertical list, not laid out on a table at all. 

Sketching on Boox

La première prise en main de l'application "prise de notes" de mon nouvel Onyx Boox n'avait pas franchement été convainquante... arrêter son traît au bon endroit, viser un emplacement avec le stylet ... tout ça est plus complexe que ça ne le devrait. La faute à mon avis à l'absence de compensation de l'inclinaison du stylet.

Starting to draw with my "Boox" was a bit disappointing. Whatever I could try with stylus calibration, there was still a significant offset between the contact point of the stylus tip and the actual drawing point. I bet better tilting support in the software (or hardware?) would have avoided that, but that's not something I can improve. Hard to stop at the right place on a rectangle's corner. Harder to make a circle (or whatever else) at a precise spot ... and almost impossible to make an arrow >_<

Du coup, quoi qu'on fasse avec la fonction "calibrage", le point de contact du stylet avec la surface et le point où l'encre change de couleur ne coïncide pas.

Difficile du coup de faire de beaux rectangles ou  (encore plus ennuyeux) des flèches. Difficile aussi de dessiner des p'tits Bilous dans le coin d'une explication. Ou de faire du dessin type "ligne claire".

I usually love to have small Bilou / Bouli talking and illustrating a technical chat... That will be difficult to do here. It usually requires to draw at small scale, a single line, Tintin-style. And that works terribly bad with the imprecisions of the Boox "Notes" application. 
 
But hopefully, lining up multiple lines and writing works naturally well. 

The good news, however, is that if I'm just sketching at a scale of 5-7 cm, striking over again and again to make the lines more defined gives some quite interesting results. Not really suitable for artwork either, but creating quite acceptable sketches.

Par contre, le style "repasser sur les lignes, plus nerveux, plus "esquisse" ne donne pas trop mal.

edit: for those who're curious about it, Onyx documents its scrible interface on github.

I got a Boox

J'ai reçu mon nouveau gadget à base d'encre électronique, donc. Même si au prix où il était, j'espère qu'il sera plus proche d'un ordi que d'un gadget, évidemment. Il s'agit d'un Onyx Boox 9.6" combinant un stylet magnétique et un écran capacitif.

I jumped completely out of my comfort zone and ordered online a device I never had in hands before at a price well over that of a Nintendo DS: the Onyx Boox N96, combining magnetic stylus (afaik), capacitive screen and e-ink display for roughly the size of a A5 sketchpad.

Malgré une boîte tout-en-chinois un peu intimidante, l'appareil a des menus en bon Anglais et la prise en main s'est faite assez facilement. Ma grande inquiétude, évidemment, c'était de savoir si je pourrai m'en servir pour mes documents "doxygen" si utile pour faire du développement intermittent.

The device feels right in hand, is quite a hybrid between an androïd tablet (unfortunately only 4.0, making applications for twitter, picasa and blogger unusable >_<), but what was really stressing me was to know whether I could use it for epub+doxygen code browsing I've been usiing sooo much for the last years to progress on my pet projects. And unfortunately, out of the 4 embedded readers, none of them got the layout right. No indentation, useless line numbers, incoherent spacing ... all of the issues I had fixed earlier this summer -- and some I never heard of before -- were back to haunt me.

Ce n'est pas gagné: sur les quatre lecteurs e-pubs embarqué, aucun n'a un système "styles de l'éditeur" comme mon regretté Cybook. Et sur chacun d'eux, le code produit a tous les défauts d'une mauvaise conversion: pas d'indentation, numéro de ligne inutiles, tailles incohérentes, etc.

J'avais compté sur l'installation de FBReader, testé avec succès sur la tablette de ma fée, mais c'était compter sans une dernière roublardise d'androïd: Il y a en réalité une version plus ancienne de FBReader dans le pack d'applications préinstallées, ce qui m'empèche d'installer une version plus récente pour cause d'erreur -104. (j'aurai peut-être plus de chances après une recompilation ?)

My plan was to use the open-source FBReader if such thing occured, but unfortunately, I couldn't install it from Google Play: interference between the pre-installed FBReader (older version) in the firmware makes it fail with error -104.

I was hesitating between sending it back and switching to some pure html-based doxygen crawling when a post in one of my blog-on-epub conversion caught my attention.

Bref, je m'apprétais à devoir me rabattre sur une utilisation de pages webs moins pratiques (pas d'annotations, pas de marqueur 'vous êtes ici' d'une lecture à l'autre, etc.) lorsqu'au détour d'un post de ce blog converti en fichier e-pub, je constate que l'un des lecteurs par défaut (je ne me souviens pas duquel il s'agit :P) que les styles sont tout à fais satisfaisants pour mes besoins:

• le bloc de code est en police monospace alors que le texte du post est en police classique,
• les indentations ont fonctionné correctement,
• (bin y'a pas denuméro de ligne, forcément, vu que je n'en ai pas mis. Haha.)

Le jeu, ça va être maintenant de comprendre la différence entre ce bloc-là et ce que j'avais dans mon document doxygen pour faire des doxygens qui marchent mieux.

See ? It's all there. Indentation, font switching... The CSS reading is there. The rendering works. It's all a matter of making the doxygen stuff damn simple enough so that it couldn't possibly fail. That's something I can handle. The boox may stay here.

mayfreeze = false

Voilà: le niveau vertical est pour ainsi dire fini. Du moins pour ce qui est des décors. Maintenant, je vais devoir passer un peu de temps à faire les réglages pour l'encre-qui-monte. La bonne nouvelle, c'est que la technique qui évite que l'encre s'arrête de monter quand elle sort de l'écran est déjà opérationnelle depuis Juillet.

It's now time to make sure the vertical level get rising ink, too. And this time, I need to take extra care that the objects that control the ink level will never got "frozen" when going too far away from the camera. That was hopefully available since early July.

Un peu plus délicat: s'assurer que Bilou se "noie" toujours dans l'encre malgré le fait qu'il puisse parfois tomber de plusieurs écrans avant d'être arrêté (et la zone de collision de l'encre ne va pas jusque là).

Another thing that I'll have to take care of, is that Bilou don't go too deep into the ink. Without it, we can quite easily have Bilou fall down so low that he'll go out of the "hit player" box ... and player will have to find some other way to hurt himself (while seeing nothing but a black screen) to be granted another attempt.

Je vais devoir ajuster un peu les encriers -- et en particulier éviter que Bilou ne soit totalement à l'abri à l'intérieur d'un encrier -- faute de quoi il pourrait très bien y rester bloqué indéfiniment. Et enfin, il faudra trouver la bonne vitesse pour la montée de l'encre, parce que là, j'arrive en haut du niveau avec 6 bonnes minutes d'avance. De préférence sans trop "tricher".

One last thing: I cannot keep the rule that "being within an inkjet = being immune to ink" as with the 4 previous levels, because then you'll be stuck in your inkjet forever.

And then, I'll need some tuning on the ink speed itself. Right now (60*32/256px/sec), I can climb up the level and I'd have to wait for over 6 minutes before the ink can catch me back.

If I let the ink almost reach me when I'm about to go through the last "room", though, I'm only some 40 seconds ahead at the top -- which is still quite a lot.