I must make some isocahedron gem!

This is a screenshot from @makeshifted, back in December 2022, that showed up in the last snapshot the Internet Archive could take of my twitter timeline. A repost with the annotation "3D was *that* awesome back in the Assembly 9x #demoscene days."

It showed up again a few times ago and I told to myself "you know, those stonekeys in Commander Keen ? Well, if I can make NDS 3D look that sleek, I won't need to pixelstudy them!

And it appeared again, posted by @benji__t this week-end while I'm doing my farewell tour on twitter.  

One possible system of Cartesian coordinate for the vertices of a regular icosahedron, giving the edge length 2, is: $${\displaystyle \left(0,\pm 1,\pm \phi \right),\left(\pm 1,\pm \phi ,0\right),\left(\pm \phi ,0,\pm 1\right),}$$ where ${\displaystyle \phi =(1+\sqrt{5})/2}$ denotes the golden ratio. -- https://en.wikipedia.org/wiki/Regular_icosahedron --

Oh! look at that ...  

Take a tetrahedron of psi, split summit so that it turns into a 2-edge, and voilà! isocahedron !

- - - 

those words above were written around the 19th of February, last year. I haven't written a single line of DSGL to make it appear in the infinite pyramid, and while I initially thought of using it as keygems, I realise that what they really be are the "magic stones" that you collect after defeating bosses.

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 ! 

That fist goes SMASHing

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

(screenshot saturday on mastodon and bsky) 

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

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

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

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

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

Funnier Apples

Depuis le début de mon carnet en cours, j'ai un objectif "rendre les pommes plus fun". ça passera par des interactions révisées mais aussi par des compléments d'animation. Entre autre, quand on lance un appleman et qu'il arrive par terre. Le comportement actuel est tiré de dumblador, qui glisse légèrement sur les surfaces planes de l'école avant de s'immobiliser assez rapidement.

Finally! that little sketch of an appleman rolling away when hitting the ground has been teasing me for month at the start of my notebook, but now I've finally sketched something in AnimEDS. Hopefully I could try to integrate it in the prototype this week-end.

It should trigger when you've thrown an appleman and its hitting the ground. The current way it slide for a few pixels before settling feels incompatible with the spheroidal nature of an apple but I still have to decide whether it will bounce-roll or just roll. Likely "just roll" will work better with slowing it down. Or maybe it should just keep rolling until off-screen or stopped by a wall ? 

Mais soyons clair: ça ne donne rien de convaincant avec une pomme sur le sol de la forêt. D'où l'idée que la pomme roule un peu en atterrissant ce qui 1) est fun et 2) lui donne un peu plus de portée qu'un projectile classique, ce qui est toujours le bienvenu dans un monde 1.

Alors tant qu'à faire dans le fun, on pourrait même laisser rouler la pomme jusqu'à ce qu'elle rencontre un obstacle, non ?

