Slides testing

I've been re-drawing the water slides directly on the "three rooms" test screen, because it feels easier to prototype there than within the reconstructed green zone level. Then I've been prototyping different things about it that I had in my notes ... only mostly ruling out some options so far. For instance, the idea of re-using the sprite of waterjets to avoid issues with waterfall-to-slide transition should be forgotten ... it helped me coding something to select the layer where Gobs should appear ... one of the things I'll need for the smashing fist.

Another such test was placing some special tiles along the slide, in an attempt to make them trigger some "fall and slide on slippery ground". 

That failed. Almost completely. I had to create an empty animation just to avoid the normal "special blocks handling" from deleting chunks of the slope as soon as Bilou touched them.

I also had to drop the idea of placing "jet" tiles in an attempt to push Bilou harder out of the slope at its bottom : they allowed (but only sometimes) Bilou to hover the whole slide upwards ! 

May the demo be with you

Well, I can't really call it "a release", but there's something new waiting for you to download it on sourceforge: an update of the "three rooms" demo with more Applemen.

Stomp them, stun them, pick them, throw them. I won't claim that they're working flawlessly, but at least they're working, compared to the many attempts that took place last month.

It should also allow you to try the water jets and the hooking mechanics if you manage to find the "hidden" second green zone "level". And if my records are correct, this is also your first opportunity to face Bangbash yourself, because last demo was last year, just before I started working on making it move!

Oyez oyez! voici un nouveau fichier téléchargeable pour explorer vous même toutes les petites mécaniques de jeu qui ont fait le buzz lors des "Screenshot Saturday" de ces derniers mois! Ramassez et lancez des Applemen ! Défiez Bangbash ! Bondissez grâce aux branches, aux jets d'eau ! Accrochez vous aux racines !

La dernière fois que vous aurez eu autant de fun, c'est quand vous étiez dans une plaine de jeu !

Parce que, bin, on ne va pas se mentir, ça reste une démo-plaine-de-jeu pour vérifier que les mécaniques principales du futur "Bilou Dreamland" fonctionnent bien sans devoir traverser un niveau de 2048x1024 pixels pour s'en convaincre. Mais ... mais ça pourrait bien changer prochainement. 

Vous allez voir qu'il y a encore plein de petits détails pas au point, surtout s'il vous vient l'idée de lancer des pommes dans l'eau. C'est assumé. C'est parce que pour la prochaine démo, je vais me faire une version "brouillon" des niveaux qui sont déjà dessinés histoire qu'on puisse voir ce qu'ils donnent avec la physique actuelle de Bilou. 

October update

That week off has been pretty B-usy ... The 'three rooms' demo now actually feature 2 additional rooms, including one that is level-sized. There are still quite some things to fix, tileset updates, adjusting to .more loading, and the like... 

• [done] separate exit special block from fall-through-door special block,
• [done] stop flashing school background by applying waterfall palette cycling only in the green zone
• [done] adjust bounding boxes ... many bounding boxes.

Bienvenue dans un post-qui-change... ma petite semaine de congé d'automne aura été bien remplie de p'tits Bilous (entre autres choses), avec en objectif #1 l'ajout de deux "niveaux" dans la démo "Three Rooms", comme proposé en Mars. Evidemment, comme ils datent tout deux d'avant SchoolRush, il y a eu pas mal de mini-couacs à corriger pour éviter de se retrouver avec un niveau au décor psychédélique qui se termine dès qu'on casse une craie

Well, some recent development are incompatible with some old mistakes... especially bounding boxes. I remember being puzzled by what worked and what did not worked when I introduced the 'sand waves', which did require one bbox x y w h command to align the visuals with the slope ... but it really was almost blind guesses.

For some reason, the "box size" bits were ignored, and the "offset" bits were ... well, it will work better with offsets that says "pictures starts 4 pixels on the right in the 16x16 frame. Of course, fixing the size first made most of the offset wrongs until I've got new offsets computed.

Even after one more afternoon of map fixing, there are weird things happening in that school zone level, like 

