Testing landing-on-slope

 

While reviewing the "tiled" chapter produced by my blogpress tools, I remembered that landing on a slope still produces odd effects from time to time. And then came an idea to reproduce these conditions in the unit-test environment.

Just as I was observing that the "dkp54" branch has been around from a long time and so has been the "cflags" branch and that "right, I promised myself I wouldn't merge things unless I've first checked they still pass automated tests."

And unfortunately, right then, the tests were not passing, they were crashing. First with an exception and then with a segmentation fault. The "offending" commit was something from 2025, a few lines that will report (rather than ignore) syntax errors within the GobState parsing.

It took some times to identify where the error was introduced, much less to fix it (hopefully) and so the 'dkp' branch (toolkit update) is now finally merged and the cflags can be just that: a branch propagating the new collision mechanism (and not a adventurous combination of features).

Les todos du printemps

Toujours en mode "post-desktop". Toujours avec mes carnets qui me servent entre-autres à suivre la progression (lente mais présente) du projet "dreamland". Tout le jeu, avec ce genre de carnet, c'est d'arriver à conserver facilement accessible les choses qui sont encore pertinentes. Souvent, ça passe par un coin de feuille sur lequel je vais me faire une espèce de petit index illustré des pages sur lesquelles j'ai encore des cases de "todo" à cocher ... régulièrement quand la dernière page de ce genre a perdu son statut de "priorité absolue".

Working without a desktop ... without a central unit where your project has its home and grows ... it has slowed me down for years until I opted for making the new home for my project to be made of paper instead. But that means I need to dig older contents into newer pages on a regular basis. And part of the solution for me was that this notebook hosts everything I need to keep track of.

A trick I've started using lately was to make visual/graphical table-of-contents towards past pages, in this case, all the pages where I have "TODO" items still pending, like a small mushroom getting hit by an apple to remind of the todo-state-machine that guided me through latest screenshot saturdays 

C'est évidemment la page 61 qui a ramassé le plus de cochettes ces temps-ci, avec les interactions autour de Funghi et les Applemen, au point qu'il a même eu droit à sa petite barre de progression.

D'autres points avaient été relevés lors du feuilletage et vont se retrouver grisés: ils ne sont pas utiles pour proposer une "première démo" de Dreamland. C'est le cas pour les ajouts juteux autour du poing-écrabouilleur de la pyramide. Oui, ce serait plus sympa qu'il fasse de la poussière, qu'il fasse trembler l'écran etc. mais on peut très bien tester le jeu sans rien de tout ça.

There are a good number of the other todo items that are linked to water interactions and swimming but that's no big surprise: water and swimming have been added over the previous year to an engine that was unable to handle that before, so there are plenty of little things left to tune or fix.

Once I was done with that first sweep, I tried to rationalize: I'd like to be able to let people play the game as early as I manage, and many of the todo items, while valid, aren't needed before people play. Sure, big smashing punch looks better if it triggers clouds of dust and shakes the screen as it smashes into the ground, but none of this is a blocking point if it's missing ... that's why the punch "icon" is greyed out. 

Si la page d'index visuel correspond à un moment-détente, comme certain(e)s feraient des mandalas, il y a aussi des petites notes beaucoup plus gribouillée sur des choses à corriger saisies au vol pendant que l'un ou l'autre essaye le jeu. Mon frère est particulièrement redoutable à ce numéro-là. Mettez lui un de mes programmes entre les mains et il va vous le soft-locker ou pire en moins de 2. Il aura fallu pas loin de 3 reboots pour qu'il puisse lancer une pomme sur Funghi le week-end dernier ^^".

Et comme vous pouvez le voir, c'est beaucoup autour de l'eau que j'ai pris du retard. 

And yeah, many of the items in those sub-page are less eye-candy than the index. Many of them are on-the-fly sketches of something my brother or my son or someone encountered while testing the latest version on my NintendoDS. Sometimes they are summaries of other TODO items grouped according to the tools/energy I'll need to tackle them. I can't really setup WiFi transfers through my NUC-cube while the dinner is cooking. I won't have my blog at hand to remember me what I wanted to draw on the NDS once I'll be in a no-WiFi zone with my DS around. I'd better focus on editing code once I'll be in the good setup to edit some code, etc.

Il m'arrive aussi de temps en temps de faire une version structurée différemment de ces todo-index, où je re-trie les check-box en fonction de ce qu'il va me falloir comme matériel pour avancer: la DS elle-même, le laptop, le "cube", un moment WiFi ... 

L'idée est d'essayer de mieux grappiller les moments disponibles et ne pas retomber sur "ah oui, il faudrait faire ça ... ah mais non, il faudrait d'abord que je mette à jour Bilou.cmd et je n'ai que la DS" quand j'ai une petite demie-heure qui se dégage.

Et forcément, c'est dans ces moments-là qu'arrive une idée du genre "mais oui! faire des ricochets sur l'eau avec les pommes!" ou "les chauve-souris cessent de vous pourchasser si elles rencontrent de l'eau (façon essaim d'abeilles Disney ;-) 

And of course, I have to accommodate for the fact that ideas pop up when they feel it, not when I'm in front of a nice blank page on which a big title has just been polished :P

