How GEDS scrolling works

The scrolling routines of InfiniMap weren't as well documented as I hoped. Not even when I blogged that "yeah, it finally works". And while trying to document them, I noted some undesired difference between what the code does and what I claimed it does in the comments. So here it goes. First this is the full level map, stored as a 2D array of tiles. Within them, we define an area of world coordinates (xmin,ymin)-(xmax,ymax) that is guaranteed to be present in the video memory as well. That is the "invariant", the condition that was true on the first line of a scroll_*() call and that must be restored before we leave the function.

    if (py < ymin + WH / 2) 
      do { up_scroll(); } while (py < ymin + WH / 2);
    else if (py + WH / 2 > ymax) 
      do { down_scroll(); } while (py + WH / 2 > ymax);
    if (px < xmin + WW / 2) left_scroll();
    else if (px + WW / 2 > xmax) right_scroll();

WWxWH is the dimension of the validty area. We will never let xmax - xmin < WW happen. To decide whether scrolling routines should update the contents of video memory, the scrolling code compares the position of the camera (i.e. the center of the viewport) with the coordinates of the area. If it gets too close to one edge of the 'validity area', video memory contents will be updated and that edge will be moved, possibly dragging the opposite edge along (since we have fixed-dimension video memory)

  void right_scroll() {
    unsigned xoff = (xmax - xmin) / TL;
    // compute target position in video memory
    u16 *src = dataview + xoff;

    xmax += SQ; // new validity window will end 64 pixels on the right.
    if (xmax - xmin > 512) { 
      xmin += SQ;
      xview = (xview + SQ / TL) & 63;
      dataview += SQ/TL;
    }
    // copy from src to video memory
    // so we fill the expanded area with valid tiles. 
} 

Then, this is the video memory. The hardware reads it as a 2-dimensional wrapping array, that is if it cannot read more at the right, it goes back reading on the leftmost column. The (xview,yview) reference point corresponds to "where in the video memory is (xmin,ymin)" (that was the part that needed a patch).

Note that only a part of that valid area will show up on screen (highlighted here).

Note that whatever happens, xmin always shifts by 64 pixels. That's the horizontal copy granularity SQ (because it was meant to be square), and no, I never checked it led to better performance than 32. We must have ScreenWidth + 2*SQ < VramWidth, though.
 

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

special properties

While thinking at 'how to implement conveyer belts', I end up investigating some currently incomplete code in special blocks handling. They have correct implementation of their collision areas, but since the migration to the new tile types engine, they can no longer act as 'doors' because they all have the same cando() properties.

Au départ, je réfléchissais à "comment coder des tapis roulants" et je me retrouve à creuser du côté du traitement des blocs spéciaux: ils ont bien un support des zones de collisions, mais depuis le passage au nouveau format de maps, on ne sait plus les utiliser comme des "portes". Je m'explique.

Au moment de coder la démo 9-9-9, je voulais mettre un système "clé-et-porte": un petit bloc devait rester ... bloquant jusqu'à ce qu'on le touche avec au moins 9 pommes, auquel cas il disparaissait et devenait du "ciel": on pouvait passer. Mais pour faire ça, il faut qu'une pomme (à travers laquelle on peut marcher, tomber, etc) ait des propriétés physiques différentes d'une porte. C'est ce qui manque actuellement. 

Euh ... attendez. Non: on a déjà un scanf qui ferait ce qu'il faut ... reste à le tester. 

There's some code in the parser to change that, and some code in 'FlatWorld' to return BlockInfo::props when we encounter one ...

Wait ... BlockInfo::props is precisely what this last `siscanf()` updates ... so ... that means the code is not incomplete at all ? it just needs to be tested ?

bg0.more vs. spr.more

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

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

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

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

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

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

spr.load+

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

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

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

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

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

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

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

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

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

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

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

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

Pentes et JumpThru

Je me rends compte qu'il y a un truc à propos des pentes que je n'ai apparemment pas convenablement expliqué sur ce blog. Voyez donc cette "capture d'écran" de l'éditeur de niveau avec les types de blocs qui sont révélés en bleu transparent. Il est assez facile d'y voir les zones considérées comme solides, et même la petite pente au niveau de la souche d'arbre (allez, je vous la marque en vert flashy). Puis il y a un troisième élément qui revient assez souvent, ce sont ces lignes horizontales, notamment dans la branche (je vous les marque en rose ou en jaune, petits veinards ;)