• [todo, not critical] Bilou not always hidden by front layer (e.g. hidden if you jump, but not if you're idle or walk)
• [todo, not critical] Inkjets not moving up and down following rails

Le plus gros morceau, ça aura été de corriger le code qui permet à un simple sprite 16x16 d'être considéré comme étant plus grand ou plus petit ... une modification essentielle pour passer du furblock à la branche mais qui interférait avec les gouttes d'encres d'inkjet et les vagues de sable ...
Alors, voilà: un joli bouton vert vers une nouvelle démo à essayer chez vous. Bien sûr, ça reste très en chantier et vous trouverez pleins de trucs pas au point, mais au moins, les horreurs ont été éliminées. Rendez-vous en Décembre avec une démo incorporant BangBash ?

Ah, and it's not in the school zone, but [done] that ugly pink background showing up in the green2 level, too... I'd rather have that fixed before uploading a new demo...

edit: There we are: 2 work-in-progress levels can be found if you explore the three rooms properly. There is still much to do, but also much to explore if you've never launched anything earlier than School Rush.

map poked!

map.poke is done. Okay, it doesn't read "map.poke" in the level script but rather block (coordinates) = (hex) so that it mimmics the block (hex) { ... } definition. And that makes it specific to special blocks.

But there it is. After some branches untangling and more commits weaving, I could use it to add a secret exit in the trunk of the 'greent' room without having to go through the now-clumsy steps of patching the level on NDS while editing code on the PC.

Bon, je crois qu'il n'y a pas besoin que je vous dise que quelque-chose n'a pas marché, hein ? vous vous en doutez rien qu'en regardant l'image... En mars, j'avais évoqué la possibilité de reprendre les vieilles maps pour étoffer un peu "Dreamlands" (ou à tout le moins, proposer un peu plus de contenu pour la démo "3 rooms"). Et bonne nouvelle, j'avais fini par retrouver les maps en question. Je m'étais donc rajouter un peu de script qui dise "alors, le bloc de type 11, c'est une sortie secrète, et dans le niveau greent (le nouveau), si on la touche, tu charges le niveau greeny (l'ancien)". Sauf que pas moyen de tester, évidemment, parce que sur greent.map, il n'y a aucun bloc de type 11...

C'était donc l'occasion de se bouger un peu et de coder le mécanisme dénommé "map.poke", à savoir permettre au script d'aller modifier les propriétés d'un bloc du niveau sans rien demander à personne (et en particulier pas à l'éditeur de niveaux ;P). Et oui, la vie est telle qu'il m'aura fallu un bon mois pour que ces malheureuses lignes de code finissent compilées sur le PC qui avait aussi le fichier greeny.map ce matin. Tout ça pour se rendre compte qu'avant de pouvoir faire une "release" avec la vieille map n°1, je vais devoir lui faire un sérieux ravalement de façade pour l'adapter au nouveau tileset ^^"

Oh I presume you don't really recognize the big tree of my so old two-levels demo: since I re-structured the tileset, there are quite some editing to happen there before you can actually enjoy anything :P

Show and Birthday

It's been 10 years I've swapped jobs. It's been 10 years and yet most of my colleagues had never seen my little DS games. Working as a software developer makes it a bit harder to show hobby software to colleagues. Few of them know this blog, and those who do do mostly because of their intervention on the cxx or rongtudju categories. Most know I'm drawing things because I had some of my drawings displayed on the wall before we move to the new building.

And then a new batch of colleague joined, including one who's been doing a Flappy Bird clone on FPGA for a school assignment. They are the same generation as my S-team beta-testers, so I decided to pick my DS along at one social event, showed it to the young team... not much more than AnimEditor, but they were quite smiley about it. I did not have any ready-to-run playable demo on the device, though, and the cheese pot came in ...

That was a few months ago. Two weeks ago, I was visiting Ged's place. I clearly couldn't get there without my latest demo in my pocket. Well, not quite that version. The 'ongoing work' one, with a different tune for every world, but still needing fixes every here and there. He did enjoy it, though, and his 8-year-old son did enjoy some not-too-old version of SchoolRush. I've been told that it is a shame we can no longer catch the highest apples on the green zone, though.

Then there was my birthday, alone until 13:00 where Cyril came and play some Donkey Kong Tropical Freeze ... and check the latest progress on Bilou. And I knew I'd bring some "cookies" at the office the day after. I typically prefer to make it so people can come and meet me at the coffee machine rather than just drop the stuff and disappear... So I decided it was about time to show them Bilou as well. 

Most of my team were pleased to give a look at the game, a few of them played either 3-Rooms (.nds) or School Rush, and among those who did, none found it obvious that GRAB is GRAB instead of PUNCH. I might want to do something about that before I make a release of DreamLand... A few colleague actually tried to beat level 1 of School Rush and one even managed to reach level 2.

In other teams, there were of course some colleagues to find it odd that I do that with a Nintendo DS rather than going for Androïd or Nintendo Switch. The recent court face-off between Big N and the team behind 3DS and Switch emulators doesn't really speak in favour of retro-homebrew approach ...

Final round was yesterday with my even-younger-nephews who wanted to try 3-Rooms after I shown it to my brother for music selection approval. Last but not least, that triggered a question from the 15-y-o Tango nephew who was curious to know where he could download the tools I used to build the demo and asked whether programming was required to create new characters.

Reprendre les vieilles maps ?

Surprise quand j'avais fait le tour de mon cahier "level design", je n'ai en fait que 2 niveaux et demi candidats pour la Green Zone. Alors que le jeu en BASIC donne l'impression qu'il en comptait 5. Mais certains niveaux (dont celui baptisé "les grands arbres") ont vraiment mal vieilli.

Alors pourquoi ne pas inviter à la fête les maps de la démo 9/9/9 ? Elles auraient besoin d'un peu de vernis, mais elles pourraient faire l'office d'écran pour apprivoiser les mécaniques du jeu avant d'être lancé dans l'historique niveau 1 de la forêt ... 

The goal for the Green Zone of Bilou's Dreamland should be around 26 screens (that's Kirby's Dreamland world 1 size). I have only 2 levels of Bilou's Adventure that seem mature enough to be included ... A bit light if you ask me. But I do have 2 small levels drawn for the earliest GEDS demo back in 2009 that might be welcome, either in the 'dreamland' game, or in the 3-rooms demo.

They might feature a bit too much of Funky Funghi, but some of them are in interesting settings, like in that 2nd level with chunks of dirt here and there that are only waiting for bridges to be tested... So I went for a poll, and 3/4 responders picked "go for inclusion" while the last person would prefer those maps to be exclusive to the 3-rooms demo.

Et le 2eme niveau de la démo, avec ses petites plate-formes et ses funghi partout serait le terrain rêvé pour introduire les ponts et jouer un peu avec. Et si la question n'a pas suscité de débat remarquable sur twitter/mastodon, il y a au moins unanimité sur le fait que les faire intervenir au moins comme terrain d'exploration supplémentaire depuis la démo "three rooms" est une bonne idée.

• [done] import cube:/home/grizzly/pype/codinDS/dsgametools/schem.map 
• [done] import cube:/home/pype/hobby/R4-bakcup/GREENY.MAP
• [done] import cube:/home/pype/hobby/R4-bakcup/GREEN2.MAP
• [done] see what they look like
• [todo] bring them back on NDS so they could be fixed with up-to-date tileset.

 

Demo: Scorpeye, Apple, Water and Sand

A new demo appeared. At last, my checklist is complete (and sure, there are still many more things to write for a next list). The demo is still based on the "three rooms" -- mini-maps barely larger than the screen, each presenting one of the zones the full game should provide. Don't expect much more land to explore. I still have a few concepts to prove before I can do that.

Enfin direz vous, et je ne vous contredirai pas. Voici la nouvelle démo de mes travaux en cours sur Bilou's Dreamland. Toujours limitée à 3 salles à peine de 2x2 écrans qui servent pour expérimenter les nouvelles mécaniques sans passer trop de temps à courir jusqu'à la nouvelle fonction à tester. Mais pour la première fois, vous allez pouvoir nager, affronter les sables mouvants, lancer des carapaces. Et puis il y a toujours le rodéo d'éponge et le saut en encrier. Allez, quoi. Sortez votre linker et faites-vous plaisir :)

Compared to the previous demo, you can try

• the new appleman animations
• the collapsing platform (pyramid)
• the scorpeye shell (jump on the scorpeye, then grab it like you'd do with a blador)
• flowing sand, pushing you down the slopes
• improved swim mechanics, waterflow
  

tested on NDS Lite, desmume 0.9.11 and desmume 0.9.6

Feel like playing a real game ? Try my previous titles ;)

Sand "waves" completed.

Bien. Ce coup-ci, je pense qu'on y est enfin. Le sable tombe, il fait un petit tas, le tas croule le long de la pente, puis se "dissout" au moment d'arriver à la chute suivante. ça reste "mode démo", celà dit: le code pour la pente à contresens n'a pas été testé et la longueur de la pente est hard-codée dans la "l'animation" de la vague qui descend. Mais ça fera l'affaire.

At last. Sands falls down, piles up, flows down slope and then falls again. The illusion is complete. The code is partly production-grade, partly demoshow-grade. Just what I need for a new release of the 3-rooms demo ... if only there wasn't that just-popping-up bug in the School room >_<

Over-engineered ?

Maybe I'm starting that "swim made fun" thing by the wrong end. What I really need is to be able to move Bilou through water and to get him out of the water. Sure it is fun to swim in Rayman Origins, it was pleasant in DKC and a nightmare in TNMT on NES. But unlike all these games, I have no "water level" planned in Bilou: Dreamlands. The reason why I started working on dash-in-water is not because travelling through water would feel empty without it. It isn't even because I have level sketches where jumping out of water is a key mechanics. It is solely because in the current demo, you can't reach the green room exit unless you trigger an unintended double-jump with precise button mashing that should be left to speedrunners.

J'avais donc un beau projet pour les mouvements dans l'eau. Je venais de commencer à ajouter "on accélère si on appuie sur JUMP" et J.L.N a pris "la manette" en main. Il a nagé à droite. Il a nagé à gauche, puis il a voulu sortir de l'eau. Et bien sûr, lui n'a pas attendu que Bilou revienne à l'état "je patauge en attendant" avant de presser le bouton de saut: il l'a fait depuis l'état "bilou nage à gauche", là où j'avais prévu un "fonce dans l'eau vers la gauche" en réaction au bouton "pied"... Bilou n'a donc même pas tenté de s'élever d'un pixel. J'avais échoué le test n°1 de Miyamoto: "the JUMP button makes Jumpman jump". Et donc je me suis enfin posé la bonne question: "Est-ce que j'ai vraiment besoin de tout ça, moi?"

Parce que dans mon cahier bleu, avec les croquis de level design que j'ai l'intention d'utiliser pour Bilou's Dreamland, l'eau est bien présente, mais je n'ai jamais un "niveau aquatique" à proprement parler. Ce qui motive cette recherche sur les mouvements dans l'eau, c'est juste le fait que la berge est trop haute dans la démo. Et donc, garder une mécanique simple "JUMP" à la surface = sauter hors de l'eau et sauter hors de l'eau près de la berge = sortir de l'eau serait impeccable si j'éditais un rien l'écran-démo pour que sa berge soit un tile plus bas ^^" (et éventuellement que j'augmente de 15% la hauteur du saut depuis l'eau, actuellement défini au doigt mouillé)  

I wanted to use the opportunity of changing the level map to also fix an issue I had with the interaction of surface-swimming and following the water flow. I presume that the core of the issue is that the *middle* of the character's bounding box is used to determine whether there's a flow to follow. But "stay at the surface" code maintains Bilou above the flowing tiles. As soon as one pixel of the box enters the "full water, flowing downwards" tile, it starts pushing Bilou upwards.

I made a few bad moves, like trying to have full-water-flow-downwards tiles higher (closer to the surface), but that didn't work at all. Instructing the level that "water-flowing-downwards" can be felt through did work pretty well, I think.

Pendant que je testais cette nouvelle map avec sa nouvelle "berge" moins haute, je me suis rendu compte que depuis qu'on sait nager à gauche et à droite, les remous de la cascade ne nous entrainent plus vers le fond. La flottaison est trop efficace et le centre de Bilou n'entre plus dans la zone qui le tire vers le bas. J'ai un peu chipoté, mais heureusement, il suffisait de permettre à Bilou de "tomber" aussi dans cette zone pour que tout rentre dans l'ordre (enfin, je pense)

area %d = anim %x

Bon, franchement, je me demande depuis quand ce problème attend que je m'y attelle... que ce soit mon blog, twitter ou mon calepin, impossible de trouver une date correspondant à "oui, la plate-forme se reclappe, mais quand je me mets plus sur sa gauche, je passe à travers.

J'imagine que ça fait partie des choses qui m'ont motivé, fin du mois dernier, à faire en sorte qu'Inspector Widget marche à nouveau dans la démo "3 rooms". Et la visualisation des zones de collision m'avait porté à croire que j'avais mal défini les zones de collision dans l'éditeur, sur NDS.

At some point, I noticed that InspectorWidget wasn't working anymore in Dreams.nds ... not quit ideal when you're trying to add bits of gameplay to your years-long-under-development demo. Especially not when you barely manage to get more than 1 hour of gamedev at once. And after I managed to get it back, I suddenly remembered that seeing Bilou falling through the flipping platform was nothing new and that it was linked to the platform having bad hitbox.

Parce que oui, ayant la flemme de définir les zones à la main, cette 'crocforme' est (avec la branche-qui-rebondit), un des premiers objets du jeu à importer une zone de collision passive directement avec area 0 = anim ${FLAGS}, plutôt que d'en fixer explicitement les coordonnées comme j'ai fait avec Apple Assault et School Rush.

Sauf que sur DS, les hitbox sont parfaites. Rien à redire. Je re-transfère le fichier (le lendemain), des fois que j'aurais oublié que j'avais déjà corrigé le soucis. Je recompile (le surlendemain), je teste. Pas d'amélioration. On est samedi, je sors l'artillerie lourde: une nouvelle instruction `break` pour le langage de script histoire de pouvoir mettre un breakpoint dans ddd et commencer à inspecter le comportement du parseur de script pile là où ça coince: dans la boucle qui lit les commandes 'Define' de l'animation où on fixe les coordonnées de la zone solide et des hitboxes pour l'animation.

At first, I thought I had just messed the hitbox within AnimEditor for DS. But a few checks and WiFi transfers later, it turned out that no: the data (as far as the editor was concerned) was ok, but the game still would use the bad hitbox. Checking that on the parser would be darker than night -- or so I thought. This is how the parser now supports an additional "break" instruction that is a noop where you can set a gdb breakpoint while parsing things. These are not meant to be committed, of course, but it definitely helped.

A few 'next instruction' later, it turns out that my engine is using tool-absolute coordinates for the hitbox instead of object-relative coordinates. That is, when you edit an animation in AnimEDS, you don't only store how to use it in-game, but also what you need to edit it again in the editor, and that includes where to put each component on-screen in the editor. The character's center and the edition widget center may match, but they don't have to.

Le code qui gère ça n'est pas tout neuf: il a permis d'améliorer les hitboxes pour attraper les objets dans SchoolRush il y a près de 10 ans. Mais j'ai commis l'erreur de copier-coller le code plutôt que de faire une fonction "importArea" qui serait utilisée des deux côtés: pour les zones actives et les zones passives.
ça n'aura donc pas été trop compliqué de faire en sorte que les deux utilisent le même bloc de code (le bon) et d'avoir une plate-forme qui fait *enfin* ce qu'on attend d'elle :-P

J'espère que je passerai un peu plus vite de la découverte du problème à la recherche de sa solution, la fois prochaine ^^"

If I want to fix that, I need to track not only hitbox#n ORIGIN coordinates, but also those of the 'solid' box -- the one used to decide whether the object cando() something. then when one 'ORIGIN' instruction shows up for the area we're interested in, we create relative coordinates. Hopefunny enough, it turns out I already have code that does precisely that, because I have both active and passive hitboxes and I failed to avoid repeating myself when writing the original parsing code ... and later failed to fix both copies when I realised things were not going as they should have.

3 rooms on 3DS

Novembre 2021, un rétro-fan nommé Fei m'invite à rejoindre un chat francophone qui accueille déjà un certain nombre de mes contacts twitter versés dans le rétro-coding. J'y ai fait quelques apparitions, mais je dois bien admettre que j'ai du mal avec la formule 'discord' qui a tendance à semer la confusion dans mon esprit.

Du coup, quand j'ai une nouvelle petite démo avec les 3-salles, bin je leur poste le lien, pour avoir un peu des retours. Sauf qu'à l'époque, la plupart des dev' qui ont un matériel compatible avec les homebrews NDS ont en réalité une DSi ou une 3DS... et là, bardaf: écran bleu.

J'en arrive assez rapidement à la conclusion que le fautif est le support des vieux linkers utilisant le port GBA (qui est absent des DSi et 3DS). Les tentatives de lectures sur la plage d'adresse prévue pour le "gba slot" provoquant des exceptions hardware. Mais même une fois ce code-là commenté, toujours pas moyen de faire tourner la démo. En fait, le code n'a pas trouvé les fichiers de données "intégrés" au .nds avec l'Embedded File System de Noda. Fei utilise le "Twilight Menu++" ... je creuse un peu mais fin de semaine, je n'ai toujours rien. Perso, ma 3DS n'a encore jamais vu de homebrew de sa vie (malgré l'acquisition d'un OOT3D) et j'ai oublié comment je faisais tourner des homebrews sur ma DSi avant que ses triggers ne me lachent. Le tourbillon du printemps 2022 va emporter tout ça au pays d'Oz dans l'oubli.

My bad. Really. It would not have taken me one whole year figuring out why my homebrew wasn't running on DSi and 3DS if I had not been messing with the ndstool settings in an attempt to avoid 'twl' headers. I started studying how any exploit on DSi seems to ultimately rely on something called 'generictwlpayload' to launch devkitpro/bootloader. But chances are that if it does not find some specific signature in the binary, it will fail to inject hooks to e.g. SD card reading.

Anyway, this is *so* satisfying to finally see someone else (Fei, this time) being able to run my demos again. I hope I will find a way to make it compatible with desmume as well and quickly manage to backport that 'fix' to some SchoolRush build... just in case.

With --slot1 R4 --slot1-fat-dir /tmp/fat
/tmp/fat/Dream.nds, it now works.

Mais là, ce week-end, pour voir comment je peux m'y prendre pour faire des tapis roulants, je me rends compte que mon mercurial sur sourceforge n'est pas à jour. de plusieurs mois ^^". En regardant de plus près je retrouve une micro-branche qui reprend mes tentatives pour corriger le problème. La différence, c'est qu'entre temps, j'ai été démarché pour une version "cartouche" de SchoolRush. Et que j'ai commencé à essayer de comprendre comment faire tourner des homebrews DSi sans linker, encouragé par un post sur hackaday qui promet un mécanisme ne nécessitant ni jeu particulier ni modification permanente. Juste un p'tit serveur web et le navigateur intégré au firmware. (j'ai encore un peu de codestudy à faire dessus, mais on y reviendra).

Tout ça pour dire que j'avais une idée bien plus précise de "twl = indispensable pour démarrer quelque-chose sur DSi" qu'il y a 4 ans quand j'ai fait la mise à jour de mon devkit. A l'époque, j'avais d'abord remarqué un gonflement de tous mes programmes, puis une incompatibilité avec desmume. Le coeur du problème, c'était un changement de fonctionnement de l'outil ndstool mais en voulant "forcer" le support de desmume, j'avais aussi sabordé le support des consoles DSi et 3DS. Une petite marche arrière et Fei est maintenant en mesure de faire tourner la démo "three rooms" sur sa 3DS ^_^.

Voyons donc si je peux aider desmume à comprendre ces "nouveaux headers" si chers au TWLoader, sans lesquels il n'essaie même pas de faire le patch DLDI des softs qu'il charge... encore que ... en 2016, je pointais que desmume n'avait plus besoin de --gbaslot-rom pour faire tourner SchoolRush ... à creuser.

edit: 3/4: With some GameInfo::isHomebrew() function located, I thought it wouldn't be too hard to allow dsi-enabled .nds to run with desmume, but that was not the problem (not with 0.9.14, at least). The problem was more with DLDI patching. Unfortunately, the handlers checked by slot1_GetCurrentType() are not yet registered into slot1_list[] when you invoke desmume --slot1 R4 Dreams.nds. Adding slot1_Init(); slot2_Init(); at the start of CommandLine::process_addonCommands() definitely helped.

Edit: 8/4: For some reason, slot1 is super-slow in the emulator. I'd like to try slot2 instead, but the GameInfo structure is full of zeroes since NDS_LoadROM() has been called. A preloadROM function finally allowed using --gbaslot-rom and have it recognized as a homebrew, but that still did not allowed libfat to find files.

Conveyed ...

It's not a surprise (or it shouldn't) if there are waterfalls and sandfalls in the Three-rooms demo. And especially, if there is ground between two of them. I want my game engine to be able to 'push' you when you're on some ground, like it would if the ground was actually a conveyer belt. And it's been a few years now that using sand/water falls for that integrates better than mere mechanical belts in most levels. 

I have notes in my notebook for quite some times, too, about how the game script should indicate what those blocks do. They're not quite "special blocks" (that interact with collision code), but rather "physical types" that could be polled by frame-per-frame controllers.

I'm not completely satisfied with the proposed syntax, though. I'd rather use type %d {...} and is %s "%x" for level editor identification (like for block %d {} describing interactive special blocks), and I'd use props %x, like we already have for special blocks.

The truly innovative part is %s.%s = ... pattern to setup variables into controller factories. That one will be a bit more complex to get running, because the map of factories is actually managed directly by the GobState class, and I'd rather not re-inforce the Using... anti-pattern here.

crocform #1

You may remember I had plans for a larger variety of platforms in the desert/pyramid zone of Bilou Dreamland. There's a second flavour of the crocodile-inspired platform that I barely shown so far, but which got a significant role to play in the work-in-progress level design. Unless you have some sandfall around, it is merely behaving as a "disappears after some time" platform. With sandfall, it adds "respawn" to the mix.

Last week end, I finally got to the point where I wrote some script to give it existence in the ongoing 3-room demo. There's a thing that went significantly wrong, though: Bilou couldn't notice when the platform is gone.

La pyramide, c'est l'endroit idéal pour des plate-formes un peu particulières. Qui croulent, par exemple. Ou qui changent d'orientation. Mais quand j'ai voulu faire un p'tit essai dans ma démo actuelle, Bilou est resté gentiment à attendre que la plate-forme revienne, flottant dans le vide. En réalité, il me manque un évènement capable de "décrocher" Bilou de la plate-forme: puisqu'elle existe toujours, pour le jeu, on peut toujours marcher dessus.

Il y aurait plusieurs moyen de régler: Bilou peut déjà se faire "propulser" par une collision (hic: seulement s'il n'est pas au sol). Les dumbladors empilés détectent quand l'un d'eux s'en va (hic: seulement grâce à un contrôleur dédié et l'ajouter ici décalerait tous les évènements de Bilou). Au final, c'est le contrôleur testant si on est sur une plateforme que j'étends pour qu'il puisse tester un bit d'état de l'objet auquel on est attaché..