edit: for the next week-end, analysis and preparation happened thanks to the cube serving the repository over WiFi to the boox sketchpad and then coding happened early in the morning, outdoor in the Virtual Machine of That Other Laptop (better battery, awful keyboard) through sshfs as the files and compiler were hosted on the cube too but the emulator ran within the laptop. At least, the 1st half-hour session was outdoor then the rest was coded on the "dining" table next to the coolness dispenser. That allowed me to have 3 items done (that's completing the page 61) and 2 screenshot saturday released :P      

That fist goes SMASHing

It took me about 30 minutes to finally craft the script needed to bring in the smashing fist I had drawn back in February. I'm a bit sorry that it took me so many month to finally be ready to write that script. Part of it because I had not given it any priority over applemen or sliding water, but mostly because finding some time for doing homebrew is more and more complicated, unfortunately ^^".

(screenshot saturday on mastodon and bsky) 

Similarly to what happened with the rolling appleman, having the bare functionality is just unlocking many other things to do to get it satisfying, like having dust clouds when it hits the ground of having some screen shaking. 

Voià. J'ai enfin transféré les pixels du gros poing écrabouilleur et j'ai même trouvé 2x15 minutes pendant cette semaine de folie pour écrire le script qui le fait monter et descendre. En deux fois parce que le laptop ne tient plus 30 minutes d'affilée. Ça débloque une belle quantité de trucs à faire, mais si vous voulez bien, je vais déjà essayer de comprendre pourquoi je n'ai plus d'électricité depuis le 30 et essayer de faire réparer la chaudière qui n'a pas aimé ça.

• [done] adjust layer priority so that smashers hide in walls
• [todo] shake the screen when hitting the ground
• [todo] shoots clouds of dusts when hitting the ground
• [todo] get a green pillar following them. That could be a 3D item

and well, surprisingly enough I hadn't yet a way to change the layer order. That shall be bit $2000 of the flicker-control word (defined through GobExpression opcode F since bit $8000 already controls whether the given GOB should appear in front of every other GOBs of the same layer (used e.g. by "weapons" you throws)

Petite mise à jour parce que j'ai ajouté 2 autres smashers côte à côte pour voir un peu ce qu'ils donnent dans une configuration "défense de couloir". 

appleman 2.0.1

A little bit of work on the Appleman last week-end (at last, you could add and I wouldn't blame you). I've got the "shocked" animation revised, added "carried" animations and gathered infos about where these are in green.spr.

I'll still need to see why there is no "bounce" when it is shocked (reason: it's just using stopper and the animation is supposed to do the job) and patch the greent.cmd level script on the SD card of DarkneSs, because it still show the appleman with big purple punches instead of feet. (appleman.cmd must be correct, since level 2 doesn't seem to have any similar issue).

Voilà donc enfin le moment que je prends pour compléter les animations et le comportement de l'Appleman pour le projet Dreamland. J'ai corrigé l'animation "étonné", j'ai ajouté les animations "transporté", tout ça attend dans un petit fichier green.spr le prochain passage du WiFi. Je note au passage que le fichier "greent.cmd" qui décrit le premier niveau des "3 salles" a besoin d'un petit rectificatif pour ne plus me montrer un appleman aux poings mauves ^^".

La prochaine étape sera d'ajouter les animations des "pieds perdus". J'ai aussi retiré la commande de boucle pour l'animation "assommé", mais j'arrive trop tard: c'était bon pour compléter le comportement "Apple Assault" où les applemen se réveillent seuls, mais c'est inutile pour le comportement construit à partir du fichier "blador.cmd". Car oui, le nouvel appleman est plus ou moins la fusion des deux.

So let's add tonight "undead feet" animations, check a "do not loop stunned animation" that must be over 1 year old in my notebook. I've got another notebook where I've written down blador's behaviour ... let's merge that into appleman's script and we'll cleanup the resulting code mess once the home mess is tidied up.

edit: adding the wandering feet turned out extremely annoying. They're one-sprite objects, unlike most of the things I animate with AnimEDS, and it seems the software still handle that in a very different manner: touching an sprite in the side panel adds a frame with that item, rather than changing the current frame. It also breaks relationship between timeline, frame editor and buttons in general. I'll have to get that fixed: it really breaks the user experience...

edit': pick up works, stun works, wandering feet work. Apple/water interaction is a catastrophy, throwing only work from times to times, and there's something odd when you stomp on a stunned apple (blador acted as a platform there, appleman won't). That feels like it should roll instead ... A good thing animation 2.0 freed some frames ;)
 

I want to try your editors so much!

How could I resist to such a quote ?

Adeline Venture (hehe) in Shadow Of The Temple The puzzle platformer I really, really want to make some day.

I want to try your editors so much! But in order to finish, I will have to do it in an engine I already know well. Probably construct3 -- CastPixel

It made me want to pack a set of my dsgametools with contents of Castpixel's mockup pre-digested into a .spr file so that she could directly toy with the level editor ... perhaps also convert the tutogit scripts so that she'd get something playable!

So first thing to know is that SEDS works with 16x16 blocks. There is a perl script that can convert the mock-up into tiles but if used directly, it will be a complete mess as game assets.

1. 
   ensure things are aligned on the 16x16 grid as much as possible. That means the ladder half-way over pillar must be shifted. A few other things needs similar shifting on the mockup.
2. SEDS shows you 64-pixels slices at once. The scripts *can* handle wider pictures, but at the moment, they'll scan e.g. first row of 256x16 pixels and output 4 64x16 rows in the first page, then another 4x64x16 chunk etc. The result is barely usable, again, because many objects bigger than 16x16 will be de-aligned and will need to be re-aligned in the DS editor.
   
3. So instead, you may want to turn the mockup into a 64x* image where things are where you want. Todo: imlib2spr.pl should be able to scan the image in 64px-wide columns itself, so that this step becomes useless and the mockup remains readable.
   
4. The script may remove the background color, but when it does so, it also deletes fully background blocks from the output file. This is nice to avoid redundant data, but again, it screws up alignment on such a mockup. You can scribble something on those blocks or you may turn off the background color by giving another one with --bgcolor=ff00ff. Todo: have the imlib2spr.pl tool inject empty slots on the sprite page when it encounters such full-background blocks, to preserve alignment
5. B u t if I use --bgcolor=some-color, the tool will inject a fully-transparent block as block 0. This is required for proper operation of the game engine and the level editor, but this is useless on the sprite pages. And worse, having block 0 editable led to corrupted files in the past. todo: patch the tool so that the empty block is never used by the generated pages (and never allocated by the editor :P)

With all that taken into account, with a 64x* png file with the content of the mockup aligned on a 16x16 grid as often as possible, conversion is performed with 

SpriteEditor/bin/imlib2spr.pl cast-a-venture2.png venture.spr --nomap --nopack --blocksize=16

And the reverse operation to see how things went is

SpriteEditor/bin/spr2png.pl venture.spr /tmp/venture.png && display /tmp/venture.png

Once that looks fine, copy the venture.spr file on your SD card in the /moving/ directory, make sure you have SpriteEditor for DS at the root of your SD card and launch it.

• once launched, press START to enter the FILE screen
• click the |/_/ browse button to show the contents of /moving/
  
• if venture.spr doesn't show up, hold L trigger and touch the "UV" button on the alphapad to filter the list of files. (holding L lets you enter the second letter of each "button").
• touch the "venture.spr" name to load the file, then press START again to return to the edition grid.

 

Dreamland checkpoint

"I can roughly work 1 maybe 2 days on Bilou every time the kids have holidays" was my answer to my step-brother when he asked whether I was still working on my game. So where are we (compared to 2024) ? 

Let's check some boxes, to see that. Note how I realised that I shouldn't try to include that level with 3D books : that would require new tools development and we're now past that kind of change.

Some of the box have been shifted from cyan to green: that means they're still things that will require more significant work to be done, but they're not *mandatory* for a first playable version of the level they're featured in.

And I just read a note I made to my today's self: 

There'd be some fixing on the old maps, possibly some keys or switches by NPCs, but that shouldn't be as ambitious as The Big Green Zone Relooking I've been talking about 3 years ago. The aim would rather to make the game more fun to play, and clearly not to get rid of any magic door.

The geyser thing is almost a "big relooking" thing... "push and flood the level" clearly was. It shouldn't stop me from trying the level.

Hanging around in the ICE ...

Good thing with the German express trains is that they provide unlimited power and some WiFi. Your trip might not go as you expected, but at least you've got time to sit, think and check your code base to plan what you'll do in your homebrew project afterwards.

Among those "what's next", some are already done now, like "converting furblock to treebump"... which it did not need after all.

For some time, I have this little note in my notebook... Because many of the levels in the design book expect that we could hook and hang to some objects. I'd like it to be stylish, with swinging animation and all. But for the purpose of testing the levels and trying the game, just snapping to the hook and waiting for the player to press JUMP or leave would do the trick.

The train-idea here is for the step just after that bare proof-of-concept: I already have a "radius" controller that keep a character within a given range of a "pin point". Being hung could use that controller rather than being snapped to a static position. 

To do so, we can shoot a new game object, Bilou's hand(s), that will snap to the hook and use that as a pin point for the swing. That means we'll have to hide bilou's hands on the existing hero game object (like we do when he's carrying something) ... or just don't draw the hand at all, and reuse its OAM slot to draw Bilou's eyes separately from his body, meaning we'd gain one extra freedom degree for the animation, and wouldn't have to draw a dedicated body-and-eye sprite for every angle.

Then I started brainstorming about the croc-platform: I'm not satisfied with its current look. I dug some real egypt crocodile pictures (and real statues pictures). I toyed with the idea of having the crocodile head showing sideways rather than front view -- that would have meant it wouldn't stop sands when flapped anymore ... The blue book said it wouldn't harm that much.

But I couldn't convince myself it would work either. When the crocform#1 flaps down, it completely cease to interact with characters. A sideways crocodile head flapping down by 90° wouldn't "disappear" that way. It would still be in Bilou's way, mostly as a small wall, but it should still be possible to stand on the rear of its neck ...

A few spots in the ongoing level design would work fine with crocform#2 repurposed, but in other spot, it would mean throwing the player into spikes, rather than just let them fall down...

And then I thought about a type of object in New Super Mario Bros that would behave quite like what I need for my collapsing platform, and it meant I wouldn't even need to drop the "shut the sand door" idea:

How long before we play ?

Somebody asked The Question: how long before we can play the game (presumably Dreamland). So I picked my secret blue notebook and for every level, I tried to identify what I'm still missing to let you play it. Each of the checkboxes cost about 1 month of hobby time. maybe. I won't try being a project manager here. Not during hobby time. Oh, and blue boxes cost more. Possibly up to 3 months.

Je n'ai pas vraiment envie de jouer au gestionnaire de projet pendant mes temps libres. Mais voilà, la question a été posée: "dans combien de temps est-ce qu'on pourra jouer" (à Bilou Dreamland, je présume). Alors j'ai repris mon cahier bleu, celui des secrets, des niveaux et des idées de gamedesign. Et pour chaque niveau déjà esquissé, j'ai fait l'inventaire de ce qui me manquait déjà. Pour les 3 premiers mondes prévus pour le jeu. Je n'ai encore aucun niveau pour le 4eme (ni aucun pixel, d'ailleurs). Chaque case à cocher sur cette map géante, c'est probablement 1 mois de hobby. Probablement 3 pour les cases rehaussées de bleu. Faites le compte ;-)

edit: avant la prochaine démo,

• [done] faliciter la sortie de l'eau
• [done] animer les chutes et les pentes de sable
• [done] Appleman en CompoundGob
• annoncer la démo aussi sur #retrodev, la communauté francophone de Fei, Kannagi, Banshaku et les autres.
  

Mais la bonne nouvelle, c'est que certaines de ces cases ne sont pas indispensables pour avoir une version "jouable", c'est à dire où on puisse atteindre la fin des niveaux. Les PNJ, par exemple, sont supposés être optionnels tout comme Yoshi était optionnel. Parfois, une substitution par un élément déjà existant pourrait s'envisager. Certains niveaux de la school zone seraient mieux avec des lattes en guise de tremplin, mais déjà jouables en utilisant les gommes rebondissantes de School Rush, etc.

DS Ram Leakage in TestNScripts

I had thought that fixing 'slope unit-tests' in addition to 'wall unit tests' would mean my fixes to get the scorpeye behaving as intended. That would mean the 'summer code review' would be over and the 'summer game dev' could start. Well, that was hoping too much, because there's actually one more test that, for some reason, doesn't show up in ./testme --list but still exists and is important: TestNScripts. This one loads the real .cmd files of SchoolRush and checks parsing went fine. And it does not only check one of them: it will reload many scripts in the same "engine", the way the game does.

while (ntests < n) {
   TestBench tc;
   for (uint i=0; i < REDO; i++) {
       printf("== R%i/%i redo%i ", ntests, n, i);
       tc.ResetEngineResources();
       ParseScript(tc, scripts[rand()%nscripts], __FUNCTION__);
       tc.CheckEngine();
   }
   ntests++;
   tc.Over();
}

No assertion failure here, instead one of the trickiest things to track: memory exhaustion. So it's time for me to learn how to use my tracking tools again. I even left documentation for my future self back in the past (thanks, past self ^^). Once again, the problem arise also in 'default'... looks like I had been over-optimistic in September 2021 when I merged sprites overlay into default.

Well, at least if gives me hope this time: on the 'newmap branch', the forgotten test terminates with 'Out of DS memory'. I managed to get a log of what is allocated at that time, but it would require filtering what has leaked from last ParseScript, and what belongs to the current, interrupted because there's no more memory, running ParseScript. Hopefully, when the bug occurs on default, it gives me a nice 'halt because of leakage' and not a 'out of DS memory' condition. 

• [done] understand why the new branch gets so high on memory consumption
• [todo] make sure .spr and .cmd files in fakeroot/ are working fine (despite they now need bilou.spr and school.spr)
• [todo] that should be the job of UnitTest.mk

edit: dummy! dummy! dummy! ... the 'DS Ram Usage' statistics in those tests is a lie! when it says 95% used, it doesn't mean you'd use 95% of the NDS 4MiB of RAM to play the script. It means that the dummy-allocator-that-never-recycle-memory used 95% of its storage to process the script. Should parsing become more complex (e.g. because we're loading one more file, or creating more intermediate structures), the memory used by the script will grow while the true RAM usage on the NDS would stay roughly the same.

Eeet ouaip. Je me suis donc morfondu un bon morceau de l'été sur le fait que mon moteur de jeu faisait péter sa consommation de mémoire. En tout cas, ça a sérieusement refroidi mon appétit pour le dévelopement de jeu après les heures de boulot. Trouver le problème, ça demandait de se plonger dans une montagne de données et les outils d'il-y-a-longtemps pour comprendre où était la fuite... Sauf qu'en vrai il n'y avait pas de fuite. Tout ça, c'était juste un ou deux messages d'erreur mal nommés qui me faisaient croire que la lecture des scripts prenait plus de 4MB de mémoire (tout ce que la DS a, en somme), sauf que l'environnement de test pour faire tourner les niveaux de mes jeux DS sur PC n'est pas prévu pour qu'on joue, mais pour qu'on trouve les erreurs. 

Donc contrairement à un système de gestion de mémoire ordinaire, quand on lui "rend" un bloc de mémoire il ne le réutilise jamais. La mémoire qu'il fournit à la demande est toujours de la mémoire qui n'a jamais servi pour une autre tâche dans le niveau, et c'est elle qui finissait par faire défaut. Vous me permettrez de croire que si vous avez envie d'en savoir plus, vous êtes aussi en mesure de lire l'Anglais?

If I want to have an estimate of the memory it would take on the NDS, I'd have to keep track of individual allocs and frees and see whether they reach some maximum at a new alloc. (2023-10-23)

What is that one-time allocator ? well, maybe you've heard of bottom-up allocator, where you just keep track of one position in memory: the top-of-used-area, and everything above the top is unused memory. Of course, as soon as you free things out-of-order compared to how you allocated them, that allocator is no longer enough. You would like at least a list of freed-blocks-that-could-further-reduce-top in case the block at the top is eventually freed. Well, the one-time allocator does not even do that. Any byte of one-time memory can be allocated exactly only once. If freed, it is "painted" as free and will remain like that until the ongoing test terminates. 

That is silly as far as memory management is concerned, but it means if some block has not benn freed when the test terminates, you know what role this memory had when it failed. There can't be any tricky-as-hell case where "yeah, that memory had been used for A and then freed, but then it has been re-allocated for B. So maybe B is wrong or maybe something still had a reference of when it was used for A". Sometimes it truly helps. When I'm not misguided by my past self with lying error messages.

Scorpeye... Enfin!

 Oui, je l'avoue, j'ai été lent. J'ai été distrait (au sens attention détournée). J'ai été démoralisé par cette "carapace" qui ne voulait pas faire demi-tour à chaque fois ou qui faisait des demi-tours intempestifs. J'ai douté, de cet empilement de couches qui devait me permettre de laisser des personnes non éduquées au C++ de bricoler aussi leur propres personnages. Sauf que tout ça, c'est bien joli mais que quand vous avez un dysfonctionnement quelque-part, le débugger vous balance des instructions machines alors que le problème est dans le bytecode qu'elles interprètent. Et mon "inspector widget" (pas encore fonctionnel dans le projet 3 rooms) est loin de valoir ddd.

It's been a long time, I have to admit. I've been slow to get things running; I've had lost the hope that I could get that scorpio-shell turning back when it hits a wall... and only when it hits a wall. It felt like I had built a Jenga stack of complexity in order to have a 'simple' interpreter for state machines. But a language is never less complex than the tools you provide to debug it. And Inspector Widget fell short when trying to explain the issue (partly because it is surprisingly not yet working on Dreams.nds)

Une intuition pendant mes vacances ... j'ai retracé la machine d'état de mon scorpion-cyclope. J'ai bien identifié deux ou trois incohérences, mais rien qui ne conduise au bon comportement une fois corrigé.

Oui, je sais aussi, par rapport à ce que je bricolais sur le côté pendant mes semaines de vacances, c'est maigre. C'était des vacances un peu ... particulières.

Puis hier, j'ai repris la machine d'état de pendat. Lui aussi, il réagit quand il fait demi-tour en se prenant un mur. Et il n'est peut-être pas parfait, mais il marche en général bien mieux que cette satanée carapace.

Alors que scorpeye tentait de reconnaître l'absence de sol à l'aide d'un testpoint, pendat se contentait de "dire" "ah bin si la vitesse horizontale est tombée à zéro, c'est qu'on s'est pris un mur. Sinon, c'est qu'on a plus de sol. C'est forcé."

I found only a small evening of ndsdev during my summer holiday this year, and I used it to map the state machine of Scorpeye. It helped me finding a few weird stuff, but it would not make things run properly enough, unfortunately. Then I realised past Inktober that I already had a 'working' monster that bounced off walls. That was the running pendat. And I started mapping its state machine too (granted, after all these years of dsgametools, I should have given myself a tool to make that automatically). To my surprise, it almost never used the same tricks to perform the same task.

For instance, I used a TestPoint below scorpeye to tell me whether there was ground underneath when it claims it failed to slide on the ground. But this is unreliable because it checks only one point to decide for ground while the WalkController checks the whole surface. Instead, the pendat would test whether it came to a halt horizontally. If it did, that means there has been a wall. Otherwise, it bets there's no ground left.

Same with fall/slide transition: the scorpeye tried to use a testpoint to know whether it FAILed because of a ground. Pendat code author (past self) knew the only thing that can make GobGravityController FAIL was a ground. Being stopped by a wall triggers an event. That means no testpoint validation is required.

Finally, I gave myself an extra variable (there are still plenty available for scorpeye) to remember the sliding speed so that we can bounce walls without having to rely on an ImpactController to save the last speed, because so far I don't think GobWalkerController is an ImpactController. It requires to double some states (like left-thrown vs. right-thrown), but that should not be a big deal.

Still, there's one thing that I'll need to fix with unit testing: from times to times, being stopped by a wall while 'walking' doesn't make the move FAIL, but it does clears the speed. Pendat doesn't suffer for that because it has an "increase horizontal speed" statement in its running states that prevents the speed to stay null. I had to add the same statement to the shell, but it shouldn't be required. that's a todo item for XMAS, I guess.

Il me fallait un double-état pour la carapace lancée, une variable supplémentaire pour retenir la vitesse à la place de la 'variable d'impact'... ce genre de choses. Mais il y a un élément suspect. Pour qu'il n'y ait aucun soucis, je suis obligé de mettre une instruction forçant la carapace à accélérer. Sans ça, il reste des situations dans lesquelles je retrouve ma carapace toujours dans l'état "on glisse vers la droite" mais avec une vitesse nulle est un mur juste à ça droite.

Comme si GobWalkerController avait un bug qui l'empèchait parfois de signaler l'échec (FAIL) même si la vitesse tombe à zéro. ça, ce sera une tâche pour un test unitaire.

scanf %ms ou scanf %n?

 it should have been quickly done. Almost trivial. Edit "DHud.cpp", revive calls to the MuadDebug class, change the GOB number so that it tracks the scorpeye rather than Bilou, and make it rewind time

• when the shell's horizontal speed turns to zero
• after it has been thrown (there's a flag telling us that)
• after it has been picked up (need a new flag for that).

Except that however I tried to do it, and regardless of the amount of instruction-by-instruction stepping I made, I couldn't get the second condition to trigger. The optimizer did a great job at packing the expression evaluation code -- I mean there, that you can't tell anymore where you're in the source while doing it, and thus mostly can't set a breakpoint on a specific instruction.

Hopefully, there's the B opcode (not D, which is for Detach) to break at the script expression level. That one at least allowed me to realise that the expression for that second condition was indeed evaluated. But for some reason, the part I was interested in, with flag-setting, never got executed. A 'all done, bye' opcode always showed first. Mysterious...

Faire des essais dans le jeu pour essayer de reproduire un 'trick' pas fréquent, et avoir programmé un critère d'arrêt qui nous permet de passer en débugging pas-à-pas mais en revenant une image en arrière dans le temps, donc en revivant exactement l'évènement qui fait que tout est parti de travers en bullet-time pour pouvoir le comprendre et savoir ce qui doit être corrigé. J'appelle ça le muad-debugging, et c'est vachement pratique.

Enfin, surtout quand ça marche.

It turned out the reason was the expression got truncated even before it was turned into bytecode. Such a thing is not viable to extend the game to "Bilou Dreamland" level.

The code to parse an expression basically looks like

siscanf(base+cont,"[%64[^]]] (%64[^)])",predicate, axion)

And both 'predicate' and 'axion' arrays are static-sized. I know there's another way you could do the 'same' thing, but with any-sized arrays. That'd be something like

siscanf(base+cont,"[%m[^]]] (%m[^)])",predicate, axion)

in which case the siscanf function will allocate some memory by itself and you'll have to invoke free(predicate) when you're done with it. It is sure the way to go in most of your production code, but to be honest, I do not want this within GEDS script parsing code. Parsing a level already takes too much time. Adding dynamic memory for strings processing will only make things worse. Not to mention that it will fragment memory with temporary strings requested while we're making big blocks for the 'tank'.

But there's another trick I could (and likely will) use:

%n Nothing is expected; instead, the number of characters consumed thus far from the input is stored through the next pointer, which must be a pointer to int. This is not a conversion and does not increase the count returned by the function

Combined with the fact that %*s scans a 'string', but does not store it, I should be able to write

siscanf(base+cont, "[%n%*[^]]%n] (%n%*[^)]%n)", &predistart, &prediend, &axstart, &axend);

Now, I'd have start and end pointers for both expressions (if they're actually there), plus that would be copy-less and I would directly perform ascii-to-bytecode conversion. The conversion code would have to be adjusted, of course, so that it takes two pointers instead of one and that it does not expect a terminating \0 character at the end of the expression. So that will be a new "todo" item for when ongoing things are cleared and time is right to start something more experimental.

Oh, yes. And I could just grow the static arrays, of course. That's what I did in the past when they were 32-character long each, and I thought "well, 64-bytes predicates ought to be enough for everybody, right ? ". In another context, I could pick ridiculously large arrays (like 2048 bytes each) and forget about the issues for decades until it strikes back with some auto-generated script. But that would be a bad idea on the Nintendo DS with its fairly small stack. And nah, I won't make the arrays global either. That would sure break so many things in the ability to run that code out of its current context that it has even been considered as an evil thing to do by the former generation of developers.

Attaquons 2022

 Le changement d'année coïncide plus ou moins aussi avec un changement de journal-agenda, un truc qui m'accompagne depuis 2019. C'est là que le trouvent la plupart de mes "todo lists", maintenant, que ce soit pour les outils, le jeu ou la VTJ. Inutile de dire qu'à la page 169/185 du cahier en cours, il me reste encore un paquet de cases à cocher. On va juste transférer ça dans le nouveau cahier, hein ;)

Il y a aussi des thèmes de posts possibles:

• "your first mushroom", pour faire écho à "your first koopa", vu que SMW nous met le 1er dans un bloc volant ...
• les plates-formes de DK:TF (avec potentiellement un intérêt pour la Peaks Zone)
• parler de l'absence de prévisibilité des dangers dans Toki
• parler des lanternes de The Messenger, les comparer avec les piquets d'Aladdin et le dash-slide de Megaman
• parler des éléments de puzzle de Rayman Legends

Ouais, en fait, je pourrais juste me faire un signet "Blog Me" et le passer de page en page quand je fais vraiment quelque-chose avec tous ces sujets.

Ah, par contre au niveau de la fréquentation du site, on est vaguement dans les même genre de chiffres qu'en janvier 2021, mais il faut creuser pour commencer à trouver du contenu de 2021 dans les posts, le trio de tête étant tenu par des vieux posts liés à des réponses dans des threads twitter en vue.

Mais que ça ne nous déçoive pas, en 5eme position, on a quand-même le lien vers le téléchargement de School Rush. ce n'est pas énorme, mais c'est toujours ça.

Back to the 3 Rooms ... hopefully.

 

Most of what had been identified as faulty early this summer is now fixed. Even the mysterious way Bilou flickered while running has been understood (something cleared the VRAM slot of one of the head's sprites) and fixed (animation was using the wrong page). It's been quite time-consuming but at least it is done. It's time I start doing some [todo] pixel art to make proper 'doors' in each environment and [done] craft the kind of rooms I actually need for my 3-rooms milestone.

But see, I've taken almost 1 hour editing that and commenting about it. So I've captured my description of the milestone in my notebook because it's much easier to take it and focus a bit on what I'm going to do next than it is with a blog. 

Anyway. Let's have all tools and runMe rebuilt. Let's have them installed on the cube so that I can use the latest build on the Real Thing before I start messing up with the maps and spritesets.

Many of the 'todo' items for last year had nothing more 'to do' on them.

In the milestone, each room had two doors, so it could communicate with both alternate world. [todo] the engine needs to be able to remember which world we come from and spawn Bilou at either left or right door based on that information. That requires at least an engine upgrade.

DJLN.cmd

Faire des niveaux sur papier, ce n'est définitivement pas une activité à proposer à mon fiston. Au mieux, je peux lui proposer de me dicter un niveau que je ferais moi sur papier.

Par contre, prendre la Nintendo DS de papa et ajouter des blocs ici et là, ça ça lui plaît bien. Mais pas de chance, la branche "newmap/newmeta" n'est pas encore stabilisée au point qu'on puisse tenter de jouer au niveau ainsi construit.

Assez surprenemment, mon nouvel écran de patching m'indique que l'erreur se trouve sur la première ligne de pyram.spr, CMAP n'étant pas une commande valide pour les scripts. Enfin, ça c'est sur émulateur après avoir récupéré les fichiers présents sur DS avec le wifi remis en service.

En fait, ce serait la commande spr.more "pyram.spr" qui n'a pas été comprise par l'éditeur de niveau. Du coup, au moment de sauver, il en fait un input "pyram.spr" Si j'en crois les numéros de version, le bug a déjà été patché, c'est juste que la DS n'avait pas pu profiter de la nouvelle version. C'est J.L.N qui va être content...

• invoking autoexec.cmd with the [run] button does not seem to allow PatchWindow to be invoked.

Twitter Trap Status: story is featured in "All tweets from blogger". No videos around. 

Where are my thumbs ?

I'm trying to add support for spr.more in LevelEditor (so that we keep seeing monsters positioning while editing DreamLand maps ;) but it doesn't work well. After some debugging, I realize that the values for the 'animation number' stored in the first word of the 'TINY' section make no sense. Animation #17000 ? with 48 animations per sheet ?

A simple test with ./sprdo confirms that even if I just load-and-save a file that has meaningful thumbs numbers, we end up with bogus numbers in the saved file.

Still wondering what thumbs I'm talking about ? They are still 32x32 images produced while saving animations in AnimEDS that are then used in LEDS for monsters edition.

Watching the memory backing my vector through execution, I finally found a suspicious set of `free()` statements at the end of the 'extra/unknown data blocks to set of MEDS animations' function.

The history of that function is that it abstracted something from `spr.load` script statement so that `spr.more`can exist. When it is done with them, the GameScript used to dispose of remaining really-unknown data blocks. Such as thumbnails. They won't be needed while we play the game and they eat up significant amount of memory.

Then, there was the code of SpriteEditor, the FileModel, to be precise. It had been updated so that it could invoke the same sort of 'FromExtras' function, but since we're not interested in MEDS animations while editing sprites, template magic makes this whole function unused. And then is the new tool, that tries and use code meant to be for GameScript but in a load-modify-write setup. That one ends up with freed pointers in its array and then try to save back those opaque data in the file. This is where my 17000 comes from.

The perplexing thing is that AnimEditor itself doesn't seem to read back the TINY thumbnails, but still when I load a file from OtherFileWindow, I get no thumbs on my top screen. Not until I edit something and move to another page, that is.

It took me time to check everything, and it finally revealed that, yes, makeThumb() are properly invoked even for OtherFileWindow, as soon as we call MetaWindow::data_reloaded() to signal things were updated. But the setup ThumbsWindow::restore() installed to show and use the TileTable showing the thumbnails got screwed up by OtherFileWindow's default layers settings. forcing a call to THW::restore() within data_reloaded finally fixed the issue. So that means bilou.spr on lime DS is likely fine and I can download it to resume development of LevelEditor's support for spr.do ^_^ (erhm. Next time. It's quarter-to-midnight and I've got meetings tomorrow ^^")

edit: unfortunately, after retrieving bilou.spr and school.spr that had been edited by AnimEditor on the NDS, they still contain rubbish TINY sections... I'll have to work on a medsdo tool to study that...

• [okay] AnimationModel already has RenderThumbs 
• [todo] animchk wrongly claims the options of sprck.
• [okay] *::Load and *::Save should be in the model layer.
• [check] could we be missing vector::clear ?
• [todo] we shouldn't push a TINY if it wasn't rendered.
  

Reality check

 J'ai atteint un stade dans le développement de mon nouveau LEDS ou je peux envisager de faire un essai sur du vrai hardware. (En fait, il y a plusieurs choses que j'aurais dû essayer depuis longtemps, mais il semble y avoir une sorte de flemme à ressortir la DS et démarrer server.pl, ces derniers temps). ça fait une jolie photo, mais j'ai facilement passé la soirée à faire l'inventaire des choses qui ne vont pas :P

One bit at a time, a new build of LEDS has appeared, that combine enough patches from the 'newmap' branch so that I can consider giving it a spin on real hardware. Well, or so will I pretend. The crude reality is that the "Check List for RealThing" is only a few page past "April 2020" in my notebook.

I got no significant crash, but many of the features are incomplete. The evening was gone when I finally had the list compiled. Next evening, I'll update the e-book doxy-code and will start investigating why I have "bugWindow" inserted between MapeditWindow and MonsterWindow ...

La conversion des niveaux, par exemple, est incomplète. Ni les tiles "jump-through" ni les pentes n'ont été récupérées. Sur un vieux niveau où il n'y a pas de déclaration des blocs spéciaux, ils sont tout simplement invisibles (voire peut-être ignorés).

Les copier/collers de blocs spéciaux sont un peu bizarres aussi, en particulier pour les tiles "voir ci-contre". Je sais pourtant en créer de nouveaux en utilisant directement les Meta-Boutons.

Enfin, il se passe quelque-chose d'étrange avec la gestion des "fenêtres", comme si il y avait un mode "buggué" entre le mode "dessin" et le mode "édition de monstres".

Je sens qu'il va y avoir un nouveau .epub avec le code le plus récent à télécharger sur boox ...

The Dreamland Map

I'm reaching the last pages of my plan-your-things notebook. It helped a lot completing both real-world and hobby projects. I've got more books available to take over, but I also need to make sure I won't miss contents of the 2019 book when I'll be hanging around with the 2020 book. That's why the 'todo maps' are on flying sheets rather than on proper pages.

Maybe there are things I should blog for remembering. Clearly there are things I should doxygen...

There are things I still need to blog in there. Notes I've taken about SNES hardware, for instance, and similar hardware features from the NDS which I haven't used yet.

And then, there are game analysis things, which are totally unrelated to tools & engine development, but which I'd like to bring into the 'design class'. Those, hopefully, will not be missing if I don't have them around in the new book.

You see, having the dsgametools code around in a e-boox is nice, but I need some additional place to "think out loud", and with my eyes not liking using screen more than 10 hours/day, it cannot only be this blog anymore. That's what the notebooks are for ;)

Dans le code de Celeste ...

Je m'étais fait une conversion epub du code de Celeste, peu après avoir reçu mon boox, pour étudier un peu tout ça pendant que *deline était à son cours de sport. Il faut bien dire que ce n'était pas simple à suivre, entre les hyper-jump et compagnie. Mais ici, un des développeurs vient de tweeter une série de mini-vidéos pour montrer toutes les ruses de gameplay qui ont été mises en place pour que le gameplay soit satisfaisant.

A few time after I got my first boox, I found the code for the game Celeste by Matt/Maddy Thorson. It seemed appropriate to study it while *deline was having sports in the evening, and it did give me some difficulties with all those hyper-jumps and similar advanced techniques. Especially since I barely started a game of Celeste on my switch and I'm nowhere in mastering those advanced moves. But the developer did tweet a list of 10 tricks they used to make the gameplay more satisfying.

Oh, j'ai une partie en cours sur Switch, aussi ... mais M. Oshiro en furie me mène la vie dure.

• De 1 à 4: on a des techniques équivalentes dans Bilou
• 5 - contourner les coins au lieu de se cogner la tête dessus. Pas encore.
• 6 - s'aligner sur une plate-forme à sens unique quand on passe à travers
• De 7 à 10: différentes manières d'étendre les zones de collisions avec les murs / plate-formes pour compenser des pressions de touches un peu tardives de la part du joueur (un peu comme le vile-coyote-time, mais dans d'autres circonstances - notamment pendant un wall-jump).

edit: ça y est! j'ai passé M. Oshiro!

Tiens, pour la comparaison, on atteint quand-même les 5000 lignes de code pour Player.cs (qui pourrait contenir plus que le code de Madeline, hein)

The tricks are the following (if twitter dies, they are hosted on "Celeste & Forgiveness" with their original animated gifs)

1	coyotte time	You can still jump for a short time after leaving a ledge.	done
2	jump buffering	If you press and hold the jump button a short time before landing, you will jump on the exact frame that you land.	done
3	Halved gravity jump peak	If you hold the jump button, the top of your jump has half gravity applied (gives more time to adjust for landing)	done
4	Jump corner correction	If you bonk your head on a corner, the game tries to wiggle you to the side around it.	todo
5	Dash corner correction	if you dash sideways and clip a corner, it'll pop you up onto the ledge.	todo
6	Dash corner 2	also pop you up if it is a semi-solid platform	todo
7	Lift momentum storage.	Add momentum of upwards-moving platform to regular jump impulse, but allow to use it even a few frames after platform stopped moving upwards.	done
8	coyotte wall-jump	you can wall-jump 0.25*playerwidth away from the actual wall	d.n.a.
9	8 for super-wall-jump		d.n.a.

(the 'done/todo' status indicates whether I have a corresponding solution in Bilou's game engine/state machine)

ImportsWindow::render()

Bion, la nouvelle garde-robe est installée ... j'ai eu un peu de temps pour regarder comment m'y prendre pour avoir les images des différents personnages du jeu sous le contrôle de la nouvelle "ImportsWindow" et en tracer les grandes lignes dans le code
[done] utiliser les ImportBlocks pour choisir quel état afficher où
[done] mettre en place une matrice de scaling pour les éléments secondaires d'une ligne 'import'
[don't] sauver les noms ? 

Je vous en raconterais bien plus, mais je suis à la recherche du truc électrique responsable des coupures de courant à répétition dans la maison ...

MonsterPropertiesWindow

At last, I've got a first working sketch of the 'monster properties window'. It turned out quite tricky to get it working. It can report whether gobs have links and initialization expressions in addition to tehir class. There still is plenty of work, like being able to actually update state when you use the widgets, and write an expression by using the customized 'TypeWord' widget featuring the full gobscript characters set.

Trickiness came from window-to-window communication, so that the right widgets got displayed at the right time (having to hide the whole "tileset" widgets)