furblock de montée

La dernière tentative d'améliorer la branche s'est plus ou moins soldée par un échec constructif. Puisque le week-end de montée m'offre un peu de répit, je vais partir sur une idée qui m'est venue en passant en revue les autres jeux avec des éléments de gameplay similaire: commencer par me faire un "bloc-note" à la SMB3, qui se concentre sur le mécanisme, pas sur l'animation. Et une fois que le mécanisme sera validé, je fait la même chose avec un objet invisible.

So trying to combine physical motion and animation for the bouncy branch proved to be a bad idea. Rolling back. I'll keep my satisfying animation and combine it with an invisible block behaving like the "note block" of Super Mario Bros 3 instead. And I'll prepare that with non-invisible block in an easier-to-test environment, that is the pyramid room.

• premier fix: je dois retirer les zik.import de mon script pyrat.cmd: ces commandes sont propres à la "trhee rooms demo" qui pré-charge un module de base (bilou.xm) et runMe ne connaît pas (encore) l'équivalent, même après recompilation du dernier modèle
• deuxième fix: runMe a besoin d'un "../spriteB.spr" explicite pour aller chercher le nouveau fichier (et pas un vieux fichier de SchoolRush dans efs:/moving/spriteB.spr ^^")
• 3eme fix: ma petite anim' faite à la main doit utiliser la SpritePage 8+2 (parce que le fichier bilou.spr préchargé contient 8 pages)

Bon on y est. J'ai un "furblock" dans le niveau-test de la pyramide. Je saute dessus et il s'enfonce bien puis ... il décole vers l'infini et au-delà (ç.à.d  -2147483648). Ah oui, et il n'a encore un tête de fury que sur DS, pas sur l'émulateur. 

J'ai utilisé pour le réaliser un nouveau contrôleur "grille" qui indique si on est repassé au "bloc" suivant, histoire de passer d'un état "repoussé vers le haut" à un état "repoussé vers le bas", et que le bloc finisse par se stabiliser à sa position d'origine. Mais manifestement, ça ne marche pas encore.

There have been a few "setup" issues, leading to a few TODO items to be processed later (this season?) in my notebook, like runMe not supporting the multi-music commands and the lack of "translate to that sprite page" macro for multi-spriteset that leads to annoying magic numbers. But I have to admit that even with that done, the behaviour was fairly surprising. Well, on the DS, the "furblock" did a downwards bump and then skyrocketed to negative numbers: I needed something to fire an event when the original position has been reached. And that thing could be the "grid" controller that was part of my "how to code bosses" arsenal.

But even with that, the resulting behaviour is emerging and perplexing. I guess I haven't found the proper set of rules yet.

Et nous voilà le week-end d'après encore plus au calme, ce qui m'a permis de décortiquer avec InspectorWidget le comportement émergeant (mauve) et de trouver les corrections (bleues) nécessaires pour que ça marche pour de vrai ;)

Special thanks fly to Wye for his SMW-remake-howto video and how it reminded me that the Springy note block exists in first place, and how they were perfect match for the feature I was looking after. ^_^

Let's have more musics!

If you have tried the last demo, you most certainly noted that there are only 2 soundtracks for 3 rooms. And moreover, that there is a different set of sound effects depending on the room you're in. This is a drawback of the current sound engine, where everything is in one data file: main in-game tune, side tunes for menu and such, single-pattern for level clear, mini-patterns for 1-UPs and notable pick-ups, samples to play them all and samples to be used as standalone sound effects.

Bon, un des gros morceaux de programmation qu'il me reste à faire sur le moteur de jeu, c'est de faire en sorte qu'on puisse plus librement passer d'une musique à l'autre. Pas charger une autre musique en changeant de monde, ça c'est déjà fait. Non. Je veux dire décider que "string tracking" n'est pas la musique idéale pour la green zone et que "4U2" donnera mieux. Ou "little flower on the grass". Pour l'instant, ça pose un soucis parce que les fichiers musique contiennent aussi la palette sonore pour les différents personnages. Je voudrais donc pouvoir faire avec les samples et autres patterns ce que j'ai fait avec les images : charger un deuxième jeu de sons par-dessus la musique destinée au monde. ça fait un moment que ça me trotte en tête.