I've had a similar issue with dumbladors when time came to 'stack' them: when one recovered, those stacked on top of it had somehow to detect they'd no longer have a platform behind them. It would be trivial if the gameobject implementing the platform was destroyed, but here it stays around.

• extend dumblador's extra gobbit(when 7.1) to Bilou
• trigger an extra "throws up" temporary hitbox when flapping down the platform
• implement it all with brand new "larger animated blocks" feature, not with a sprite, because that platform doesn't truly "move".

The temporary hitbox seemed to be the least-resistance path, so I gave it a go. But unfortunately, it led nowhere. Mostly because the already-implemented collision I was trying to reuse (that use to make Bilou bounce of erasers, for instance) is only tested in states where Bilou is airborne. Here, I'd need it in states where Bilou is supposed to be on the ground.

Yet, I hesitate going for an additional micro-controller gobbit (despite it already has C++ code) because that would introduce new events to deal with. I'd rather have the onpath controller be able to fire an event when the platform-object it is attached to signals it is no longer a platform, the same way the controller can signal the object no longer exists.

I could try having some automated test into 'onpath' that would ensure the current state of the 'platform' object still has the area active and using the proper flags, but that would require extra care if I don't want Bilou to behave weirdly when the platform turns back or does any state transition that don't actually imply losing its 'platform' behaviour.