(En tous cas,  J.L.N approuve ... et apprécie le fix qui évite à Bilou de se retrouver figé dans un mur pendant qu'il nage) 

edit: The pull mask feature should allow me to make eyes and stem either in front of or behind the apple's "body" more easily. I had forgot it exist and made a messy animation where sprites are swapped, which makes it blink in the editor ^^"

Now, that simple animation opens up a lot of new options in terms of gameplay and interplay. What happens if an apple rolls into another apple ? and into a bopping funky funghi ? 

Game design brainstorm from 2022 suggested that you could "push" a funghi by throwing an apple at him when it's mid-air, but shouldn't it bounce the apple back at you if he's grounded ? and what if you're hit by an apple that's rolling back at you ? shouldn't that hurt ?

That starts making the appleman looking a bit more like a koopa and a bit less like a goomba, doesn't it ? My brother even suggested that it could be the core mechanics of a dedicated puzzle game ^_^

Ah. None of these are available yet, of course ^^"

•  roll-apple-roll: 27 june
• apple-bounces-funghi: 10 June.

 

Une pente qui tombe à l'eau

I had tiles that push you along a slope. They've been shown in the sands mostly, but more importantly, they've been tested in a setup where there's plain ground at the bottom of the slope.

Here, I'd like to use water falling down a slope as a way to implement a one-way region somewhere in a cavern of the green zone. But it didn't quite worked as intended. What makes Bilou slide down in such a setup is that a test-point queries the tile number under his feet and use that to look up a physics values array. But once you get down the hill, the hotspot gets in the air, and nothing finishes to push you out. 

Il y a sous l'arbre creux une sorte de pente rendue glissante par une cascade sous-terraine. Mon frère l'avait utilisée pour créer une sorte de sens interdit entre deux morceaux du niveau. Alors j'ai déjà des pentes, donc ça aurait dû être une simple formalité, mais comme vous l'aurez sûrement deviné par le titre, ça n'a pas été sans mal Premier couac: en voulant rendre ce "tapis roulant" plus rapide que les chutes de sable, je suis sorti des limites d'un tableau, ce qui a eu pour effet d'appliquer l'effet geyser à l'ensemble du niveau ^^".

Plus contrariant, une fois arrivé en bas de la pente ... rien. On ne tombe pas dans l'eau, on reste juste là, sur le rebord. Parce que c'est le pixel sous le *milieu* de Bilou (le "hotspot") qui détermine si on se trouve sur un tapis roulant mais qu'il faut qu'il n'y ait plus rien sous lui sur toute sa largeur pour qu'il commence à tomber. Je dois donc rajouter un autre type de tile qui pousse comme un tapis roulant tout en étant pas du sol.

So I added another tile that behaves like air and keeps pushing you as if you were on sliding ground and put them at the bottom of the slope, but even that wasn't enough to get it working. It would take you as far away from the slope as you want, but then, once your hotspot is in plain air, you'll stop, happily idling in the middle of nowhere.

The part I was still missing was the F_START_FALLING property to my new tile type, something introduced so that we could land in slopes properly by having slope tiles letting you keep falling into them (until the hot spot reaches the ground) but not start falling through them when you're walking.

Il restait un dernier soucis. Un couac lié à un changement plus récent et qui fait qu'après avoir bien emmené Bilou au milieu de nulle-part, il ne tombe toujours pas. tout ça parce que j'ai donné au nouveau tile possède bien la propriété F_FALLTHRU, utilisée pendant que Bilou tombe, mais pas F_START_FALLING utilisée pendant que Bilou est au sol pour voir s'il pourrait tomber ^^"

With that new bit set, we finally have it: Bilou keeps sliding until there's no solid ground, and there  it cando(START_FALLING) and ends up in the water :P

There's one odd thing going on with the way the water slide is made as a conveyer, though. Conveyers just move you and don't affect your speed, and that's on purpose. But that means that as you're running full-speed against the water flow (if you manage to) and decide to jump, you suddenly move in the air at top speed while you were almost idle on the ground.

Maybe I should mimmic Sonic's water slide and make a dedicated "woah! I'm sliding down!!" state for Bilou as well.

But even then, when Bilou is walking against a conveyer, it is natural that he's walking faster than he's moving ... against water, we all know there's a force slowing us down, so it'd make sense to see his animation slowed down and pixel-fitting its motion against the water ... which would mean acting on his speed rather than shifting his position ... Meditate on this I will. 

Petit à petit, le niveau se construit...

Bon, j'ai passé un peu de temps dans mes éditeurs sur DS ces derniers jours pour habiller un peu plus le premier niveau et je viens de construire une map avec le 2eme (après un moment de frayeur de "est-ce que je ne viens pas d'écraser mon gac.map en essayant de créer gpc.map ?_?"), tout ça pendant que je faisais la mise au point des portes du côté PC.

• un arbre tout à gauche pour marquer le bord du niveau
• (pour une raison inconnue, sortir de la map par la gauche conduit à un plantage de runme ... à investiguer)
• une petite pente avant le premier arbre pour rendre le niveau moins plat, valider le graphisme des pentes et faire de la place pour des plate-formes avec les petits vers dessus (côté notuto)
• il faut encore une palette alternative pour la terre dure et des images de bord pour la terre d'arrière-plan
  

I've spent some times on PC to get doors working, but also some time on the NintendoDS itself, putting more tiles around the edges of crude level I had last week. I even tried to start importing the second green zone historical map, but a blue screen in LEDS put that to an end. (possibly linked to bad handling of color palette selection in "paint" mode). It highlighted I'm lacking some darker tones for some parts of the color palette (mostly dirt) and some edge tiles for the "far away dirt"

So here's a couple of screenshots that were part of the last "Screenshot Saturday". One of them illustrating an attempt to implement the "sliding stream from waterfall" which doesn't quite work the way it should: it's too easy to force your way by quickly jumping away again and again. plus, it doesn't kick out into the water once you're at the bottom of the slope. To be investigated

• première tentative pour la cascade-glissante
• quelque-chose empèche le système actuel de nous jeter hors d'une pente avec les tiles "tapis-roulant" ... à creuser.
• correction des hitbox de Bilou qui nage pour qu'il arrête de se manger les murs à tout bout de champ
• habillage de la "cachette sous l'arbre" ... je la trouve un peu petite dans son état actuel ...

Par contre, avant la prochaine release, il faudra vraiment que je prenne le temps de dessiner une deuxième moitié au décor de fond qui convienne pour "au plus profond des cavernes sous la forêt" ...

Make it exist first,

You can make it good later. It's an ongoing meme in the gamedev community, and it's perfectly capturing what I intend to do with the "Green Zone" levels.  The map is very crude, most of the areas use repetitive patterns of the same block, it feels dull to "play" and I don't even have graphics for the key or the closed door ... but at least, I can check whether we can reach branches, cliffs, leap over holes and the like.

Il y a un meme qui est occupé à faire le tour des groupes "gamedev": un trait qui reboucle plus ou moins sur lui-même entourant un pâté de couleur accompagné de la légende "commence par faire en sorte que ça existe". En vis-à-vis, l'image d'un cercle aussi propre sur lui que s'il sortait d'inkscape ... avec la légende "tu pourras l'améliorer plus tard". Et c'est vrai que c'est assez pertinent: combien de projets ont tourné à rien parce que leur dévelopeur à cherché à atteindre l'inaccessible étoile trop tôt ? En plus ça colle assez bien avec le planning que je me suis fixé pour l'été: faire une version minimaliste de chacun des niveaux qui hantent le cahier-bleu-du-redesign pour voir si Bilou sait atteindre les différents objectifs ou si je dois envisager des mécanisme "d'aide à la conduite" du genre de ceux utilisés dans MainFrames. Et tant mieux si le niveau me sert aussi de bac à sable pour valider le fonctionnement des portes.

Files are being swapped back and forth between the computers and the DS, as I bring together the fixed bouncing branches, geysers and updated applemen. Unfortunately, the level editor is currently unable to show us invisible gobs (workaround: done), and with doors and branches, I start to have a higher number of them ... It also has restrictions on how to link items that I'll like to get rid of later on.

There's something though, that I don't really like about the current state. It's crude. There's no beauty in the way it looks. There's not much fun in the way it plays. Monsters feel placed randomly on uninteresting surfaces. The forever-in-progress "level two" -- with its geyser and huge trees -- makes me feel prouder than this.

Je transfère donc un script dans un sens, un spriteset dans l'autre, je passe du temps dans l'éditeur de niveau pour que ce "Green Zone 1: L'Arbre Creux prenne forme... Forme, mais pas vie. J'avoue que c'est un peu décevant cette austérité, cette absence d'objectif et de gameplay... et je me suis surpris à apprécier de retomber sur le niveau-en-chantier ou la salle de test qui me paraissent tellement plus accueillants bien que totalement inachevés.

Enfin des portes

 Si, si ... ce blog parle toujours de développement de jeu DS. C'est juste que les portes, c'est pas mal comme morceau et que les retours de camps, c'est pas mal chronophage. Mais voilà! J'ai eu un truc qui commençait à marcher hier!

Post by @PypeBros@mastodon.social

View on Mastodon

ici je vous ai mis la version rigolote. Quelques heures plus tard, j'avais fini par trouver les bons réglages pour que Bilou s'arrête à la porte de destination une fois sa vitesse suffisamment réduite.

Here's the first somehow-working attempt to move Bilou from one door to another. There are plenty of things still quite crude, and we don't even get the illusion that Bilou enters the door. It's based on another patch that allowed entering the end-of-level doors and on a new opcode that simplifies things by letting Bilou directly target the door's destination rather than aligning on the coordinates of the source door as it moved to the target as I initially planned.

If you can't see the clip from mastodon above, it shows Bilou flipping in front of a door (no enter animation yet ^^"), then zipping to the next door (no hiding yet) and then oscillating around the target door endlessly (wrongly assigned the speed division to a "found" event when I should have used "hit" instead ^^" -- that is now fixed). You'd have missed that it happens in the caves under the Hollow Tree, meaning that yes, I started remaking historical levels into LEDS so that I could test them.

All that also uses (and validates) a fresh implementation of revised collisions mechanism so that we can have collisions for "is there a door", "I'm done entering the door", "I've reached the target door", "I've left the target door", etc. despite the fact that generic flags are already crowded since SchoolRush. 

Les plus observateurs d'entre-vous auront reconnu un fragment de la Green Zone, plus précisément la fin du niveau de l'arbre creux, mais parcouru à l'envers. Donc oui, j'ai enfin commencé à reconstruire les niveaux historiques dans LEDS pour pouvoir les intégrer à Dreamland... ce qui a bien plu à J.L.N, d'ailleurs, qui en a profité pour réenfiler sa veste de chasseur de glitches.

La porte elle-même est finalement beaucoup plus simple que ce que j'avais envisagé grâce à un nouvel opcode: ATATTACH qui permet à Bilou de s'attacher directement à la destination de la porte (à laquelle la porte elle-même est attachée).  

Les portes ... prochain vrai objectif

C'est ce qu'on pouvait lire en mars sur une de mes pages d'agenda et en avril sur mastodon. Et c'est toujours d'actualité, bien que j'envisage de faire d'abord un essai des éléments de base de leur implémentation sur un le bonus qui rend des points de vie ... Si vous avez un peu essayé la dernière démo, vous avez sans doute été surpris par un brusque changement de niveau dès que vous vous approchez un peu trop d'un truc en forme d'ouverture. C'est clairement quelque-chose que je voudrais améliorer.

La bonne nouvelle, c'est qu'en fait, j'ai déjà la moitié du travail: enregistrer la position actuelle dans des variables. Et voici la deuxième partie: se diriger vers les coordonnées enregistrées.

Bilou's Adventure maps have doors... you know, the kind that are located at some point on the map and will near-instant put you somewhere else on the map. So I'd like "Bilou Dreamland" to have doors as well... That will require a bit more effort in the GEDS environment that can't simply do ROOM=12 : xbilou=100 : ybilou=100. So i've got this nice tree stump sketch in my agenda since at least March'25, and I've been twisting my mind around the issue of how to make it work with state machines and collisions and linked game objects.

Now, my Basic games typically struggled to extend beyond one level. At best, I'd chain-load the next level which would happen to look a lot like the previous one (or not) by sharing lot of code thanks to copy-pasta... And entering a door would typically freeze everything as the game had entered a dedicated micro-script that ignored everything but entering the door. 

L'idée générale, c'est donc d'avoir deux "personnages" pour une porte, l'un représentant le point d'entrée et l'autre le point de sortie. Le mécanisme d'attache qui permet à Spongebop de rester pendue à son clou peut aussi servir pour lier les portes. Bilou, lui, se liera à la porte "entrée", et la suit de la même façon que dumblador suit Bilou quand il le transporte.

The overall idea is to have two game objects involved in a door-to-door transit: one being the incoming door, and the other being the target location. There will be a one-way link between them in the level script. As part of the 'entering' trigger, Bilou would attach to the input door, which is itself attached to a target GOB. Using that to transport Bilou to the destination should work quite nicely: it's been years that tracking the attached object works nicely. The question is "how do I send back the door once Bilou has left?"

I cannot just "track an object left at the original position", because so far, the engine only track *one* object at a time. But I could record the position before leaving, and -- with the help of a new controller -- track that position. In fact, I already have such "record position" behaviour as part of the "grid" controller used by bouncy branch and furblock.

Coding directly such a multi-step mechanics didn't sound a wise move to me, but I had an animation for the health power-up that made it circle around ... and a notebook entry suggesting to do that with lines of code rather than lines of pixels. I'll save the introduction of an invisible permanent object to circle around if I inject "reccoords" and "track(recorded)" in that health pick-up ... which has just been completed today. 

Voilà donc un premier pas franchi: ce petit point bleu volant a enregistré sa position d'origine comme l'aurait fait une porte et est en train de se servir du nouveau contrôleur pour s'orienter et graviter autour. 

Bon, et se faire transporter ne sera pas tout: je voudrais aussi qu'on ait l'impression que Bilou *rentre* dans la porte avant le transport. Quelque-chose de plus convaincant que le simple décalage vers le noir de la version BASIC où appuyer sur "haut" un peu trop à gauche ou à droite nous enverrait à travers le chambranle, la main devenue noire de Bilou ressemblant à un trou de trop dans le mur :P  

And I must admit I injected significant time in thinking how Bilou would *enter* the door. I know it isn't required to see him walk into the door like Bubsy did, and likely the spin at the start isn't strictly required either, but I intend to use it as the excuse to align Bilou with the door such that I can later fade him to black without having a Bilou-shaped hole dug into the wall (QBilou.bas did that ^^) nor require pixel-precise location to activate the door (Super Princess Peach did that >_<)

edit: If I give the engine one extra opcode to "attach to the object that object is attached to", then all those extra steps about the "door" acting as a flying carpet that takes you to a given destination and then goes back to its anchor location becomes useless...

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. 

GobExpression debugger

Throwing apples does not work the way they should. There are likely bugs in the state machines transitions, and -- once again -- they are tedious to isolate. So here a screenshot of a first step towards a tool that would let me step through guards and actions at bytecode level.

The colored line just below shows those opcodes, one character at a time.

I've got such bugs to fix in the past, of course, but that's always been a pain. InspectorWidget can only break when a specific transition is taken, but not before its guard expression is evaluated. And something in my C++ code prevents gdb from stepping through the expressions evaluation function.

Juste avant de partir en vacances, j'ai fait des petits tests avec des lancers de pommes, mais il faut reconnaître que ça ne marchait pas comme prévu. Et faire du debugging de transitions, avec les outils actuels, c'est le truc le plus pénible (en dehors des 'guru meditation', peut-être). Il était temps que je m'attaque à un "side-project" esquissé pendant les valises: un véritable bytecode debugger dans lequel on sélectionnerait son expression comme si on explorait des adresses mémoire: n° de gob, n° d'état, type de transition puis choix de la transition.

On aurait ensuite la possibilité de mettre des breakpoints au niveau "instrution", mais aussi de faire du step-by-step dans les expressions pour voir si l'évaluation se produit comme prévu ou non.

La capture d'écran ci-dessus vous montre bien qu'on en est qu'au tout début: faire en sorte de pouvoir utiliser les caractères programmables de la DS pour pouvoir renseigner 'constante n° 2' ou 'décaler de 3 bits vers la gauche' sur le même espace qu'un des caractères ASCII.

So far, it's really the first baby steps: video mode switching and character reprogramming so that opcodes can each be shown on a single 8x8 character. Part of them could fit within the extended ASCII range, but there's some room consumed right after that for the 'screen maps' themselves, that cannot be assigned to any character.

But the idea is to half a screen of these expression, see a cursor step as you press the 'forward' DPAD direction, see the stack fill, the reads and writes from object variables, etc. Long is the road ;)