Et cette semaine, j'ai pu passer un premier cap: importer les samples. ça a l'air de marcher, mais ne nous leurrons pas: vu le type de programmation auquel on a affaire, il faudra rajouter quelques tests automatiques sous scruteur de mémoire pour garantir qu'on n'a pas ajouté une bombe à retardement dans le jeu. Et il y aura une repasse pour mettre ça au net avec des classes une fois que j'aurai validé le concept, parce que pour l'instant, ça part dans tous les sens, aucune des classes du moteur de jeu n'ayant été prévues pour ça.

So among the objectives I sketched in my 2024 notebook, there was some ideas to overlay .xm files the way I overlay .spr files... Or rather the other way'round. Here the generic "bilou.xm" containing mostly sound effects would see its samples and patterns imported over the world-specific song.

#ndsdev status last night: I could allow 2 instances of NTXM::Song to exist together.
#ndsdev status tonight: I can import instruments from one NTXM::Song so that different environment can share some sound effects.
little step for #gamedev, giant leap for game #MadeWithMyEngine.

I admit it might sound weird to add the common part over the world-custom part. After all video does the opposite. The reason here is that odds of adding common sounds over the course of the development feels higher than odds of adding new samples to an existing song. It shouldn't be too hard to tell my brother that patterns 50-60 should be kept free for sound effects, same for samples 50+, no matter what song we're using than to remap all samples of the per-world-songs to other slots because we've got one extra ooch-that-is-electric sample added in the shared bilou.xm

But yeah, I still make sure that bilou.xm is only loaded once, when the game initializes, and we don't pay extra wait time for overlaying it from the SD card. Instead, samples and patterns from the shared song got "borrowed" from the shared song and marked as such so that they aren't freed when we swap songs. Did I mention I read a bit about RUST programming language earlier this week ;) ?

edit: now also imports mini-pattern ^_^

edit: tried new songs ... some things worked, but some things look broken

edit: ow. turns out when you encounter pattern break on a mini-pattern, only the channel with the break command is discarded ^^". Seems like it was only a matter of luck that SchoolRush did work fine, and possibly explain why playing / leaving it idle long enough started producing super-fast trash sounds. Now, you'd have hard time dumping the ROM with that ... not as "easy" as with a runaway audio channel on a GBA.

edit: fixed

Appleman 2.0

Bon, je me suis enfin refait les animations de l'Appleman dans l'éditeur d'animation modulaire. C'est que déjà avant que je ne m'attaque à Apple Assault, j'avais dans l'idée que Bilou puisse ramasser le corps de l'Appleman pour s'en servir ensuite de projectile. Puis c'est plus cohérent avec le comportement de dumblador qui joue le même rôle dans la School Zone.

Sauf que, vous vous en doutez, ça ne s'est pas passé sans mal. D'abord quelques plantages de MEDS (oui, encore) qui m'ont obligé à tout refaire, puis le niveau qui ne voulait plus rien charger le temps que je lui réexplique où se trouvent les animations demandées et que je corrige celles qui étaient lues en boucle alors que la machine d'état prévoit une transition "à la fin de l'animation".

You could easily claim that this was a cursed sprite and I would almost believe you. See, I've had applemen pixels from over 15 years now, and yet I wanted to upgrade its motion into a compound sprite. The idea would be to make it more like the dumblador, losing its feet when stomped, staying stunned until feet are recovered etc. I expect that it would feel fun...

Then the curse started, with blue screens in the editor as I tried to "clean up" some animations, despite I fixed something similar in September. Then the level would no longer load because some of the newly defined animations were looping and AppleAssault assumed it could wait for them to be done for some transition. And when all that was fixed, with WiFi transfers over RunMe through the NUC, the appleman did not have feet but huge, purple fists instead.