reality check: using onpath(when w7.2); (from the worst-possibly-named commit)

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.

Three tunes

Having three different visual environment for Bilou's Dreamland's first demo is one thing. I'd like to given them distinct musical background, too. That was last week-end's target, but unfortunately, it hasn't been very satisfying.

Sure, I could get 'school rush' theme played while being in the school room, and 'Apple Assault' theme while being in the green room (sic), but the loading time between them became quite excessive. Even if I expect this to happen only at 3 different time in the game, being completely silent and blank then is a no-go.

The second issue is with sound effects. Apple Assault used simple samples to play sound effects for e.g. jumps, stuns and the like. School Rush instead had mini-patterns with 3-4 tracks to produce the desired arpeggios and effects from ultra-basic sound palette. Of course the green zone tune did not featured any of this.

 The third and final(?) issue is an endless loop within the memory manager. Most likely, something's wrong within libNTXM memory management (or in my messed' up clone of it) which never showed up since I was playing the same module over the whole game's lifetime in previous installments.

Eh bin ... ça en a fait, des choses à fixer pour pouvoir passer d'une musique à l'autre au sein d'un même programme basé sur GEDS. Entre les makefiles, la bibliothèque NTXM elle-même, les p'tits soucis de parser et les modifications à apporter aux scripts, heureusement que TortoiseHg était là pour déméler tout ça au moment de faire enfin des commits.