There's something I seem to have missed to explain about my implementation of slopes. Let's check this screenshot of the level editor, with the tile types revealed. Some areas are obviously solid (covered with fully-painted overlay squares). Some are slope (okay, I'll paint them in flashy green), and then there's a third recurrent item, identifiable with horizontal stripes (like the one painted in pink, on the tree branch).

Those striped tiles are 'jump-through' platformes, helping the player to climb up structures in the level. They are simply implemented by changing the "world flags" that we're looking for depending on whether we're moving up or down, by acting like ground if we fall down, and like air if we jump through them.

Elles correspondent au type "jump-thru", qui a la particularité de laisser passer ce qui monte mais pas ce qui descend. Aucune magie là-dedans: c'est simplement le "GravityController" qui ajuste le test effectué selon qu'on monte ou qu'on descend. Ce type agit aussi comme du sol sans agir comme un mur: si on arrive dans la branche par le bas avec une vitesse horizontale, on la conserve.

Là où ça devient intéressant (ou louche comme une passoire sans trous), c'est pour les blocs "jump thru" qui sont marqués en jaune. Non, il n'y a pas de passage secret, et on est jamais sensé sortir de la souche.

Now, there is another location with yellow jump-through blocks. This is no sweet secret passage. This is directly linked with the slope nearby. You see, depending on the controller used for a given state, we can decide to check for CAN_MOVE_THROUGH or CAN_FALL_THROUGH. And while we're walking along a slope, we don't try to fall.

Imaginons un instant qu'on ait un personnage occupé à monter cette pente. Il a un point de contact (en vert flashy) qui doit rester sur la pente, et une zone de collision (en bleu). Pour qu'un déplacement soit valide, l'ensemble des blocs sur lequel la zone de collision arrive doit posséder les bonnes propriétés -- par exemple "on peut passer à travers" ou "on peut nager dedans". C'est le principe de la fonction cando() dans mon moteur de jeu.

Mais dans le cas d'une pente, on voit clairement que la zone bleue peut "déborder" sur les blocs juste à-côté des blocs-pente. Si on les rends solides comme des murs, le personnage restera bloqué en bas de la pente... d'où la réutilisation des blocs au-travers desquels on sait tout faire sauf tomber.

(C) The UnDisbeliever
why we need more than slopes & blocks.

If we had instead a solid block at the end of the slope, the character would get stuck. It was perfectly detailed in the Undisbeliever's recent blog post on his SNES engine tile collision description. I tried to show the same with the zoomed screenshot, with a 'hot spot' in green, the 'cando(MOVE_THROUGH)' area in blue and the intersection of the jump-through tiles and that area with some pink-ish pixels.

I guess we could also have just used empty tiles for most of the rest of the slope (but the top, that is). I suppose I grew the habit of using jump-through tiles under slopes so that monsters work properly, especially those with check-points. If not, when they'll check a few pixels away from their hot spot whether there is still ground to walk on, they would wrongly consider they should turn back.

Ils permettront aussi qu'un personnage dirigé par une "IA" qui sonde la map autour de lui ne pense qu'il arrive au bord d'une plate-forme en trouvant un tile "creux" quelques pixels sous son point de contact.

Voilà, j'espère que c'était intéressant ;)

L'encodage de la physique du sol

Bon, j'ai pris un peu le temps de cogiter à ce dont j'ai besoin pour les nouveaux types de sols dans mon moteur de jeu. Je sais que je veux plus te types de pentes et plus de types de physiques, mais en relisant mes notes sur les pentes pour comparer ça à celles de Ishisoft, je suis tombé sur un os:

Si je veux des tapis roulants qu'on ne sait pas traverser, il me faut des tiles "physiques" avec la propriété "IS_WALL". Ou plutôt sans F_PLAYER_THRU. Cette propriété va être testée sur l'ensemble de la zone que le joueur (ou un ennemi si on regarde F_MONSTER_THRU) voudrait occuper après son mouvement.

I took some time to make a list of those 'special grounds' I'd like to have in my game engine. More slopes, that was an easy one. But while I was comparing my plan to Ishinsoft's tigsource post, I noticed a potential issue.

If I want to have conveyer belts that act as solid structures, I'll need physics-changing tiles that also have some IS_WALL property. Well, actually, that doesn't have F_PLAYER_THRU, since the 'cando' system allow move to some area only if a set of properties is true for all the tiles covered by this area.

Mais si je veux des plate-formes glissantes en jump-thru, il me faut des tiles "physique du sol modifiée" sans la propriété "IS_WALL" (donc avec F_PLAYER_THRU, cette fois-ci). Jusqu'ici, comme la physique "glace glissante" et "tapis roulants" sont dissociés, je pourrais m'en sortir en définissant aussi les propriétés de collision pour chaque type de physique.

I also want slippery jump-through ground, which requires physics-modifier tiles that act as plain air if you jump through them (so with F_PLAYER_THRU set). Hopefully, slippery ice and conveyer belts are distinct things, so I could just have per-physics-tile properties set and we'd be done.

Les ennuis commencent si je veux un mur solide avec des pentes et une physique particulière: à l'intérieur de la structure, il faut que des tiles avec 'F_PLAYER_THRU' pour qu'il n'y ait pas de murs cachés dans la pente. (Un vieux truc mais toujours indispensable avec 'cando' et ses flags) et sur les bords de la structures, il faut que je repousse les assauts des sprites trop entreprenant pour les obliger à attendre le sommet avant de s'installer.

ça me consommera 2 types de tiles physique. Ce n'est pas forcément un cas fréquent et on aura pas nécessairement besoin de dédoubler tous les types de physique.

Things really get nasty when you consider structures like Aladdin's sandfalls (we should have some in some Sonic games too). There are physics tiles (pushing the player to the left) involved and slope tiles involved. Some physics tiles will have to let the player thru, else they will get stuck into the slopes (that mostly happens in the middle of the structure), and other physics tiles will have to act as walls at the edge of the structure, so that aggressive speedrunners don't get through. I don't see shortcuts to workaround the situation: we'll need two separate tiles type here, despite they'll have the same effect on physics (push player to the left).


Du coup 1) il faudra regarder sous une pente pour avoir ses paramètres de physique et 2) ce sont les contrôleurs qui conserveront les informations dont ils ont besoins. Le coefficient de friction dans le contrôleur 'momentum' qui traduit les impulsions en vitesse et 'stopper', le fait d'être poussé dans un sens ou dans l'autre dans 'walker' et 'needground' etc. (on y reviendra).

Et pour afficher tous ces types (pas loin de 250 en tout), il me faudra plus que mes 16+n petits tiles utilisés actuellement. Je n'ai pas la place pour mettre tout ça dans la "zone libre" de caractères prévues pour les widgets (128 caractères, juste après les codes ASCII): je tombe dans l'espace prévu pour les écrans. Mais j'ai assez de place après les écrans. (oui, ça n'a rien avoir, mais j'avais besoin de le garder sous la main).