I don't want the expression evaluator to be slowed down by extra tests, so I'll do the kind of tricks 8086 debuggers were doing: inject breakpoint opcode at the next instruction and remember what was there instead. Next time the debugger is invoked, it will restore the saved opcode, show us the new state and tell the expression to retry current instruction when we give a green light.

appleman 2.0.1

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

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

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

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

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

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

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

gravity.flow ?

Je voulais faire tout autre chose, mais au moment de prendre le code en main, je me rends compte que j'ai une série de modifications qui n'ont pas encore eu droit à leur commit ... et que je ne sais plus trop à quoi elles correspondent.

Il s'agissait en réalité de deux modifications liées à l'eau: animer la surface (nager si bien avec un miroir en guise de surface, c'est un peu dommage ...) et faire en sorte qu'on puisse placer un jet d'eau dans une grotte. Parce que vous ne ça n'aura pas manqué de vous faire tiquer: il y a une sorte de rectangle moche au pied du geyser sur l'image ci-contre/dessus. C'est lié au fait que le geyser (tout comme la cascade) est obtenu en par une combinaison des deux couches de décor: l'une avec une animation de type "palette cycling" et l'autre avec une animation conventionnelle. Et donc pour mettre le geyser dans une grotte, il me faut deux nouveaux blocs "décor de geyser fusionné avec le décor de grotte".

After a fairly busy week and significantly busy Saturday, I wanted to try updating the Appleman behaviour, but I found my homebrew directory with different files uncommitted and changes involving binary files like maps. So I started by running the current code first on the emulator, and visit those maps to see whether there were any changes. And oh, of course. First change was animating the water line (see the mastodon video below). Second was an extra water jet in the second green map.

Quand je dis "je ne sais plus à quoi elles correspondent" (y compris une modification du code qui assure le palette cycling), comprenez "il a fallu que je fasse tourner le .nds pour m'en souvenir". Ce qui m'a donné envie d'en faire des petites captures (un jour après le ScreenshotSaturday ... pas de chance ^^"), et sur une de ces captures, on remarquait quand-même fort que le haut du geyser reste en permanence au même emplacement. Moi, j'aimerais qu'il monte et qu'il descende, pour ajouter un peu de dynamisme à la scène, et appeler à l'interaction.

See on that level editor, waterfalls and geysers are made of two layers of tiles combined. But that means you can't put a geyser over a dirt wall unless you've got tiles showing that in first place. Plus I'm using another palette slot for the dirt wall than the default one, meaning the cycling code had to be updated. That was ready for some screen-shotting. 

J'aurais peut-être pu utiliser le contrôleur "grid" de furblock, mais tôt ou tard, il faudra aussi que Bilou soit propulsé vers le haut par le geyser. Plan B: utiliser le même mécanisme de "flow" dans le contrôleur gravity que celui codé pour swim. Je profite donc que tout le setup wifi est là pour modifier le niveau et je définis un nouveau type de tile (les ^ mauves). ça donne des résultats rigolos avec Bilou, mais en réalité, ça ne marche pas: Bilou est bien ralenti quand il arrive dans le haut du geyser, il peut même remonter légèrement, mais au final, la gravité lui donne une vitesse suffisamment élevée (on peut aller jusqu'à 6px/frame) pour qu'il redescende, puisque le geyser le fait monter à une vitesse constante de 2px/frame. Bref, c'est bien pour des tapis roulants mais pas pour des geysers.

But then, the top of the geyser was very static ... I want it to wave up and down a bit. There are different ways I could do that in my engine, but only a few where not only the geyser top but also Bilou is lifted up when in contact with the stream. That implies a mechanism similar to the water flow designed last year, except this new special physics tile will define a property for the gravity controller instead. It will still be an "AIR" tile, though: we can fall through geyser, not swim them. (I hope to avoid nasty corner cases that way).

Unfortunately it didn't work the way I wanted. Lifting Bilou by 2 pixels (cyan lines on the diff) is fine as long as the vertical speed is lower than 2 pixels/frame downwards. It gives a nice boost when jumping and catches you when you're "stomping" the geyser, but while you're being stopped, your intended velocity keeps increasing, and at some point, you'll be fast enough to reach the ground again. Exactly as you start sprinting backwards on a conveyor belt.

So I ended up using the yellow code instead: directly change the polarity of the gravity based on the sign of the terminal velocity stored as a per-tile-type property. Not perfect, but close enough for now.

Mais en fait, il n'y a pas tant à changer que ça: plutôt que de déplacer Bilou, on va utiliser l'information stockée pour contraindre la vitesse maximale ... et tant qu'à faire, inverser la poussée si la vitesse maximale est négative. J'ai pris des vitesse identiques pour la gravité et le jet d'eau pour le "petit nuage" en haut du geyser, ce qui lui donne un mouvement symétrique alors que pour Bilou, la gravité lui permet d'acquérir une vitesse jusqu'à 3 fois plus grande, et il a donc tendance à s'enfoncer plus dans le jet d'eau. ça suffira pour le premier jet ;-)

edit: valeur maximale -2px/frame validée: il suffit de garder le bouton de saut enfoncé pour décoller bien au-dessus du geyser. Et si on tombe du sommet, on ne redescend pas trop bas.
 

Post by @PypeBros@mastodon.social

View on Mastodon

Heal Pick-up

I've had a "heal 1 point" pick-up in School Rush, and I was quite happy with it. The only issue is that everybody always mentioned it as "a 1-UP". I guess when your main character is a blue ball with hands and feet, a pick up that looks like a smiling blue ball will often be perceived as a 1-up...

I've been toying with the idea of making a "blue patch" collectible (see the bottom sprites in the screenshot nearby), inspired by the red dots of CoolSpot. I did my best but ... well... it just feels wrong when I animate it. It doesn't convey proper shape or coherent motion... and adding sparkles to it didn't help either.

Quelques petits pixels que j'ai rajoutés un peu plus tôt dans la semaine et qui serviront de points de vie pour le prochain jeu de Bilou. Pourtant j'aimais bien la balle bleue souriante utilisée pour ça dans School Rush ... mais voilà, j'entends vraiment trop souvent les joueurs en parler comme "la vie". Au point que rajouter un autre dessin pour les 1-UP, ça n'aurait pas de sens.

So I went for something else, using that same blue ball as a base, but trying to get some circling drop... it's not as smooth and convincing as I hoped, but it's doing a fair job anyway. I had tried to make something more elaborated by adding sparkles, but it feels like it doesn't work: it catch the attention along a triangle that competes with the circular motion ... or something alike. I'd love to have the wayofthepixel board to ask and get advice, but those times are gone...

J'espère que vous aimez ces espèces de gouttes-de-yin-bleues qui tournent... je pense que je les ferai sans les scintillements: ils me semblent casser la fluidité de l'animation comme ils sont là.

Ce n'était pas mon idée de départ: je m'orientais plus vers des pastilles tirées de Cool Spot, mais ça, ça s'est avéré encore moins réussi ^^".

Pas si circulaire ...

Bon, j'essaie de mettre au point le fait de s'accrocher aux racines, et ça malgré le fait que j'ai noté quelque part "oui, ça ne marche pas parfaitement, mais c'est amplement suffisant pour faire le tour des niveaux sans ce prendre la tête".

C'est sans doute ce que je ferai dès demain, mais il faudra que j'y revienne et que je corrige un peu tout ça. Un composant "reste dans le cercle" avec un comportement cahotique, c'est marrant pour SpongeBop à cause de son élastique ... mais pour les lianes qui pendent ? les signets ? les ponts ? les boss ?

Technically, it would be nice to have Bilou reusing the "stay within radius" behaviour of SpongeBop when he's hanging at a root. Just have a smaller radius, show his hands grasping the root and voilà (oh, and remove the white polygons, please). That would work if that RadiusController wasn't randomly jerking up. Jerky monster with funny tik-tokking eyes is fun. But a jerky bookmark ? A jerky vine ? that looks suspiciously close to a bug to me

I had already fixed a more serious bug last week, and somewhere on some note book, I wrote down that "jerkiness shouldn't hinder levels traversal. Keep it as is and keep going". And yet there I am. Maybe this number shouldn't be that high ? Maybe that thing is wrong ... What does it look like in DDD?

Je vous ajoute deux petites capture-gif pour que vous vous rendiez compte si vous n'êtes pas allés vous promener sur mastodon ces derniers temps ... une où ça va pas trop mal (ci-dessous) et une ou ça part dans tous les sens (ci-contre)

Dans les deux cas, je ne donne aucunes consignes avec la manette. c'est juste "l'énergie de départ" qui est hors contrôle ... ou un problème d'arrondis qui s'accumulent ... ou quelque-chose de plus fondamental.

J'ai fini par rajouter un printf("%vx,vy + %corr_vx,corr_vy @%extra_radius") dans le code et faire cracher des tonnes de chiffres pendant que ça partait dans tous les sens (le debugging step-by-step, sur un problème comme ça ne donnait rien). Contrairement à ce à quoi je me serais attendu, on a très peu de "brusque augmentation du vecteur-vitesse" ... par contre, on a régulièrement un vecteur plutôt important (correction d'1 ou 2 pixels) parfois pendant 2 frames d'affilée. Dans un setup où la gravité met 8 frames à augmenter d'1px/frame, ça veut dire que Bilou va facilement nous faire un petit bond de la taille d'un caillou quand ça se produit.