C'est encore hautement perfectible, notamment au niveau des temps de chargements, mais si je veux avoir une première version jouable de Dreamland d'ici la fin des primaires de J.L.N., il va falloir que je me concentre d'abord sur le reste.

So I've been trying to see where I could have poorly managed memory ... something that would explain how the loop appeared, but given how shielded the memory management code already was in libntxm, I started doubting of my own deductions.

Then the emulator suddenly decided to give me addresses and register dumps! Huzzah!... but they were all for the ARM7 core.

It turned out that, no matter whether you invoked NTXM9->stop(), the timer interrupt keeps running and it keeps checking for the NTXM7->song pointer and dereference it. Simply, all channels are turned to mute, or something alike when you've stopped the playback on the ARM7. Note that background color for the top screen turns to weird orange when this occurs.

And of course, the ARM9 code would delete() that song before it sends the 'set song' command to the ARM7, meaning that the ARM7 core would start using recycled content to guide how it should work (including objects and VPTRs!) ... Pretty weird to see shared virtual tables between the two co-processor of a console, btw. Don't try to do that with the M68000/Z80 duo of Megadrive development.

• step one: fix the .cmd so they use SFX that suit with the loaded level
• step two: find a way to share revamped SFX through levels
• step three: find a way to hide music loading latencies.