Ensuite, voilà que les pieds de l'appleman sont remplacés par des gros poings mauve alors qu'il devrait réutiliser les pieds de Bilou relookés en brun. La faute à un code encore un peu trop jeune dans le chargement d'un 2eme fichier de graphismes. Les couleurs erronées, ça, ça m'aura pris plus de temps. Je me replonge dans le code d'il y a 2 ans, je vérifie qu'on a bien assez de mémoire vidéo pour charger tout ce petit monde (scoop: oui. On a 16KiB, assez pour 8192 couleurs alors que les 16 palettes accessibles par les sprites n'en consommeraient que 4096)

To get proper images, the first thing is to ensure SpritePages are properly remapped when loading the additional set. For the school zone, that was done with spr.more "school.spr" page8,82 meds+4. Yeah, I know. That's not the most self-documenting line of script in the world ^^". What's important here is page8,82. That is controlling the remapping.

• The first number (8) indicates that we expect Bilou.spr to feature 8 sprite pages, and that pages for "school.spr" are to be numbered 8, 9, 10, ...
• The second is not a number: it is a series of digits each identifying a page, and each telling where each page is starting with the 8th slot. Page 8 remains unchanged (since the series starts with an 8), but page 9 will use page 2 instead (where Bilou hands and feet are)

That was for the school zone, but the green zone spriteset did not have hand and feet. Instead, they had to be added as the 11th page within the set ... almost page 20 for the level. Code parsing that was a bit crude too and was never meant for things identifying page number higher than 10. Oh, you could do it, but you might have to identify page 11 in the whole set with ;. I tried to simplify that a bit so that we can actually use spr.more "green.spr" page8,-..---.----2 meds+4 instead. Here,

• every - in the sequence means "that page holds no sprites. It shouldn't be used by animations".
• . means "don't touch: that page is perfect as it is". Any sprite page in green.spr has such a dot.
• And you know about the final 2 already: it identifies one page within bilou.spr that must appear instead of a "draft" page of green.spr and be used by Appleman animations

Definitely, some colors from green.spr were loaded here. We wouldn't have the sprite-branch with colours that close to those of the trunk otherwise. But the yellow worm now has weird blueish outlines and the appleman feet are both light-Bilou-green rather than having one dark brown and the other darker brown. 

Et là, la raison était plus ... exotique, on va dire. Le code C++, rien à redire. C'est presque limpide: ça *doit* ajuster les commandes qui définissent les images et palettes utilisées par les personnages, à condition que le décalage soit correct. Et le décalage, je fournis à la main dans le script du niveau. Mais manque de bol: le compilateur (gcc 8.1.0 ajouté à devkitARM 49 en 2018) produit du code machine qui ne correspond pas à ce qu'il me faut (une fois encore). Vérification faite, le gcc 10.1.0 du devkitARM 54 ne fait pas mieux. Pour avoir enfin mes bonnes couleurs, il faudra que je réexprime mon code différemment pour contourner ce qui semble être un bug dans le générateur de code ou dans l'optimiseur ...

There's a line in the remapPages() function that should deal with that: find "change sprite" instructions in the animation code, isolate the current palette value and add the "adjust palette" computed by the caller. It should work, really, but single stepping through the code with all the optimized-away locals left me puzzled. So I dug deeper, taking notes of the machine code, tracking what register meant what and ... 0_0

and there was no add instruction to be found. Nowhere in the loop. The machine code generated by gcc 8.1.0 would just assign the same green_palette[0] to every sprite no matter what palette they were using. That seemed to happen with gcc 10.1.0 as well... it wasn't too hard to work around, but yet. Troublesome.

zik.more "bilou.xm"

Bon, après avoir peiné à permettre de mélanger deux jeux d'images dans la mémoire vidéo, il est probablement temps que je regarde à faire la même chose au niveau des sons. En particulier parce que pour l'instant ma démo "three rooms" est obligé de partager la même musique pour l'école et la pyramide. Et si CJ ou Piek me débarquait là tout de suite avec une musique plus pyramidale, je serais obligé d'aller copier-coller les samples et les pistes de 'bilousch16.it' par-dessus, sans quoi je risquerais d'avoir des effets bizarres.

La manière la plus simple de procéder serait de charger d'abord "pyramid.xm" puis d'aller piocher dans "bilou.xm" les pistes et les samples que je veux importer. ça a par contre l'inconvénient qu'à chaque fois que le jeu va charger un nouveau monde, il doit commencer par oublier tous les sons, charger les sons spécifiques au nouveau monde puis enfin remettre les sons communs par-dessus. Avouez que c'est un peu idiot.

Une alternative à creuser, ce serait de faire en sorte que les sons et pistes d'effets de Bilou.xm restent en mémoire, et que la musique "pour le monde en cours" sache y faire référence sans essayer d'en gérer directement le contenu. En somme, que ces samples aient un statut "d'invités" et que supprimer le morceau en cours n'ait aucun effet sur eux.

• bonne nouvelle: XmTransport, la classe chargée d'ouvrir les fichiers XM, est déjà capable de travailler avec un NTXM::Song& donné.
• [done] vérifier qu'il n'y a pas "d'effet Singleton" dans ::Song
• [done] extraire le bilou.xm hors de la musique de SchoolRush
  

done transition on looping animation

I've been crawling on the dark side of hobby game development lately. Dark because it mostly involved too much hex numbers and too little pixels to feed enjoyment while doing it. Dark because it implied admitting that I have not been paying enough attention to things like "whether unit test still pass" and "whether it might be the right time to merge that into default". Things that make the difference between coding and coding as a job. Now I have to repay that attention debt, right after the buggy-tool debt and even before I can look at that memory leakage debt. Given how long it took, how little motivation I had to do it more than 1h per day, I wonder whether I shouldn't have opted for something less useful but more enjoyable first...

Anyway, I went on with cherry-picking bits of the 'newmap' branch that ought to have been on independent branches and merged into default long ago until I finally identified the fix that stabilizes on what pages animations are actually loaded.

Y'a les jours où le développement de jeux, c'est fun. Puis il y a les jours où le programme supposé anticiper les défauts du moteur de jeu vous crache de l'hexadécimal à la figure. Tout ça parce que j'avais espéré pouvoir remonter dans le temps avant la décision "allez, on va faire évoluer le moteur de jeu pour qu'il puisse supporter plus de pentes, plus de types de sol et encore plus de folies!" ... parce que je n'avais pas pris la peine de vérifier que la modification juste avant ("allez, on va autoriser la fuuusiooon de fichiers graphiques au moment du chargement pour permettre d'avoir un monde 2") ne cassait rien de ces fameux tests automatiques.

Et encore: l'hexadécimal, il a presque fallu aller le chercher dans les boyaux de la bête qui se contentait sinon de nous roter un "transition sur fin d'animation en boucle". Eh oui. Et j'avais beau reprendre les fichiers dans mon éditeur, vérifier à coup de MD5 que j'utilisais les bons, vérifier l'état du GobTransition dans le débuggeur, rien ne parvenait à expliquer comment l'animation d'inkjet se retrouvait tout à coup avec une boucle.

I have small scribbled characters and notes about it all over my yearly notebook, but I thought it might be worth another "big picture" sketch page to summarize all the things I had forgotten about my own code and re-discovered while working on this specific bug.

Like how you can load two files in the sprdo helper tool to see which animation #543 truly is ... I should have remembered that earlier on. As soon as I noticed that the the commands I could see in the debugger were not matching what they should (they were ending with a 'LOOP' command, just to start with. I tried comparing them with the line above, the room above, but I should really have just compared them with the next page ^^". Then I've been distracted by that "meds+4" extra token on some files, but it was just a hint for Level Editor. I guess that would have been obvious if I had refreshed memories of "world 2" by reading my own blog posts again. But for some reason, I only thought about that tag now, when blogging about how I eventually figured out that I was missing some fix written long ago, but not merged on "default" ^^".

Au final, ce que j'aurais du faire, c'est comparer cette animation incompréhensible à celle se trouvant au même emplacement, mais sur la page *suivante* dans mon fichier school.spr ... parce qu'il me manquait sur la branche que je cherchais à corriger un malheureux patch corrigeant un décalage d'une position au moment d'enregistrer les animations du fichier supplémentaire à côté du fichier de base :P

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.

ça boume, vieille branche ?

Bonne nouvelle: j'ai enfin ma branche rebondissante. Je suis plutôt satisfait du résultat. A un détail près: les couleurs. Je pensais au début que j'avais pêché la mauvaise palette parmi celles de green.spr, mais j'ai du me rendre à l'évidence: ma petite animation utilise les couleurs de l'autre fichier. Je n'ai encore utilisé que des sprites "tout simples" en dehors de l'école, et j'ai forcé leurs palettes directement dans le script qui définit leur comportement. Pas moyen de faire ça avec les animations binaires de MEDS. Et si je désactive cette astuce, j'ai aussi des couleurs bizarres pour tous les monstres précédents.

Yeah. I've got one first objective met: I have branch-that-bump bumping. Just one last thing to be fixed: it doesn't use the proper palette. I thought I was merely missing some adjustment number in my script, but I had to admit the bare truth: the only reason why school zone had proper palettes for monsters is that Bilou's palettes were split from the School Rush file. It took a few tries to get palette patching working right, but it ended up easier to do than I had foreseen.

ça paraissait improbable, cela dit: après tout les animations du niveau 'school zone' s'affiche correctement. Il doit forcément y avoir une ruse de chargement que je n'ai pas encore prise en compte. Bin non. bilou.spr et school.spr partagent la même palette, c'est tout. C'est aussi bête et sot que ça.

Modifier les palettes au chargement dans l'animation n'est pas trop difficile, heureusement.

3 Rooms - Release Early

 

There we are. The first demo featuring the first 3 environments of Bilou's Dreamland cycling to one another, changing music and graphics. It's super work-in-progresss, and there are so many things to be fixed that I won't try list them now. But you know what they say: "release early, release often", and a fellow gamedever asked me earlier this week about being allowed to test and so on. So if you think he's right, enjoy this St-Nicolas gift.

Download: Dreams.nds updated Dreams.nds for new year

Voici donc (enfin ?) quelque-chose de téléchargeable avec les environnements que j'ai l'intention de faire évoluer pour y amener toutes les nouveautés de gameplay de Bilou's Dreamland. Alors, soyez avertis quand-même: c'est vraiment une version 0.0.0.1 là. Pas même une ébauche, tout juste un canevas. Y'a des retouches à faire par-tout. Y'en a tellement que je n'aurais même pas le temps d'en dresser la liste avant d'aller me coucher. Mais qui sait, ça vous amusera peut-être.

greent.map

Se pourrait-il que j'arrive malgré tout à avoir une démo "3 rooms" pour la fin de l'année. Enfin un premier jet. Le hic n° 1, jusque là, c'était la quasi-impossibilité de faire une nouvelle map propre. Depuis l'introduction de la branche newmap, l'éditeur de niveau ne savait plus le faire, mais j'ai fini par trouver ce qui n'allait pas

Maybe I'll have a 3-rooms demo by the end of the year ? Not with all the features working, of course. Expect static waterfalls and incomplete water physics, but at least a .nds where you could travel freely between the 3 environments I have so far. Until yesterday, that was hindered by a bug in the level editor that prevented me from creating new maps: I could only update existing ones. But that bug is now solved, so I started tiling 'greent.map' and 'schoolt.map' as I intended them to look like in my notepad.

Du coup j'en ai profité pour redessiner en 512x256 les niveaux-démos prévus, rajouter les palettes de couleurs que j'avais essayées pour les cascades. Il n'y a pas encore d'animations ni de physique de l'eau ... ce qui donne un résultat un peu perturbant (mais pratique pour aller voir ce qu'il y a d'autre sur le 2eme écran). Ouaip. c'est l'avantage de la Saint-Nicolas en quarantaine quand les enfants ont assez grandi. J'ai eu l'occasion de m'asseoir avec ma DS à côté d'un Gimp.

Then I went ahead, taking advantage of the 'woot-we-have-new-toys' while we're all locked-home by quarantine to open my earlier waterfall mock up and redraw that into SEDS.

I hope I'll be able to do the same with pyrat.map soon.

bg0.more vs. spr.more

 Bin ç'a été un drôle de week-end. Avec la p'tite famille en attente de résultats des tests covid et moi qui savais déjà que j'étais négatif ... enfin, le point positif dans tout ça, c'est que j'ai pu (dû?) me poser et clarifier sur papier ce qui n'allait pas avec ma gestion des 'overlays de spriteset' (si, vous savez bien: la superposition de deux fichier dans la mémoire vidéo de la console).

Reprenons. J'avais remarqué que mes écrans bleus étaient liés à des pages incohérentes, et ça m'avait conduit à constater que ni l'indexage page-dans-le-fichier ni bloc-dans-une-page ne contrôlait que je restais dans des objets définis. En clair, si je prends la 12eme page sur un fichier qui en fait 10, bin il y a des chances que ça se termine mal.

J'ai donc rajouté du code pour détecter et rapporter les erreurs (ces petits yeux gluants sur mon dessin de l'autre jour) si bien que le niveau de l'école ne chargeait plus. En cause, l'animation de ce smiley bleu qui sert de renfort d'énergie à Bilou et qui est un peu un extraterrestre dans le jeu. Tout comme les livres, les fardes et les lettres-bonus, il s'agit d'un élément de la map du niveau. Un simple bloc animé. En revanche, son animation fait partie du fichier bilou.spr, histoire que je puisse le réutiliser dans les autres zones à l'identique.

