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".