Don't start addressing step three before you get the 'three rooms' demo running and you're ready to encode levels.

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.

3-rooms todo board

The 'todo board' for School Zone worked quite well. Maybe I should make one for my "3 rooms" milestone, given how unlikely I am to do large amount of work for homebrew project these days...

(Well the milestone description for "3 rooms" is in itself a sort of todo-board; just focusing less on what is not going well right now)

And in case you see Bilou heads all over the place again, make sure you get a look back at that Bug Punch post...

Un montage graphique pour me rappeler de ce que j'ai à corriger, ça n'avait pas trop mal marché quand j'avais démarré la School Zone. Je me dis que ça pourrait marcher aussi pour mon challenge des "trois téléporteurs" ... Tentons, donc.

pyramt.map

Files transferred. Last week, I had just complete mess of tiles, some even not part of the file, but things remaining from the previous level. Hopefully, each of these level worked fine in the level editor on the NDS.

With a bit of tweaking, I could also get the shown in runMe. After I remembered I had a button to show the loading log in case of failure, I realised I had a few files missing (mostly .gam files) and I could get school title screen working with sprites as well.

But as far as pyramids and green zone maps are concerned, I'm still trying to get them working. Dreams.nds itself triggers a blue screen somewhere in GobAnim::translatecommands.