Les autres pentes

Du point de vue du moteur de jeu, un niveau est avant tout une grille dont chaque case reçoit des propriétés: solide, solide uniquement quand on tombe, pente, spécial, etc.

(note to English reader: the handwritten text on the pictures is part of the post's text this time).

... A grid, with tiles telling "solid" or "sloped", or "jump through, but don't fall". And sometimes just "special block".

Les "blocs spéciaux" ne sont pas compris par le moteur de jeu lui-même (d'où leur caractère "spécial") mais décrits dans les scripts qui définissent les règles du jeu.

Ainsi, quand Bilou touche par exemple un Bonus, le moteur de jeu récupère quelques bits d'information pour chaque pavé (8x8) de la grille constituant le bloc (16x16) et reconstruit un numéro de bloc spécial (de 0 à 255) qui permettra de retrouver les instructions à exécuter (faire un son, déclencher une animation, donner des points, etc.)

... each "special block" tile provide two bits that are combined to define the "block number" used to retrieve collision properties, hit box and script expression that makes a bonus play a sound and spikes hurt Bilou. The game engine itself, to some extent, doesn't know anything about the special blocks except how to delegate block/object collisions to the appropriate script sections.

Quand Bilou touche une pente, en revanche, le moteur de jeu sait qu'il doit aller regarder une petite table indiquant la hauteur de chaque pixel de la pente. A priori, la forme de cette pente pourrait être n'importe quoi. Mon éditeur de niveau connaît les pentes à 45° et à 22.5°

The height array tells how high is each pixel in the tile. The game engine knows very well what to do, this time. Some tuning could provide an alternate height array to support a different kind of slope, but I haven't used that so far in the game.

Mais voilà: j'aimerais pouvoir avoir plus de souplesse: des escaliers, des coudes, par exemple. Un petit schéma de rien du tout qui traîne depuis des années (2010?) sur un bloc de brouillon en atteste.

"Le mieux serait d'avoir deux boutons 'pente' [dans l'éditeur de sprites] qui forcent le remplissage d'une ligne de 64x16 pixels avec des pentes suivies (les modèles)"

 ajoute encore le calepin.

That "sprite editor / stripe of sloped tiles" approach hangs around in draft mode for years. Because each tile has a unique address in video memory, I had plan to use that address to extend "advanced slope-to-the-right" into "start-of-slope, 0° to 22°". The issue is that the Sprite Editor has no real control of which blocks goes where in memory. Just filling a row of the tile sheet with slope patterns doesn't guarantee that the corresponding tiles will all receive consecutive (and not even aligned either) numbers in the tile set. The solution was in realising that the Level Editor is the component that should solve the more-slope-types problem.

En effet, la technique que j'envisageais alors consistait à utiliser comme information supplémentaire la position du graphisme au sein d'une ligne de blocs dans l'éditeur de niveau (une "tranche" de 16 pavés de 8x8 successifs). On pourra alors convertir l'information de la grille "pente compliquée vers la droite" en "transition douce de 0° à 22°" parce qu'on est dans le 6eme pavé sur une tranche de 16.

Sur les dernières années, ça n'a jamais été mis en service et mes derniers tours d'horizon dans le code de l'éditeur de Sprites me confirme que travailler "par tranche de 16 pavés" serait un vrai casse-tête (le mode et le moment de l'allocation des pavés dans la mémoire vidéo n'étant absolument pas prévu pour ça).

Et cet été vient une idée qui jette un autre éclairage sur ce problème: "Les pentes douces, c'est un problème pour l'éditeur de niveaux. Ce n'est pas quelque-chose à régler dans l'éditeur graphique.

Et l'éditeur de niveau sait par contre traiter des groupes de chiffres pour montrer qu'un bloc spécial est soit un bonus, soit des pics, etc. En prenant donc un type de pavé qui dit "pente compliquée, regardez les chiffres en-dessous pour en savoir plus", je peux diriger le moteur de jeu vers une autre table de hauteurs qui définit la pente (parmi 16 pentes possibles), mais aussi éventuellement fixer le coefficient de friction (sol dur, glissant, boue-qui-ralentit, etc.)

"Special Slope" type merges the behaviour of "sloped tile" and "special block": it will have less bits available to encode the type of slope (e.g. "only" 16 possible slopes), it will require collaboration of multiple tiles, but instead of creating a BlockArea and trying to match collisions, it will just provide an alternate height arrays.

Il me tarde d'essayer ça ^_^

Adding the MapAnim

 Allons-y donc pour l'ajout d'un nouveau type d'animations dans mon moteur de jeu: la modification du contenu de la map elle-même dans le temps. Jusqu'ici, c'était limité à "faire disparaître le bloc en (x,y)" ou "retire-lui ses propriétés, mais laisse-le visible" (pour les bonus cachés). ça peut marcher pour certaines choses, mais ça suppose que les éventuels effets liés à la disparition soient entièrement pris en charge par un sprite supplémentaire. Idéal si l'image doit quitter son emplacement (un morceau de pont qui tombe, un décompte des points qui monte, etc), celà dit.

Let's have one more way of animating things in my game engine. One that would be suited to special blocks, and that update the map content at a specific location over time. The only thing I could do so far would be to shoot a sprite-manipulating game object and make the block disappear. That's mostly appealing if you want a picture to move away, like broken bricks, falling logs and the like. 
The "BlockAnim", used to animate the ink, is not interactive and apply simultaneously to all the instances on screen. It can make SMW coins spin, but it cannot leave a trail of sprinkling sparkles behind.

Now, let's resume the coding, I'll keep you updated on the outcome. I already love the animation I designed last night for the bouncing erasers ^_^.

Il y avait aussi les "blockanims", qui permettraient par exemple de faire tourner les pièces de Super Mario World sur elles-même. On procède alors par une mise à jour de la mémoire "tiles" et toutes les instances de l'objet sont mises à jour simultanément sur l'image à l'écran.

Le nouveau "MapAnim", lui, correspond plutôt aux besoins pour faire bouger un buisson devant lequel on passe, mettre des petites étoiles là où il y avait un bonus, etc. Comme vous pouvez le constater sur les diagrames, le mécanisme qui permet de mettre à jour le niveau (les données gérées par la classe InfiniMap) n'est pas particulièrement simple. Il met en jeu une description de chaque type de bloc spécial (les BlockInfos) et un objet temporaire capturant "tel bloc à tel endroit" (le BlockArea) qui permet d'interagir avec le personnage (GameObject) qui vient de passer par là. C'est finalement InfiniMap lui-même qui procède à l'effacement sur base du résultat du test de collision. La seule bonne nouvelle, c'est que c'est assez souple pour permettre des (petites) portes, des bonus, des bumpers et même les guides invisibles qui font faire demi-tour aux encriers.

pullmask working!

That's quite an achievement for the z-order branch: I got the 'pull mask' technique working properly in the game engine. No more than 14 hours ago, I still had Bilou disappearing (with only one hand remaining) when I made him do a roll-jump. I also altered the engine so that a transition animation *always completes* before another animation is launched. Switching to mid-roll-jump transition to jump/fall transition just kills the whole purpose of transanims (offer some more smoothness). The "new Bilou" track is thus completed and ready for a new release.

Après le décor, c'est Bilou qui - in extremis - est prêt pour la Grrande Riliize de Septembre. Il n'y a pas 14 heures, faire faire un saut-boule à Bilou le faisait disparaître presque complètement... c'est maintenant résolu. Les "transanims" sont donc prêtes à l'emploi et il me restera au plus à faire une copie-miroir du saut-boule (pour qu'on puisse aussi en faire vers la gauche ;) Mes nouveaux outils sprsplit, dumpanim et sprmerge ont été bien utiles dans la bagarre, si vous voulez savoir.

Reste donc juste à peaufiner la map pour faire un premier schooldemo.nds... et là aussi j'ai une bonne nouvelle: je viens de retrouver sous un fauteuil le chargeur de la DS "phat" de ma fée (la DSlite étant en réparation depuis sa Grande Chute du mois de juin et la DSi pas encore homebrew-ready, mais j'y travaille :)

Il me restera donc tous les aspects "collisions étendues" pour l'après-vacances.

transition animations

Jusqu'ici, chaque "état" du comportement de Bilou pouvait avoir sa propre animation. Tomber, marcher, sauter, finir le niveau, etc. Tout ça fonctionne très bien dans Apple Assault, mais avec mon nouvel éditeur d'animation, j'ai envie de profiter de la liberté accrue pour donner encore un peu plus vie à Bilou: pirouette au sommet du saut, demi-tour moins brusques, etc.

Mais là, les choses ne vont plus comme prévu. Il y a de curieux soubresauts dans l'animation du saut de Bilou, qui tient plus du numéro de claquettes aériennes à la Snoopy que d'une performance d'athlète, je trouve. Le problème ? eh bien, j'ai créé une animation "chute" qui fait la transition entre la dernière image du saut et la position traditionnelle de Bilou qui tombe, les 2 pieds en avant et les mains en l'air. Le hic, c'est que dès qu'on entre dans un nouvel état, l'animation de cet état est lancée dès le départ. Donc, dès que je fais faire demi-tour à Bilou pendant son saut, il recommence l'animation sauter/tomber. Idem si je relâche ou ré-enfonce le bouton de saut.

Not so long ago, I was still convinced that having one animation per state would be just enough. Maybe some tricks would be needed to pause the animation until a certain speed would be reach or so, so that you could have funny transitions like turning back or fall-and-crash vs. fall-and-land. After the first attempt of re-doing Bilou animations with AnimEDS, I have to face the truth: that wouldn't work properly, and adding "cosmetic states" just for the purpose of having the desired animations would be a real nightmare: the state machine describing Bilou's behaviour is already quite complex.

Bref, il me faut un nouveau type d'animation, des animations de transition, qui sont déclenchées quand on passe d'un état à un autre, pour ensuite céder le pas à l'animation prévue pour l'état de destination. En théorie, il serait possible d'émuler ça avec des états supplémentaires et des "quitter l'état X quand l'animation est finie", mais pour cette fois, ce serait introduire une complexité tout à fait inutile et un fameux méli-mélo quand il s'agira de trouver les bugs dans un comportement aussi complexe. Bref, c'est ma prochaine intervention sur le moteur de jeu: faire en sorte que "stateJL->stateJR on event [DPAD RIGHT &] () :anim9" soit compris et retoucher les animations en fonction.

What I really need, is the ability to assign a specific animation to a transition. Not only you've got anim X when Bilou is idle and anim Y when Bilou walks, but you have also anim Z that will play when you switch from idle to walk and anim Z' that plays when you switch from walk to idle. As soon as Z or Z' is done, it automatically resumes with Y or X (resp.), and you're already in the "walk" state when Z starts playing. If you switch from fall to idle, however, neither Z nor Z' is played. Maybe you'll use Z" for that.

I've proceeded to some sketch and UML reasoning, and I think I figured out how to start coding that. I can't wait for the house to be clean so that I can start experimenting with some libgeds improvement ^_^

blocking GOBs

Vous vous souvenez peut-être d'un commentaire de mon frère CJ comme quoi "il faudrait quand-même à un moment donné qu'on puisse avoir des ennemis à travers lesquels on ne passe pas même si Bilou est invincible... une chose que je n'avais pas vraiment prévu de rendre possible dans le moteur de jeu de "Apple Assault": Bilou ne sait pas traverser Funky Funghi simplement parce que dès qu'il le touche, il est blessé et repoussé en arrière. Mais pour les encriers et les plate-formes mobiles, ça risque de causer bien d'autres soucis.

It may look like Bilou can't walk through Funky Funghi in the released demos so far, but I'm actually cheating. What happens is that every time Bilou touches Funky, he's hurt and slightly bounce backwards. It wouldn't be possible that have an harmless, blocking sprite with the Apple Assault engine ... fairly annoying to implement inkjets in the schoolzone, isn't it ? I't's been a background question for a while now, and many solutions have been dismissed already, but I quite like the latest one: have object-to-object alignment primitives in GobExpressions so that you can say "hero is moved out of inker's area" between "play a 'ding' sound" and "shoot a sparkle"

Du coup, pourquoi ne pas simplement prévoir quelques actions "de base" d'alignement au niveau des expressions gobScript ? Plus besoin de définir des flags "sprite solide" ou "non-solide", "solide uniquement de haut en bas", pas besoin de venir bricoler les contrôleurs de comportement: on prévoit simplement qu'un des personnages impliqués dans une collision puisse donner l'instruction "repousse l'autre hors de ma zone de collision verticalement" ou "centre l'autre sur ma zone de collision horizontalement". Même la création d'un lien "transporteur/transporté" peut s'y retrouver. Chouettos.

Personnally, I like how "clean" this approach is. No need to hack something about the collision classes, no need to hard-code some directions of collision, no need to expose more things like absolute location or area properties to the gobScript. Just "block-x, center-x, attach" instructions that will be interpreted in a context where both areas are known by the engine. Just one little detail shows up when reading back the code of the collision engine: only "passive objects" will be capable of using those new operations, because state transitions for the "active object" in a collision are taken after collision tests for that object. Who had collided is no longer known. on found [...] (...) is thus not allowed to use any of the 'extra context' information.

Par contre, en relisant le code, je me rends compte que seul l'objet "passif" dans une collision aura la possibilité d'ajuster sa position ou celle de l'autre objet. Toutes les notes on found sont donc en réalité impossibles à moins de changer aussi le coeur du système de gestion des collisions: il faut les ramener à on hit[]. On garde les plate-formes passives même si c'est elles qui contiennent le code qui aligne les objets.

Conséquence: si je veux qu'à la fois l(a plupart d)es ennemis et les personnages puissent déclencher une réaction avec des plate-formes "passives", il me faudra une classe "Solid Moving OBject" en plus de "HERO" et "EVIL".

That may have some impact on the way we script those objects. Most of the use cases do not cause strong problem, except the "platform that carries both heroes and foes". There, I'd love to make sure that 1) the platform is passive, so that it holds the collision logic 2) I don't end up with O(#foes²) tests in collision tests. It sounds like I'll need a SOLID class in addition to HERO/EVIL, so far...
Small battle plan:

1. add a "transported" state. (e.g. standing on platform)
2. enforce coordinates alignment.
3. make sure you're free to move when transported
4. handle disappearing platform.

Implémenter les plate-formes.

Aah. De vraies vacances, ça fait du bien, même si ce n'est que quelques jours... qui se terminaient par un peu de baby-sitting à un mariage cet après-midi. L'occasion de refaire un peu le point sur les problème des plate-formes mobiles. Le point essentiel, c'est que -- tout comme le transport d'objets par Bilou -- ces plate-formes dépendent de la possibilité de lier un gob à un autre temporairement. Un micro-contrôleur "follow", donc, qui déplace p.ex. l'appleman à l'identique de Bilou.

At last some day off ... really off. Not even some Bilou thinking until this afternoon "_". And I had no documentation or current code state with me when doing so, which somehow explained why I focused on a fairly remote problem such as moving platforms. The last thoughts came to the conclusion that being carried would involve a dedicated "follow" micro-controller where a Gob is attached to another.

Be coherent
Comment s'assurer que la plate-forme aura déjà fait son déplacement au moment de déplacer ce qui s'est posé dessus ? Sans ça, on risque d'avoir des effets de "décalage" chaque fois que la plate-forme modifie sa vitesse, comme ceux qu'on peut observer dans Zool.

To make that work, however, it is mandatory that the carrying object has moved before the carried object's movement is evaluated. Otherwise, the player will experience zool-like glitches everytime the absolute speed of the carrier is altered. The FollowController must thus be able to detect whether there is an not-yet-processed carrier situation and execute anticipatively the "animation" of that carrier. That will require some more book-keeping at the core of Engine::animate(), but I think it'd be more flexible than pre-encoded priority levels.

Pour y parvenir, le mieux sera de faire en sorte que FollowController::think() puisse détecter si son objet-cible a déjà été exécuté ou non. On joue là au plus profond du moteur de jeu, qui appelle Animator::play() sur chaque objet qui s'est enregistré via reganim(). J'ai déjà une liste "pending" séparée de "todo", il me reste à noter au niveau de Animator lui-même où on en est. Après ça, il suffira de se faire un petit if (target.state==QUEUED) target.play(). L'objet-transporté voit alors son exécution interrompue le temps que l'objet-transporteur soit mis à jour.

Thou shall not follow the NULL pointer
Avec ce mécanisme, je vais introduire pour la toute première fois une référénce directe entre deux personnages du jeu. Jusque là, je passais systématiquement par le tableau GameScript::gob[] ou je me limitais à une interaction éphémère lors d'une collision. Si je ne fais rien de spécial, une plate-forme détruite pourrait amener les objets transportés dans un état incohérent, voire provoquer de sérieux problèmes au gestionnaire de mémoire ou planter sauvagement le jeu.

The second challenge I addressed is to ensure that we can handle the disappearing of the carrier transparently for the carried object(s). We can do that in different ways, some including list of cross-references, etc. but it looks like the best way around could be to delay actual Animator::DELETE requests by one frame so that the former carrier can be caught in DISCARDED state by FollowController::think() method that would drop then the reference.

Je pourrais exiger du "programmeur gobscript" qu'il règle ça lui-même en prévoyant des états-tampons ou des collisions de désolidarisation, mais ça signifierait qu'une erreur de script dans la machine d'état d'un objet pourrait se traduire en un dysfonctionnement du moteur lui-même... à proscrire à tout prix. Ca risque donc de me coûter un Engine::animate() un peu plus sophistiqué, mais l'idée est de garantir que tout objet "qui s'en va" sera présent au moins pendant une frame dans l'état "DISCARDED".

Gobs Dynamiques

Pour permettre que Bilou soit assailli encore et encore par (e.g.) des Applemen, il me faut ajouter à mon moteur de jeu le support des objets dynamiques. Jusqu'ici, chaque élément "vivant" du jeu (les "GameObjects" ou "gobs") est déclaré dans le script produit par le level editor. Il possède un numéro d'identification unique qui détermine sa place dans la "table" des gobs. Si ça marche plutôt bien pour les ennemis classique, c'est évidemment insuffisant pour les tirs (pensez à un shoot-m-up), les bonus mobiles (le champignon de super-mario), les petites animations sympa (la petite étoile qui apparaît quand Kirby se cogne trop fort) ... et ... les monstres créés à la volée par un "générateur" (qui sont une variante des tirs, finalement).

J'ai déjà en partie la logique qui permet d'invoquer la construction d'un objet depuis la logique du jeu, je dois encore m'assurer que j'ai la possibilité de décrire le fait qu'un tel objet peut disparaître ... et mettre en place un petit test pour vérifier que tout ça fonctionne bien.

So far, most of the sprites in Bilou are statically defined in the game script produced by the level editor. They have a unique ID, well-established initial coordinates and so on. And that works pretty well, mostly because I haven't introduced anything like "shots", moving bonuses or any run-time generated monsters. One of the key elements of "Apple Assault" is precisely that there will be more and more monsters coming like in a Game&Watch.

I've got some of the logic to bring new monsters to life during the game ready, which has been tested for sound effects. I need to check that such monsters can also be terminated, both during the game (e.g. at the end of an explosion animation) and when the level is completed/restarted.
Then I'll need to put this all together and check it indeed works as expected in a small "gedsdemo".

I'm not pretending it's a tedious task. I'm just a bit overwhelmed IRL to start coding something that allocates memory dynamically after office hours.

Et pour être tout à fait honnête, les parts de Munchkin et autres pizza-buffet initiés par mes collègues sur le temps de midi ne sont pas complètement étranger à l'apparente lenteur sur cette tâche.

B_CRUMBLINGFLOOR

Somehow, I stumbled upon this re-implementation of the Manic Miner / Jet Set Willy engine in Visual Basic. I'm unsure on how I should implement crumbling ground in Bilou (or any block animation in response to character's presence). Let's see how a +20 year old game handled it...

Bon, je l'avoue, je suis intrigué par la quantité d'"éléments spéciaux" présents dans un jeu aussi vieux que "Manic Miner" contient, et la difficulté que j'ai à trouver une manière convaincante de réaliser la même chose dans mon moteur de jeu actuel. Du coup, j'ai mis la main sur une ré-implémentation du jeu en Visual Basic. Voyons donc comment les blocs-qui-disparaissent-quand-on-reste-dessus ont été gérés ...

' block type constants
Private Const B_CRUMBLINGFLOOR      As Byte = 2

Block types are encoded in a separate array, with one byte per 8x8 tile. One such type is "crumbling floor". Other block types include B_AIR, B_FLOOR, B_WALL, B_CONVEYOR and B_NASTY (two of them) and B_SPARE (for switches). Jet Set Willy only has one B_NASTY type, and the other one is converted into B_SLOPE. This is consistent with my own engine.

Carles a construit son moteur de Willy de manière à réutiliser les données du jeu telles quelles -- sans être le code original sous Z80, ça donne malgré tout une bonne idée de ce qui aurait pu être fait. En l'occurence, par exemple, la structure de chaque niveau est donnée par un tableau de la taille de l'écran, indiquant quels graphismes utiliser, mais aussi le type de chaque bloc entre 0 et 7.

B_CRUMBLINGFLOOR est celui qui nous intéresse. En cherchant "crumbling" plus loin dans le code, je tombe donc sur la fonction DoWilly (extrait ci-dessous) qui gère toutes les interactions entre Willy et le monde qui l'entoure. DoConveyors ne fait qu'animer des blocs, de même que DoGuardians se contente de déplacer les monstres. Ce sont les sous-fonctions de DoWilly qui détectent les collisions et altèrent le déplacement du personnage. Exactement le genre d'approche que j'utilisais dans Calimero et Bilou en QuickBasic.

What's interesting (for me :-) in Carles' approach of redoing Willy's world is that he operates directly from the tape file of the spectrum, so not only it has the "readability" of modern BASIC (i'm not that much into Z80 assembly ^^") but it still explains the logic of the original game (how switches, witches and stuff are encoded).

If (.mode = [eWalk]) Then
  If Not (WillyCheckFeet()) Then
    ' code for falling stripped out ...
  End If
  Call WillyCheckConveyor(keys)
  Call WillyCheckCrumblingFloor
End If

The DoWilly() sub shown above proceed step by step, handling interaction of Willy with every item "present" in the game. That is, we have DoConveyors or DoGuardians as well, for sure, but they merely perform animation and movement job. WillyCheckConveyor makes sure conveyor pushes Willy. That's the real job.
Let's thus have a look at WillyCheckCrumblingFloor just below ...

Voyons donc WillyCheckCrumblingFloor dont le code est ci-dessous. Après s'être assurée qu'il y a bien un bloc friable sous les pieds de Willy, elle va utiliser FXCrumblingBlock pour procéder à l'animation (décalage du tile d'un pixel vers le bas) et transforme les propriétés du bloc donné en "B_AIR" si FXCrumblingBlock lui dit de le faire à travers la variable f.

o = .x + (.y \ 8 + 2) * 32
For c = 0 To 1
  If (m_RoomBlock(o + c) = B_CRUMBLINGFLOOR) Then
    Call FXCrumblingBlock(m_DIBBack, 8 * (.x + c), .y + 16,
                          CAPaper(m_RoomData(o + c)), f)
    Call FXCrumblingBlock(m_DIBMask, 8 * (.x + c), .y + 16,
                          I_BLACK, False)
    If (f) Then
      m_RoomBlock(o + c) = B_AIR
      Call FXRect(m_DIBBack, 8 * (.x + c), .y + 16, 8, 8,
                  CAPaper(m_BlockCA(0)))
    End If
  End If
Next

FXCrumblingBlock will not be shown here, because it's a pretty dirty function that mixes up game logic, tile animation and rendering engine commands. What I can tell you is that everytime it is invoked, it scroll downs the data of that specific tile, and insert a "blank" line at the top. Once this is done, it scans the whole tile again and sets the "cleared" flag (variable f) to false if it found any non-blank pixel. That's precisely what triggers transformation of B_CRUMBLINGFLOOR into B_AIR.

As the tile "crumbles" exactly one pixel per frame and Willy walks one pixel per frame, it means if you simply walk on crumbling floor, it will be completely crumbled when you're done walking.

Pour moi, c'est là que le bât blesse: FXCrumbblingBlock mélange allègrement rendu vidéo, manipulation des animations et logique du jeu. Je ne la reprend donc pas ici, sachez juste qu'elle décide si oui ou non l'animation est finie en parcourant les pixels qui viennent d'être édités. Si tous les pixels sont "transparents", c'est qu'il n'y a plus du tout de sol et on peut remplacer B_CRUMBLINGBLOCK par B_AIR.

Là-dessus, je vous laisse bras-dessous: il est temps que je prépare ma pitchounette à aller rechercher ma fée à Belle Ile. Ciao.

Try Again ...

La bonne nouvelle, c'est que j'ai enfin un mécanisme me permettant de recharger un niveau quand Bilou s'est pris trop de coup. La mauvaise, c'est qu'à recommencer 20 fois le même niveau, je finis par mettre en évidence des fuites de mémoire dans mon code.
Il est temps de reprendre le code de mon prototype de manière un peu plus rigoureuse, de passer en revue mes classes en suivant les bons conseils++ d'Axel. Jusqu'à 300K qui partent en fumée à chaque vie, ça coûte vite cher sur une machine qui n'a que 4MB.

Good news first: I can at last reload a level when Bilou has been hit too much. The downside is, that this highlight a memory leak in my game engine. Most likely some machine state isn't properly reclaimed. It's time to print my code and read it back with a mop in hand ...

• double invocation of GameScript ctor on reload : >280 K goes away
• not taking care of transitions when cleaning the state machine : 5K
• not taking care of cleaning "guns" : neglectible right now
• other (under inspection) lost things : 5K
• not taking care of OAMs allocation over iterations : invisible sprites after ~16 attempts
  

edit: fixing a stupid and obvious bug reduce the leak from 300K per live to 10K per live. Below comes the checkram() function i'm using to count available memory (that simply allocate as much as possible, then releases everything). Just refrain yourself from using std::whatever to store allocated chunks if you don't want to see a bad_alloc exception thrown in the middle of the process.

int checkram() {
int total=0;
iprintf("grabbing ...");
void **chunks=0;
void **chunk=0, **prev=0;

for (int chunksize = 1024*1024; chunksize>32; chunksize=chunksize/2) {
int n=0;
while((chunk=(void**)malloc(chunksize))) {
*chunk=(void*) prev;
chunks=chunk;
n++;
total+=chunksize;
prev=chunk;
}
iprintf("%i,",n);
}

iprintf("releasing ...");
while(chunks) {
void **chunk=chunks;
chunks=(void**) *chunk;
free(chunk);
}
return total;
}

Bien sûr, une telle fonction est une dépense de resources matérielles inutile si l'on connaît suffisamment l'implémentation de malloc dans l'environnement précis où l'on développe. En l'occurence, ludo connaît une méthode bien plus efficace et élégante pour libnds. And ludo's sources come from this gbadev post

Les collisions

Les collisions, c'est probablement un des éléments les plus important de la gestion des sprites dans un moteur de jeu. Outre l'aspect purement technique "y a-t-il ou pas collision" et l'aspect d'optimisation "comment tester les collisions entre N sprites (potentiellement (N*N-1)/2 calculs) en un temps raisonnable", il y a le côté "logique du jeu": comment vont réagir les différents objets en cas de collision.

Mes premiers jeux étaient assez élémentaires de ce point de vue là: collision = touché sauf si ybilou+8<ymonster. une tentative un peu simpliste de simuler le "pogotage de cafetière à la SuperMario".
Mais ça, c'était du temps du BASIC. En 1997 (déjà programmeur en assembleur et bricolant mon 'mod player à l'époque), je suis à l'unif le cours d'algorithmique de PaDM ou je découvre les joies des listes liées et où SJ me guide tout doucement vers la compréhension que "tes 'registres de sprites' ressemblent à des variables-membre en POO".

Collisions play a major role in game engines. So far, in my former game attempts, i mostly focused on "how do we know there is a collision?" or "how can i support many sprites without slow-down due to O(N²) collisions detection effort?". This time, i'm rather focusing on "what shall we do once a collision is detected?". Collisions are event that will affect the state machine of our sprites... of both sprites that are involved in the collision. My first "serious" design effort on collisions management dates back from "Out'm'Up" game for the 100K-game competition at Inscene'2K (a demoparty in Belgium), the distilled wisdom resulting on my effort to build an "Ultimate Game Maker" between '97 and '99.

Rétrospectivement, ça fait un peu peur: après 10 ans de programmation, je n'avais pas encore terriblement évolué dans ma manière d'approcher les problèmes de quand je programmais mon "Calimero" en BASIC C64 à grand coup de Gotos. Seule grosse différence, je tentais de reproduire en Software (via des "registres" pour la position, la vitesse, la puissance, etc.) le hardware idéal pour mon moteur de jeu. Un variante non-déclarée de la machine virtuelle donc, mais qui me poussait à sur-définir des éléments tout à fait accessoire du genre "combien de bits pour le niveau d'attaque et le niveau de défense du sprite ?"

Out'm'Up, mon dernier shoot en date

Bref, les années "Ultimate Game Maker" sont loin, maintenant. Si je reprends de temps en temps la farde bleue à carreau où tout cela est consigné, c'est plus par nostalgie que pour son contenu. Ou pour dater une technique ancestrale. En juin 2000, par exemple, j'expérimente dans "Out'm'up" une technique dont je ne me séparerais plus: les castes de sprites. Dans toute collisions, il y a toujours un sprite actif (qui cherche la bagarre) et un sprite passif (qui subit la collision). Le sprite passif appartient à une des deux castes possibles (hero ou evil) et le sprite actif ne cherchera pour ses collisions que dans la liste de la caste correspondance. En clair, celà signifie que les tirs de mon p'tit vaisseau ne testeront jamais que les "ennemis" (et pas les autres tirs ou les bonus) et que les ennemis ne se testent pas entre-eux (mais uniquement vis-à-vis du joueur). L'un dans l'autre, la technique s'est montrée tout à fait satisfaisante vu la quantité d'objets à l'écran (on est encore loin d'un Bullet Hell, bien sûr, mais n'empèche).

Active/Passive
The core concept is that in a collision between two sprites, one is *active* and the other *passive*. I.e. the passive sprite has just registered itself in a list of "sprites that accept collisions", but the active sprite is the one who will scan that list for a match. Together with that mechanism comes the idea of *casts*. We only have a limited number of such "lists" where sprites can register -- one per sprite cast. And so far, in all games two casts seems to be enough: heroes and evils. In a laser-ufo collision, for instance, the UFO is passive evil and the laser is active. That means that the laser only checks UFOs for collisions, not other lasers or explosions, bonuses, etc. In the UFO-spaceship collision, the spaceship is passive hero and the UFO is active. You'll note that the cast of the active sprite is irrelevant in a collision. So far, it has proven much more efficient and flexible than adjusting "power levels" (in RSD Game-Maker, all sprite had a power level, and when the collide, the one with the highest level kills the other one. period)

Si ça peut paraître un peu annecdotique dans un jeu de plate-formes, ça n'en reste pas moins la base de la gestion des collisions dans ma dernière démo. J'y ai ajouté le système des masques inspiré du code de Jill of the Jungle qui, une fois que j'aurai bricolé l'évaluateur d'expressions, permettra de faire réagir les personnages différemment selon la "source" de la collision. Petit exemple ici avec le "pendat" et ses réactions possible en cas de collision avec un objet lancé, avec un encrier bloquant ou avec le personnage.

In a platforming game like Bilou, this needs to be extended. Not only the cast of the 'hitter' is important, but also its nature, which i intend to implement through collision flags, drawing inspiration from Jill of the Jungle source code. Every "active area" defines a set of flags that identify "what it is" while "passive collision areas" indicate "what they are sensitive to". You can then have a penguin monster that takes a single hit unless it is hit by F_FIRE, which kills it instantaneously.

While the cast of a sprite never changes, each state can define various areas, with different flags. That allows us to have e.g. a special "strike" move with an additional, powerful attack area or a move that unveils a weak point. The game script defines transition on a per-area basis, so what happens when you hit one weak point can be different than what happens when you hit another area. Now, i still have to "make it so" in the code, and make the result of "area masks" visible to my "GobExpressions". In an attempt to separate the concerns, each sprite will take care of its own state manipulation: we won't have the pencil 'killing' anyone directly, but i expect that i might need some information about "the other guy" anyway (relative position, speed, etc.)
J'aurai donc bientôt réglé le bug qui "blesse" Bilou à chaque fois qu'il ramasse un bonus et un état dédié 'blessé' me permettra de rendre plus facilement Funky Funghi infranchissable. Par contre, rendre certains ennemis "solides", même quand Bilou est invulnérable temporairement, ça reste un challenge.

2024 #choice reality check: Well, now that I have access to countless hitbox reveal (mostly by Upsilandre), it turns out that having separate active and passive boxes (typically called hitbox and hurtbox) is the de-facto solution. Having a separate list for player and foes also is. But the more I progress, the more it shows that additional casts will be required for bridges and things alike. Nothing has been coded so far, though.