If I want to have an understanding of what causes Bilou to get into walls when he arrives straight into it, I need to find a way to reproduce that at will. I have to update my unit tests to cover that new scenario.
The difficulty with that setup is that the mecha will have to keep walking towards the wall for some frames, and only then try to turn back. Scripting a fake game pad controller to force the mecha to do that sure won't be the easiest path to follow. But I have a plan.
Si je veux comprendre ce qui conduit Bilou à finir dans les murs, il faut que je trouve un moyen de reproduire ça à volonté, c'est à dire reconstruire un setup dans l'environnement de tests "unitaires" que je me suis construit. Sans ne sera pas élémentaire, parce qu'il va falloir faire en sorte d'imiter le comportement d'un joueur qui continuerait d'avancer vers le mur avant de faire demi-tour, mais j'ai ma petite idée... Introduire un 2eme "mecha" qui marche normalement sur un terrain plus large et faire en sorte que notre sujet-test suive sa position de la même manière qu'une des chauve-souris-baie, sauf qu'il marche. Séduisant, non?
Let's have a second mecha that is walking "normally" on one large floor while another one, the Gob-Under-Test is tracking its position and tries to follow it, just like Berry Bats would do, except "walking". That should work, right ?
Well, reality is hitting me hard, here. I haven't managed to get the test cycle work properly. I'm caught in the process of navigating the history and running because even with the obvious sorted out, my new test gets a "memory is leaking" warning and the former 'slopes' test isn't working either.
ça, c'est en Théorie. Mais une fois la frontière avec la Réalité franchie on se prend une jolie douche froide, sous forme de fuite mémoire dans le module de tests. Puis c'est le test sur les pentes qui ne passe plus. Et comme je n'ai pas encore commencé à utiliser la branche "default" comme "ok, tous les tests passent", je suis bon pour quelques retours vers le futur à bord de Mercurial. Je vous fais grâce des Makefile qui ne détectent pas les changement de version du toolkit et des fichiers .cmd qui ne sont reconstruit que dans certaines conditions, mais j'ai fini par trouver le commit qui plombe l'ambiance.
I think from now on, I'll use the 'default' branch as a way to track what is properly passing automated tests and what isn't. Good news, commit 6ab9f8ca2931 dating from this year (April 13rd) pass the slopes tests.
Caveats when doing things like this:
- Makefile does not detect whether I change devkitpro version, so things that used to work years ago on an older devkit may fail to build nowadays and you'll have to manually clean output/*.o
- some tests depend on fakreoot/*.cmd, which is not automatically re-populated from SchoolTests/efsroot/ or AppleAssault/efsroot/. and in SchoolTests, the files are generated from SchoolTest/cmd/, which does not occur if you just rebuild unit tests.
| 1873 | 1874 |
 |  |
edit: I identified a commit at which the TestBasicSlopes started failing. Surprisingly, it was not a side-effect or whatever: the commit directly does
if ((cspeed&cp) && !cdata[0]) continue;// this testpoint only works with speed
- if ((chkflr&cp) && !(checks[pos] & F_FLOOR)) {
+ if ((chkflr&cp) && (checks[pos] & F_FALLTHRU)) {
if (isi) isi->TestPoint(xtile, ytile, pos, checks[pos], "floor");
cdata[GOB_TESTPOINTS]|=cp;
}
Which cannot have no effect on how testpoints behave in the slope tests. But if we compare how monsters in the green zone behave before (1873) and after (1874) this commit, it is clear that it has desirable effects. So I'm now sure I have to fix the tests, not the way testpoints are handled.
Je m'attendais à une sorte d'effet de bord, résultant malencontreusement d'une modification qui n'aurait rien à voir, mais non. Ce commit modifie directement l'interprétation que le moteur de jeu a du concept de "sol". Jusqu'à 1873, pour être du sol, il fallait avoir la propriété "FLOOR". Depuis 1874, il suffit qu'on ne puisse pas tomber à travers une surface pour qu'elle soit considérée comme sol.
edit++: okay. The leaking object was a 'builder' helper used by the GobState objets. The builder is a std::* object temporarily used while e.g. collecting transitions from a given state before they got 'flattened' into an array for the 'running' part. The array, just like GobStates are allocated in the 'tank', a larger memory chunk meant to host many small objects that all have the same lifetime: one level.
Ah, et pour les plus curieux, j'ai trouvé la fuite de mémoire. ça se passait dans le code qui accumule les informations sur la machine d'état avant de les "geler" dans un brave tableau de taille fixe. Sauf que ce gel est lié à l'introduction de transitions entre les états et que les tests qui fuitaient sont "tellement simples" qu'il n'y a pas de transition: juste un état unique dans lequel le sujet-test reste du début à la fin. Au travail.
In the 'slope' tests, each state was used to spawn a GameObject using that state for the test. There were no transitions: we first use a forward-moving mecha to check things are fine when moving forward with the Forward state, and then a distinct backwards-moving-mecha. But for my new test, I need transitions. That means that I won't spawn for every states. That means some states are not 'frozen' into the tank, and hence still hold references to std::* objects like vectors or strings. These are the leaking ones. Let's get cracking!
Since last week, I've been tweaking the state machine of my meka-tester trying to make it better mimmic the behaviour of Bilou when it gets into the walls. I finally get the kind of error I wanted, but it makes little sense. 
- + 
Vote for your favourite post