Sauf que jusque là, si je chargeais bien un 2eme fichier .spr par-dessus bilou.spr dans la mémoire des sprites (malgré les complications pour l'animation), du côté des blocs, c'était school.spr et rien que school.spr. Et le code qui demandait de créer un BlockAnim à partir de la page spr:6 ne pouvait pas fonctionner, vu que quand on charge un .spr en tant que "sprites", tous les autres types de pages (blocs et anims) sont ignorés. Une ruse pour éviter de charger deux fois les animations en mémoire.

Bien. On va charger les blocs de bilou.spr dans la mémoire des blocs. Mais on les mets où ? Si je les rajoute par-derrière school.spr (ou green.spr, ou desert.spr), les nouvelles pages d'animations auront un numéro différent dans chaque zone (galère pour écrire les scripts). Si je les mets par-devant, toutes mes maps sont bonnes à jeter. Et si je les corrige, je pourrai recommencer chaque fois que j'ajouterai ou retirerai un bloc de bilou.spr >_<

Alors me voici occupé à ajouter le support pour bg0:-1 qu'il faudra comprendre comme 'la dernière page du SpriteSet des blocs'.

spr.more in Level Editor

 

ça n'aura pas été simple de recommencer à avoir des représentations des monstres correctes dans le Level Editor. J'aurais probablement dû utiliser mon "autoexec.nds" pour le coup, mais j'ai procrastiné ça en insistant que 'nan, mais j'y suis presque, là'. J'aurais aussi eu plus simple si j'avais eu un affichage de la VRAM 'brute' dans mon émulateur, mais je n'ai pas encore ça non plus. Ou éventuellement un 'print' qui se mette à jour d'office.

Là, j'ai pu corriger pour que spr.more ne perturbe plus le chargement du 1er spriteset, mais je dois encore chipoter pour le 2eme. Je pensais que c'était lié aux arguments de la commande, mais en réalité, ils n'ont pas d'impact si on ne joue pas les animations.

Mais les dernières ruses que j'ai dû déployer pour que ça fonctionne (notamment un champ additionnel 'meds+%d') me mettent un peu mal à l'aise. J'ai l'impression que c'est le signe que le mécanisme spr.more n'est pas au point et demande de trop connaître son comportement pour pouvoir s'en servir.

edit: près d'une semaine plus tard, je finis par mettre le doigt sur le dernier problème. Une commande destinée à introduire une animation pour 'SimpleGob' dont j'ai changé la syntaxe dernièrement sans penser à changer la syntaxe aussi dans le parseur de l'éditeur de niveaux.

Donc, l'éditeur de niveau est prêt (mais pas encore uploadé), l'éditeur d'animations est prêt aussi (allez, je les uploade tous les deux sur le cube), les fichiers .spr sont corrigés (sur la DS aussi, je crois) ... On dirait que je vais depouvoir commencer à faire des maps pour Dreamland ?_?

La bonne nouvelle c'est qu'au passage, j'ai doté cmdck de nouvelles fonctions pour me montrer le contenu des tables régissant ces vignettes sans devoir faire appel à l'émulateur (?thumbs, ?page, ?states)

spr.more et sprdo

J'avais prévu de commencer par "Bon, ça commence à prendre forme", mais le temps que me mette à blogger, j'ai presque fini. L'idée est donc de montrer qu'il est possible de charger les sprites d'un jeu GEDS en deux fois, avec un morceau pour le personnage principal et un morceau pour les monstres, par exemple, histoire de pouvoir avoir des monstres liés à l'environnement traversé par notre personnage (comme dans quasiment tous les jeux assez longs).

Si je dis "les monstres" et pas "les blocs", c'est que dans leur cas, le fichier .spr contient aussi les animations, et que ces animations font directement référence à des numéros de page. Charger en deux fois, ça voudra donc aussi dire modifier à la volée les animations pour s'adapter aux nouveaux numéros de pages. C'est codé, mais pour le tester, il me faut des fichiers à fusionner. Or jusqu'ici, je n'ai pas énormément de fichiers .spr avec des animations. J'ai l'école, le personnage-easter-egg de la présentation de AnimEDS, peut-être un 'papa Noël' quelque part (mais où?) et peut-être un badman (mais où??).

Bref, j'ai fini par me dire que le plus direct, c'était sans doute de couper bilou+école.spr en deux fichiers bilou.spr et école.spr pour montrer qu'on pouvait les recombiner ensuite. Pour ça, ça m'a semblé utile de revenir sur un de mes outils de hacking de fichiers .spr: sprdo. Il s'agit d'un programme linux tournant en ligne de commande et qui utilise le même modèle de manipulation des .spr que le Sprite Editor lui-même. (mon collègue parlerait-il de code métier?). 

Un argument Lfilename.spr, et voici un fichier chargé. Un deuxième argument pk6, et on fait comme si on effaçait la page n°6. un p? et on voit des informations sur chaque page présente dans le fichier en mémoire. C'est un peu primitif, mais ça fait l'affaire.

Il fallait donc y ajouter une commande "montrer l'animation unetelle" puis faire en sorte que "supprimer la page unetelle" supprime aussi automatiquement les animations qui y font référence.

ça n'a pas été sans mal, mais j'y suis presque (reste à "nettoyer" les fichiers .spr de tous ces sprites qui n'ont plus de raison d'être, histoire de ne pas dépasser les 64K au moment de fusionner les deux. (normalement, j'ai déjà du code pour ça)

edit: on y était presque. Inkjet et les power-ups se sont chargés correctement. une partie de Bilou.cmd ausi, puis on arrive à une animation située sur la "deuxième page" d'animations avec Bilou (0311) et là bardaf: il n'y a plus personne. En compactant le spriteset les doigts dans le nez, sprdo m'a visiblement perdu certaines animations (la plus haute étant la n° 107 alors qu'il faudrait que j'aille jusqu'à la 129)

• [done] use the right anim (the one using the right page) for the waves
• [done] apply waves animation from the proper page (that also fix blinking of Bilou's limbs)
  
• [done] pendat and blador use proper shared limbs page
• [done] understand why the heal pick-up is gone
  
• [done] proper animation when we pick up a bonus
• [done] proper animation when we bounce on an eraser.
  

spr.load+

The next big step for my game engine to be capable of running project “Bilou  Dreamland” is overlay loading. In all my previous games, there was one main tileset and sprite set that contained all we needed. Monster, hero, Pick-ups. Anything that had to be animated sat together in that file…

Bon, prochaine étape significative pour le développement sur DS: faire en sorte que le game engine puisse charger les graphismes "en deux temps", en particulier pour les sprites. J'aimerais bien éviter de devoir répliquer le graphisme de Bilou sur plusieurs spritesets, tout simplement.

Et ouaip, j'étais prêt à lancer ça en début de congé de Noël, puis je suis laissé distraire par un 'to branch or not to branch', *deline m'a chipé la tablette pour lire du Ewilan, et moi je me suis mis à faire du déterrage de brouillons :-/

C'est ça, la quarantaine: ou bien tu code, ou bien tu blogges. Les deux, c'est niet.

In order to come up with a “world 2” that features new creatures, this has to change. Especially, I want to have a single “Bilou.spr” containing character animations for all moves. The engine will then complete this with world-specific monsters and NPC data. When you think about it, the very reason why there’s never been a level 2-1 in my BASIC games was because  I couldn’t find the proper solution to this design challenge.

Mais, allons. Ne soyons pas défaitistes: c'est pas que je n'aie rien fait sur DS pendant les vacances. Juste que je n'ai pas fait ce que j'avais prévu, et que j'ai complètement perdu de vue depuis ce que j'ai fait depuis ce moment.

Plutôt que de me lancer dans une nouvelle branche, j'ai stabilisé et consolidé les différents outils.

edit: j'ai déjà quelques p'tites modifications qui donnent pas mal.

Par contre, il faudra que je réfléchisse à un moyen de valider que tout ça fonctionne bien comme prévu.

Well, I was about to start this at the start of xmas holidays, and then *deline picked up my boox to do some e-book reading while I was wondering whether a new branch would be required or not and then I ended up spending the holidays posting some very old drafts. Welcome to being 40: blog xor code.

well, nor the whole holidays, actually . I’ve still been able to do some ndsdev, just not the kind of things I expected. Tools are now stronger and more reliable. I’ve finally started to code something for it, but I need to figure out how I am going to test that.

edit 30/1: j'attaque...
edit 2/2: sprdo could help testing it.

Bilou Dream Land (codename)

Bon, j'ai plus ou moins déjà présenté l'idée, mais comme c'est un peu perdu au milieu d'autre chose je remets le couvert. J'ai décidé de mon prochain projet de jeu. Il s'agit toujours d'un jeu de plate-forme, et toujours aussi dans l'univers de Bilou. Mais ce ne sera pas "infinite Pyramid". Pas encore.

My 'todo map' for 2019 was trying to review all the things that could possibly use a bit of work, but had no clear direction of where to go.  For 2020, I finally have a direction to follow: a new game code-named "Bilou Dream Land" so far.

• Ce sera une version "courte" de Bilou's Adventure avec un début et une fin. Plus de gameplay en boucle cette fois-ci.
• On y parcourra la Green Zone, la School Zone, la Desert Zone et probablement la Peaks Zone.
• Les zones seront plus courtes que prévues pour Bilou's Adventure: plutôt la taille d'un niveau de Kirby's DreamLand (d'où le nom de code) que celle d'un monde de SMB. (ça fait quand même l'équivalent 2 à 3 niveaux de la version BASIC de Bilou's Adventure).
• Dans la mesure du possible, je reprendrai les level design d'origine, avec des adaptations pour corriger les 'injustices', mais je m'autorise à avoir des portes-magiques sans devoir les justifier.
• J'essaierai d'y introduire des boss.
• Pas de pouvoirs 'définitifs' à la Rayman, mais des power-ups comme ceux qu'on a pu voir dans School Rush, probablement avec un nouveau-venu qui fait grappin
• Les PNJs de la BD pourraient bien servir de "pouvoirs spéciaux" liés à une zone. Napin qui creuse, Froggy qui nage... vous voyez l'idée.

The idea is to pick four environments from Bilou's Adventure and use them to create a platformer that has the length, the rhythm and the depth of the seminal Kirby's Dreamland. I'd reuse existing level design as much as possible, like the 'anniversary School Zone' map and the sketched maps for Green Zone.

If we think of Bilou's Adventure as a Cave Story-like adventure with multiple endings based on player's in-game choices and actions, then Bilou Dream Land would be the set of levels you'd play if you'd go for an any-%, going for the quickest-to-reach ending where Bilou and Bouli barely managed to escape the planet, not trying to investigate anything about why they crashed and whether that world needs to be saved.

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.