It's a wonder

Bon, on s'était fait un deal avec mon frangin: il ne craquait pas pour Super Mario RPG et je ne craquais pas pour Super Mario Bros Wonder. Et comme les cacahuètes de Noël n'étaient pas en notre faveur, on se les offrait comme cadeau d'anniversaire. Je découvre donc le jeu avec 4 mois de retard sur ceux qui l'ont pré-commandé.

On ne va pas se mentir, il y avait pas mal de chose qui ne m'avaient pas convaincus dans les trailers. Mario-éléphant ? Peach-éléphant ? des fleurs bla-bla partout ? des tuyaux qui se changent en chenilles ?

There were numbers of things that did not convinced me at all in the Super Mario Wonder trailer. Like oliphant morphs (esp. for Peach, but Mario looks silly that way too), pipes turning into worms and chit-chat-flowers. But we made a deal with my brother: he wouldn't buy Mario RPG and I wouldn't buy Mario Wonder because we'd offer them to each other.

So since his birthday comes about 3 months earlier than mine, I'm discovering the game quite late compared to those who pre-ordered it. I did have a few hours to try it at my bro's place (yeah, the deal did not imply that *he* wouldn't buy Wonder for himself, and that's what happened at Xmas :P), and playing a few levels convinced me that there was a gold mine of gameplay ideas to spelunk there. And of world building ideas, because those wave-shaped islands and clouds are SMB3-level genious.

Mais un premier test manette en main à l'anniversaire de mon frère m'avait convaincu qu'il y avait aussi plein de bonnes idées de gameplay à creuser là-dedans. Et des idées de décor, parce que ces îles et nuages en forme de vagues pour le monde des îles, c'est digne de SMB3.

Fil à suivre...

Gob3D

There are some items in the school zone that would better be done with 3D objects. This is not quite new, but if I intend to have them in Dreamlands, likely it is time to consider them more seriously. At least, to identify the questions to be addressed.

• How do we define hitboxes for a rotating 3D object ?
• How do we define events that trigger when a given angle is reached ? (e.g. for state machine transition)

Je me suis laissé quelques petites notes pour quand il sera temps d'essayer de faire des objets 3D un peu plus ambitieux que les élastiques de SpongeBop pour Dreamland. Notamment des livres qui tombent et des lattes qui tournent ... Chacun d'eux ouvrant la porte à au moins tout un niveau dans mon carnet bleu.

Il faudra que je trouve le bon moyen de lier des zones de collisions aux objets 3D, pour commencer. Puis il faudra que je vérifie que j'ai bien compris comment marchaient les "display lists" pour la NDS ... Et accessoirement, faire une petite estimation du nombre "d'écrans" que compterait la school zone de DreamLands avec et sans les objets 3D, vu que pour la green zone, je suis déjà bon avec 2 niveaux ancestraux :-P

For the objects being considered here, it might be enough if rotations always happen around the origin of the model. A smashing book always rotates around its bottom line (X position irrelevant). A bridge book, around the middle of its bottom line (Z position irrelevant). A ruler bridge around its center of mass (Y position of the origin irrelevant). Sure, this does not capture all the possible things you might want to do with a 3D object in a 2D game, but it seems to be a sufficient start to me.

Now, last time I toyed with the idea of doing more than ropes in 3D, I ended up with the issue that anything that isn't hard-coded would have to use "glCallList", but I couldn't figure out how that would work. At last, I studied the registers used to control the 3D geometry engine (which turn out to match the gl* function almost 1:1) and noted that there are "command identifiers" associated with every 3D register. A call list is essentially a set of values to be written to GFX_FIFO. Writing to GFX_BEGIN (in order to implement glBegin) would be replaced by writing the command identifier for "begin vertex list", etc.

I could use a tool to craft these and adjust their parameters so that things look properly shaped.

edit: avec le "niveau de Rémi" et le niveau-anniversaire, je suis déjà à 36 écrans (contre 30 pour le 2eme monde de Kirby's Dreamland). Il y a au mieux 6 écrans à prendre dans le niveau avec tous les livres qui tombent et 2 à 3 fois autant à aller chercher dans les niveaux sans ces livres (mais avec quand-même quelque chose comme des lattes qui tournent et des bookmarks qui pendent). Je dirais que le plus raisonnable, c'est de garder les livres-3D pour un autre jeu.

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.
  

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