The 2 screenshots above show the state as of ScreenshotSaturday, 5PM. I guess I don't have to convince you that it would look broken, if the game was doing that while you're not even pressing any button of your DS. I added print statement, revealing adjustments performed to stay within the radius (step-by-step debugging doesn't really work for such use cases), and even shooting a video of those lines so that I could time-travel and see what were the causes of sudden bumps... Except that there were no "sudden huge speed". Instead, there were multiple frames with 1 or 2 pixel-per-frame corrections, but that was already fairly strong for 1/8th-of-a-pixel-per-frame gravity. At 8PM, I had given up: it would require a complete rewrite to get stable behaviour, for sure.

Alors voilà ... j'ai copié le code de RadiusController::think dans un carnet pour pouvoir le comprendre et l'annoter ... j'ai voyagé dans le temps avec les captures .gif et analysé les chiffres que mon print avait produit et ça me donne le sentiment un peu désagréable qu'il n'y a rien de corrigeable dans ce code, parce que l'impact sur la vitesse persiste plus longtemps. Peut-être faudrait-il corriger directement la position, mais alors on perdrait la transformation de la chute en un mouvement de balancier...

edit: vous l'avez lu, j'étais sur le point de jeter l'éponge ... puis le lendemain matin, j'ai voulu tenter quelque-chose quand-même: et si les valeurs dx et dy que j'utilise pour vérifier si dx²+dy²<radius² n'étaient pas exprimées en pixels mais en subpixels ... pas en 256èmes comme la vitesse parce qu'il faudra quand-même les multiplier et que ça ne déborde pas ... mais des 16èmes de pixels ? Eh bien, avec ça, ça donne quelque-chose de beaucoup plus convaincant... je vous remet une mini-animation sur le côté. Il y a un peu de vibration résiduelle mais rien de vraiment choquant. Et ça malgré que Bilou partait avec un mouvement du genre à faire des bonds dans tous les sens au commit précédent.

But as I started my Sunday, I wanted to try something before rolling back to where I was on Friday: adjust the algorithm so that it would work with sub-pixel precision. 16th of pixels, to be precise, just the intermediate between pixel coordinates and current 256th of pixels used for speeds and entity positions by the engine. And ... well ... it turns out I now have something that converges towards a stable state. It's a bit sad for Spongebop... I'll have to try and find a way to turn of stabilization for them ^^".

Il me reste à trouver un moyen de rendre ça paramétrable, des signets qui ne soient pas élastiques et des spongebop qui le soient (la pauvre, obliger de circuler le long d'un parfait arc de cercle, c'est vraiment la dictature de SquareRoot ... je ne le lui souhaite pas).

edit²: le changement d'échelle (subpixel 12.4) suffit à lui seul pour avoir une éponge qui suit une trajectoire toute circulaire ... mais pour Bilou qui peut débarquer avec un vecteur-vitesse quelconque, il faut bien tous les petits ajustements. ça sent le code split, parce qu'il n'y aura rien à paramétrer ...

le nouvel arbre

Avec les tests effectués pour les-racines-auxquelles-on-s'accroche, j'en ai profité pour faire une petite capture d'écran de l'arbre tel que je suis enfin en mesure de le faire apparaître dans le jeu ... Je pense que vous ne l'aviez pas encore vu. Pas parfait, mais honnête, je dirais. (et oui, j'ai vu: il reste des caractères foireux tout autour... C'est une map de récup, si vous vous souvenez ;)

edit: ces caractères (étoiles) sont invisibles dans l'éditeur de niveaux: il s'agit d'une portion de la mémoire utilisée pour les animations qui se retrouve visible parce que la map fait toujours référence à des numéro de tiles qui ne sont plus dans mes pages.

There are tests ongoing on my devstation with Bilou hanging to a root in the greenzone. They've been behaving rather weirdly lately, but they're taking place in that recovered-vertical-level once drew to test load-level-two feature.

And that means at some point, I was bored of seeing non-sense flashy tiles at the start of every attempt, especially since I've drawn some more leaves tiles last year. But you had never seen them, because I had never used them. Well, now it's done. they're not perfect, but here they are.

pixels, at last.

Une petite heure de week-end où j'ai pris le temps de me faire des petits pixels ... enfin. Après une autre petite heure plus tôt dans le week-end pour faire quelques essais de croquis.

L'écrabouilleur, d'abord, qui est la résultante de mes esquisses basées sur Ristar, des techniques proposées par Helm que j'avais utilisées pour les livres de l'école et de la réalisation que  finalement, des gants façon Mickey donneraient sans doute mieux dans l'univers de Bilou que ma propre main.

Il se trouve que j'avais déjà tenté de dessiner ma main, et j'avais la S-Team en entier et le verdict est sans appel: le nouveu design, plus anguleux, s'intègre mieux.

Finally, I managed to find 2 hours to work on the missing pixels I need for Bilou's demo. First the smasher punch, using all the observations I made while posting about my Ristar pixel study. It's more squarish (and the S-Team girls like it), it has cartoony-4-fingers look and is modeled after a cartoony glove rather than my own hand. Quite close to the sketch I made the day before. I'm still undecided about the thumb position ...

Second, the top-of-waterjet sprite. I won't try to make a tutorial of how-to-animate it: there is very likely room for improvement, but it does a fair enough job (imho) and nicely fits the style of the jet (see below for the in-game montage ;). I'll still have to make it wave up and down and make it so that the jet pushes Bilou upstream on contact.

Deuxième morceau: le haut du geyser inspiré de GoodboyGalaxy. Il faut dire que les derniers tests se déroulaient sur une map où j'ai ajouté l'animation pour la partie verticale du jet ... et bon, voir le jet se terminer par une ligne nette comme ça, ... ça picotte aux yeux.

Je ne suis pas franchement au niveau de hot_pengu, mais je crois que ça devrait faire l'affaire malgré tout (NB, c'est plus fluide en vrai sur la DS).