xmas21.zip

I finally posted something more on my sourceforge project: the set of editors (plus runme) as I've got them by this Christmas, invoking oven-hot slopes support.

I wish I could provide you with a meaningful 'change log' for this 'release' of my tools, but let's be

honest: there are over 20000 lines changed between then and now (assuming that you're only interested in what changed since last AnimEDS release in 2020). It won't be exhaustive, but I'll try to give you an idea of what's in anyway.

Sprite Editor

• allows you to work on any file you've got on your memory card (including automatic backups put in /DATA/SEDS/*)
• better 'colors zapping' implementation.
• 'where is that color used?' now cleanly implemented in the PaletteWindow
• (improved host tools sprdo and sprck are missing from this pack)

Animation Editor

• allows you to work on any file you've got on your memory card. 
  

Level Editor

• uses new map layout with dedicated PHYS layer (accidentally named 'SYHP' in the file >_>)
• show the 8 color palettes when selecting a block in DRAW mode (A). Color paint mode now available on both foreground and background layers (trigger with L+A on the desired layer)
• supports new any-sized special blocks with 'lookup arrows', features revised 'meta buttons' widget to select tile properties.
• reads new 'slopes %d = "%x"' hint in .cmd or .gam files and populates the slope tiles graphics accordingly. Different maps can use different slopes or share them by importing the same .gam file.
• supports spritesets and tilesets overlay commands

runMe (gameplay preview & WiFi transport)

• Allows live-skipping of buggy script lines
• allows auto-repair of the /moving/ directory
• features new level map engine
• supports script-driven song swapping with zik.file = "%s"
  
• Improved modplayer playback speed stability
• supports spriteset overlays (spr.more "%s" ...) and tileset overlays (bg0.more "%s" ...)

All these .nds files will work from anywhere in your flash card, but if you install them with their original *dlta.nds filenames at the root, you'll be allowed to hope from one tool to another with the embedded buttons (quit, LEDS, SEDS, MEDS) in the application welcome windows.

Ludricous Speed

 There's another bug with my modified version of libntxm. It has been around since at least early School Rush prototypes and possibly even Apple Assault. If you let the player spin for too long, it suddenly starts to play things at ridiculous speed that makes the song barely recognizable.

I had the Dreams demo running with ARM7 debugger plugged in for another reason (undefined instruction) and it started speeding the song up so I dropped all my kitchen stuff and jumped on the CTRL+C to be able to dig that later. And later is now.

One symptom of the issue seems to be that the tick_ms variable is now way larger than the MsPerTick() property of the Song.

Every time the playTimeHandler() is invoked, it recomputes how many milliseconds elapsed since last call, and here I get the value of 1. It won't get out of the issue because there's nowhere we could read tick_ms = 0. Instead, the amount of time expected is substracted from the time elapsed so far, so that 'extra milliseconds' are deduced from the next 'tick'.But watching that tick_ms evolve, it is properly decreasing. It has not just been gone wild. It got corrupted from something else.

It doesn't tell me what goes wrong in the soft, unfortunately, but at least, it gives me a way to make sure players won't experience it. If I cap the tick_ms to 2*MsPerTick(), I shouldn't have issues.

Note how buggy tick_ms is close to last_ms ...

Note how unlikely it is that the player has been running for 43509 seconds. I wasn't even running it for one hour! And when it eventually occured again, lastms was 43494543, or something alike (decimal, not hexa).

Seeing some more code featuring 'compute over 100' now makes much more sense. 100 times higher than 43 million, we're quite at MAXINT for an unsigned. Plus, if you've got an unsigned, comparing -t to something might very well produce something that is compiler-dependent. Likely, there might be a switch to produce a warning for that.

Il y a un truc qui me chagrinait, avec School Rush: au bout d'un certain temps la musique partait en vrille. Le problème se posait uniquement au bout d'un temps assez long, du coup, je n'avais jamais eu l'occasion de prendre le temps de chercher le problème. Mais hier, j'avais un débuggeur ARM7 prêt à fonctionner, un émulateur branché dessus avec le code qui 'là-normalement-ça-devrait-marcher' pour un autre soucis et j'étais en cuisine ... donc ils ont tourné pendant longtemps sans intervention ... assez longtemps pour que le problème de School Rush se produise. J'ai bondi sur mon ordi pour interrompre tout ça et débugguer enfin cette histoire.

Au premier tour, tout ce que j'ai pu dire c'est que "bin c'est parce que tout d'un coup, on découvre qu'on est en retard de plus de 40 millions de microsecondes pour passer au 'tic' de musique suivant". J'avais espéré qu'il s'agissait d'une déviation ou quelque-chose de ce genre, j'avais mis quelques 'break if...' dans ddd mais quand le problème s'était finalement re-reproduit (bonne journée, ça), on était passé de quelques millisecondes de retard à plus de 43 millions, comme ça, sans-transition-à-vous-les-studios. J'en venais à me dire que 'tant pis, je vais juste mettre un patch qui limite artificiellement ce délai' puis je tombe sur l'implémentation de la lecture du temps à partir du hardware qui cache une division par 100 ... et 100 * 43 million, on approche du plus grand entier 32 bits. Là, ça pue le bug de conversions arithmétique dû à une soustraction mal calibrée... ça je pourrai corriger pour de bon.

Peaks'n'Beaks

Pour l'instant, je reste sur l'idée que la zone "des cimes" (montagnardes) ferait une bonne zone finale pour "Bilou Dreamland". Mais c'est pas tout d'avoir une idée de zone: il faut encore la peupler. Attendez-vous à avoir quelques bestioles inspirées de boucs, mais aussi de piafs plus ou moins agressifs.

Il faut encore que je trouve le moyen de le dessiner en train de voler, par contre.

Pour ce qui est du look des niveaux, j'ai été un moment tenté de m'inspirer du niveau de Meta Knight dans Kirby Stars Allied, mais à la réflexion, je le trouve trop cahotique.

Enfin, est-ce que je peux faire un niveau des montagnes sans jouer la carte de la caverne-dans-la-montagne ? On est pas franchement dans le thème du 'à-fond-platforming' pressenti, c'est vrai. Mais à force de visiter des grottes, ça devient de plus en plus tentant. D'autant qu'il suffit de couper un chou pour avoir un level design de grotte ^_^

PlaySFX vs. PlayInst

 

Je refais un peu d'explication-BD parce que là, c'est un brin compliqué. Le mécanisme que j'avais ajouté pour faire des effets-par-pattern, je l'ai poussé un peu trop loin.

Au départ, c'était bien vu: un ensemble de flags permettant de dire si on doit suivre la "partition" normale du module ou continuer à avancer dans la piste en cours jusqu'à trouver un effet 'pattern break'. Mais il y a un cas que je n'avais pas en tête à ce moment-là: les effets 'normaux' fait d'un p'tit sample tout seul. Eh oui.

Dans ce cas-là, la piste sur laquelle on met le sample n'a normalement pas de contenu. Depuis le nouveau code, elle est ignorée puisqu'au-dessus du nombre de pistes définies dans le fichier .xm. La seule exception à cette règle, c'est pour les pistes qu'on a attachées à un morceau de piste d'effet.

Disclaimer first: many of the things I'm now doing with libntxm are far beyond what it was designed to do, that is running a soundtracker on the NDS. When thigns go wild because I stop a song and replace it with another before the Player class on the ARM7 get any chance to run its every-millisecond handler routine, I'm worse than a TAS-speedrunner producing superhuman inputs on the software. Right ? Same when I feed the Player with two patterns simultaneously and going 'yeah, play pattern 9 on channels 1-12 while at the same time playing pattern 27 on channels 14-16, will you ?'. None of this was part of the original plan, and that's perfectly natural. It's up to me to make it work if I want it to work.

Ça, ça marche bien pour le moment 'lecture de la nouvelle cellule (note) dans la ligne'. Mais si on veut qu'un p'tit son puisse être joué, il faut qu'on continue à faire des calculs d'enveloppe, la gestion des registres de volume. C'était déjà un peu à ça que servait le flag channel_active. Il reprend du service.

Bon, là je me suis limité à un p'tit test tout bas, parce que ma fée est pas ultra-fan de StrTrk et que c'est l'heure de la p'tite série qu'elle aime bien à la télé.

So a few weeks ago, I fixed a crash in the ARM7 code with 'oh, I know: I'll give NTXM player a NULL song first, and then delete-and-create another one'. Not a bad idea in itself, but I missed a few things that the player has to do even when I change the song, like progressively muting the channels when there are no more notes to do. Obviously, I shouldn't prevent it from doing so even though we activated the NULL song.

I also finally implemented an if-block for the GobScript (it turned out quite simple thing to do) and tried to use that so that we'd use pattern-effects only when playing a tune with such patterns, and play plain-samples-effects otherwise. Nice try, but it turned out that no sample was playing at all. That was because of my previous changes again: when playing such lone samples, we're perfectly right to do so on channels that are not present in the song. (Actually, we should better do so). But the code from SchoolRush would only start playing a sample if there was a pattern Cell to back it up. Either a regular one, or one from a pattern-effect. I had to identify the tasks where that test was mandatory (e.g. when processing effects or advancing to the next row) and tasks where it shouldn't be used (process volume envelopes, start the sample, turn down the volume when done playing the sample, etc.)

Reste à espérer qu'avec les corrections de 'quelle musique jouer quand' et 'okay, on a plus de partitions, mais continue quand-même à baisser le volume', ça suffise pour que les musiques de la prochaine démo soit un peu plus sous contrôle.

Ah oui. Et au cas où, ces choses en forme de tentacules (Bob) sont des statues-registres.

And after all ... here's my waterfall

After almost 3 weeks of quarantine, I knew I was going to see my brother again. He stated the new 'release' looked fine, and I wanted him to see the animated version I had in mind. So I did my best to get that done by the end of the week, although this is hardly of any emergency in the not-yet-written list of things to fix in that build. I mean, yeah, the water is more convincing if the falls flow, but we can walk on it anyway, so ...

Premier changement par rapport à la démo téléchargeable: animer la cascade. Ouais, je sais c'est clairement pas le truc le plus prioritaire, mais c'est un projet-hobby, donc la priorité, ça doit rester de se faire plaisir. En plus, je tenais un créneau pour montrer ça à mon frangin, alors autant lui en mettre carrément plein la vue, non ?

I wanted the waterfall not to look like a simple scrolled tile, so instead I scrolled two layers independently, at different speeds. Yeah, I know this is quite cheap. Well, I also gave 'noise' variations in the frames of the fore layer and I intend to add 'wavy' animation to the back layer. That produced something I'm proud of, even though it's far from being perfect. It also has the bonus advantage that I can make characters looks 'in the water' by being between the two layers ^_^.

Comment éviter que la cascade n'ait l'air d'un tapis roulant bleu ? Ma p'tite idée était de jouer sur deux plan, avec deux vitesses de scrolling différentes et deux niveaux de détails différents. à l'avant, c'est "haute fréquence" et vitesse de chute élevée. A l'arrière, "basse fréquence" de détails et vitesse faible. Mais un cycle de 16 pixels pour la face avant, c'était trop court par rapport à l'effet désiré.Qu'à celà ne tienne: il me faut de toutes façons aussi un "pied de chute" où l'eau mousse. Si je garde la mousse sur le demi-bloc du bas, je peux utiliser le demi-bloc du haut pour avoir un cycle de 24 pixels de haut et un pied de 8 sans que le moteur d'animation par blocs de 16x16 n'y trouve à redire.

Les bords, eux, n'existent que dans la face arrière, y compris le dessus de la cascade. ça me fait 45 kB/s à streamer entre la RAM et la VRAM, et la NDS donne l'impression de parfaitement tenir le coup. Pourtant, il se pourrait que j'introduise malgré tout du palette cycling pour la "couche de fond". Bin oui, la je n'ai que de l'eau qui tombe, mais je veux aussi de l'eau qui coule au sol et qui entraîne Bilou avec elle. Et pour la faire couler malgré un dénivelé doux, je vais soit devoir sortir des sprites, soit multiplier le nombre de blocs animés au-delà du raisonnable.

There's a catch remaining though. I have plans for flowing water *on the ground* too, including on sloped ground. With the current setup, I have used 6 animated tiles with 12 to 16 frames each. If I ever try to expand that to ground tiles, I'll quickly blow up my DS resources before I'm half-done with the game I intend to make. I might have to animate all but the foreground layer using palette cycling instead.

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.

/Fe

Voilà, malgré une caméra capricieuse et un joycon rouge qui garde une légère tendance au drift malgré l'entretien à l'alcool, j'ai fini le jeu de Zoinks: Fe. Après un enchaînement de challenge assez satisfaisant en matière de puzzle final, entrecoupé de révélations inattendue et dans un décor impressionnant. On ne pouvait pas vraiment s'attendre à un boss final qui tire de partout, évidemment. Ça aurait complètement cassé l'atmosphère du jeu.

Cette atmosphère (et le rythme qui va avec), c'était pile ce qu'il me fallait pour me délasser. Il est fairy-friendly, en plus, avec ses visuels zen et sa musique aux antipodes du chiptune. Bref quand ma fée est plongée dans ses lectures, c'est un bon choix pour la soirée.

Pendant tout le jeu, on est invité à essayer de comprendre ce qui s'est passé, que ce soit en visionnant les mémoires des adversaires mécaniques ou en réveillant des dessins témoins du passé. Les différentes races intervenant dans le jeu y sont représentées schématiquement, ce qui marche plutôt bien sur le début. Mais j'avoue que ça n'a pas suffit pour que je comprenne l'histoire que ces stelles essaient de raconter. ça reste plus intéressant comme manière de procéder que les textes effacés de zelda: breath of the wild.

Et maintenant ? A quoi on joue ? Ah bin il y a une promo sur 'World of Goo' qui était sur ma wishlist depuis 11 ans une éteeeeernité. Allons-y.