Avec un peu d'astuce, je peux maintenant avoir un niveau "pyramidesque" dans l'éditeur comme dans runMe. Pour runMe, il aura fallu que je me souvienne d'activer l'affichage du log (parce que oui, il est toujours là, juste caché), histoire de réaliser que la DS n'a pas le fichier .gam demandé. L'éditeur de niveau peut passer par-dessus un problème de ce genre, mais pas le moteur de jeu. 

One thing, though. It's nice to have a memory crawler embedded into my exception handler, but I should make sure it doesn't trash the precious registers I had on-screen when I'm exploring invalid addresses (first, because it is impossible to hop from 0x0b00xxxx stack addresses to 0x020xxxxx heap/code without entering some invalid addresses, and second because moving down to higher addresses makes the DPAD to enter addresses confusing at best)

Dreams/efsroot/*

Premiers pas vers mon objectif des trois "téléporteurs": j'ai une structure capable de produire un .nds qui comporte aussi bien les graphismes de la school zone que ceux de la green zone, avec un bilou.spr partagé entre les deux et la possibilité de passer de l'un à l'autre pendant un chargement de niveau.

Bon, j'ai eu droit à mon compte de p'tits bugs pendant que j'ajustais les pages de sprites à utiliser pour les monstres de la green zone, évidemment.

Et si une grande partie de ces défauts sont maintenant corrigés, il reste quelque-chose de travers avec la gestion des palettes. Pour la school zone, bilou.spr et school.spr contenaient exactement les même palettes, mais green.spr en a une autre. Et essayer d'afficher les applemen avec la palette des pendats donne des résultats pas tout à fait esthétiques.