tiled milestone

tiled [t.a.g.]

J'ai une DS

J'attaque la DS

Premier Bilou sur la DS

SpriteEditor DS

Les choses prennent forme. Je peux éditer un sprite avec un outil 'crayon' ou 'block', et grâce au code de la "libfat" de chism & dragonminded, je peux charger et sauver mes sprites sur la carte SD.

Bilou .. l'ancien et le nouveau ?

Bion, il y a évidemment déjà eu un jeu Bilou, qui était programmé en QuickBasic pour DOS et qui a finalement fait usage d'une bibliothèque SoundBlaster (oui, m'sieur), même si ce n'était pas du grand délire (juste un son "hihoo" au début du niveau, un "uh!" quand on est touché, et encore).
Alors en grand, vous avez un aperçu de ce que ça donnait ... et en petit de ce que ça pourrait donner avec les nouveaux graphismes (pixelisés sur la DS).

J'ai encore du boulot pour les "feuilles" de mes nouveaux arbres, notamment parce qu'il me manque des couleurs compatibles dans ma palette pour l'instant (elle vient du jeu "Tyrian", qui ne s'est pas embarassé de teintes vert/jaune :P) J'ai essayé d'appliquer les techniques de Dan, mais il y a encore un peu de boulot avant d'avoir un décor vraiment convainquant.
Oh, et j'avais fait marcher la pomme, aussi, mais ça, c'est pas encore top (et je l'ai effacée par erreur hier, donc je pourrai en refaire une nouvelle :P)
Cette fois encore, le "mockup" fait appel à un zoli (?) dégradé pondu par The GIMP ... 'faudra que j'intègre qqch de similaire pour mon SEDS ...

edit : Vous notez l'appleman primitif et un "bubblebat" endormi dans l'arbre.

Project started

Screen Template

Vous courriez ? J'en suis fort aise! Eh bien, Sautez, maintenant...

• on pourrait diminuer la gravité (se dire que tomber d'un pixel tous les 1/60 secondes, c'est un peu beaucoup: vous avez traversé 1/3 de la hauteur de l'écran en seulement une seconde)
• on pourrait ajuster nos routines de tests pour qu'une vitesse de plus de 8 pixels sur 1/60 secondes ne pose pas de problème technique
• on pourrait revoir le modèle du saut et "tricher" un peu avec les lois de la physique...

Let's Rumble !

Sprite Editor on the DS: the SEDS approach.

/* reprogramming the background layer 3 (colored artwork)
* so that it is 50% zoomed and still appear at (xbase,ybase)
*/
SUB_BG3_CX = (-xbase*2) <<8;
SUB_BG3_CY = (-ybase*2) <<8;
SUB_BG3_XDX = 2 << 8;
SUB_BG3_XDY = 0; /** XDY and YDX useless in that case. **/
SUB_BG3_YDX = 0; /** see TONC tutorial if they puzzle you **/
SUB_BG3_YDY = 2 << 8;

.: easy :: normal :: hard :.

SEDS Multipage

tiles extraction ...

#!/usr/bin/perl
use Image::Imlib2;

$image = Image::Imlib2->load($ARGV[0]);
print STDERR "$ARGV[0]: ".$image->width."x".$image->height."\n";
while ($ty<$image->height) {
$tx=0;
while ($tx<$image->width) {
foreach $y (0..7) {
  foreach $x(0..7) {
($r,$g,$b,$a) = $image->query_pixel($tx+$x,$ty+$y);
$r=pack("C1",$r);
$g=pack("C1",$g);
$b=pack("C1",$b);
$colors{"$r$g$b"}=$ncolors++ if !exists $colors{"$r$g$b"};
$tile.=$colors{"$r$g$b"};
  }
}
$tiles{$tile}.="($tx,$ty)";
$tx+=8;
$tile="";
$ntiles++;
}
$ty+=8;
print STDERR ".";
}

print scalar(keys(%tiles)) . "unique tiles (/$ntiles) detected\n";
print scalar(keys(%colors)) . "unique colors detected\n";

exit 0;

2D sur la DS : quelques chiffres ...

single tile encoding, from LiraNuna's tutorial

Ideas for smooth scrolling on the DS...

Map bases always have 32×32 entries. To create bigger BGs (Like 64×64) you need to use several map bases. As for tile bases - If you want to make use of the full tileset (1024 tiles), you will have to use several tile bases - 4 Tile bases for 256col full tileset, and 2 Tile bases for full tileset of 16col mode. Since the Map bases and the Tile bases are located on the same region in VRAM, they can overlap. Since a map base is 2Kbytes and a Tile base is 16Kbytes, each Tile base contains 8 Map bases.

1. we can't have smooth scrolling in a 64x64 area if we reprogram 32x32 entries (dma copy) at once (<-- cyril contests this, see next post).
2. we could do the "John Carmack" trick, using hardware scroll in the 64x64 area and then "jump" to a second 64x64 area when we're about to move out, but that would kind of be silly on hardware that allows to "wrap around" the area with our viewport (which the PC hardware couldn't do properly).
3. doing "double-buffer" of the map will involve a burst of up to 8K memory transfer (through DMA), potentially leading to gameplay lags
4. we have better things to do with the other maps (e.g. additional planes)
5. DMA copy for the map might be interesting to save CPU (well, it is actually frozen during the move), but it requires that the offscreen map is a verbatim copy of what's used on screen. manual copy of the map parts instead allow us to use more bits for tiles meta-data and wipe them as the tiles are moved on screen. That would give us 64 types of block, more than we need to encode "slipperiness", identify bonus, etc.
   

Scrollons encore

Alors, quel est le truc ? Eh bien voilà. Notre niveau n'est pas construit à partir de tiles 8x8 mais à partir de blocs 16x16. On peut donc supposer que la lave prendra bien 16x16, et ce n'est pas juste 2 bits (de 12 à 15) que l'on a pour faire la différence entre les picots, la lave ou les bonus, mais bien 4x2 bits (2 dans chaque tile faisant partir du bloc 16x16). Soit 256 types de blocs spéciaux possibles. De quoi voir venir...

Yes! Ca scrolle!

edit 2024: Le CVS, c'est fini, et le travail sur le scrolling arrive d'un bloc dans le repository mercurial. Entre les deux, il y a eu un SVN où on voit le travail évoluer jusqu'à l'étape ça marche (4 décembre).

faire et défaire ...

autre bonne nouvelle: les animations marchent! enfin, quand je dis "marchent", je devrais plutôt dire "rampent", puisque pour l'instant, seul le "petit ver jaune" de la forêt a été animé.
Je suis pas mal fier de mon coup, je dois dire. J'ai gardé un code tout à fait générique, qui est paramétrisé par un petit script de commandes. Petite astuce, les déplacements du ver sont intégrés dans la séquence d'animation elle-même, ce qui permet d'avoir un contrôle plus fin du déplacement (pour vraiment donner l'impression que le ver rampe, et pas qu'il glisse sur le sol pendant qu'il se tortille, comme on le voit si souvent dans les jeux amateurs).

En revanche, si je commence à être assez rôdé sur les std::vector<GameObject*>::iterator, je suis encore un peu perplexe sur les destructeurs virtuels. L'environnement d'exécution du "petit script" en question doit être "renettoyé" chaque fois que l'on veut relancer le script, et pour l'instant, ça se traduit encore trop souvent par un écran rouge de la mort. J'aime bien la méditation, mais toutes les 5 minutes, ça devient lassant. (quicklink: l'assembleur ARM par TONC: http://www.coranac.com/tonc/text/asm.htm)

D'un autre côté, j'ai un peu relooké mon script qui traduit une image (comme celle ci-dessus) en un tas de tiles et les données pour la map, de sorte qu'on puisse lui indiquer quelle couleur doit être considérée comme "transparente", et il s'arrange tout seul pour que les tiles entièrement de cette couleur soient considérés par la toute nouvelle routine de "testpoints" comme étant "EMPTY", tout le reste étant de type "BLOCK"...

edit-PS: la première version du level editor (sans sauvegarde) n'arrivera qu'en avril de l'année à venir. Là, on est donc toujours dans une "composition" de niveaux à coup de Gimp suivi d'une conversion avec détection des tiles redondants par un script fait-maison.

*bounce*

• rebondir si sa vitesse est trop élevée
• s'arrêter si la vitesse n'est pas trop grande.

Même le maniement du joystick est géré de cette manière.

# gestion de la chute de Bilou.
state4 :anim0 {
   using gravity
   testpoint off (4,16)
   testpoint off (12,16)
}

state5 :anim0 {
   using stopper
   testpoint on (4,16)
   testpoint on (12,16)
}
# si la vitesse est trop élevée, on rebondit en la réduisant de moitié.
state4->state4 on fail [v1 $40 >=] (v1 2 / ~ :1)
state4->state5 on fail [t]

En avant. Essayons de voir si j'arrive à fixer la caméra sur Bilou pour le promener dans le niveau. Et en même temps, je vais tenter de faire un petit .nds de démo pour que vous puissiez tester ça sans devoir comprendre le fonctionnement de mon 'runme'.

gedsdemo : get it!

Bilou par Wifi ...

edit: comme je m'y attendais, c'est plus que probablement dans la gestion des animations que se trouve le gros bug. C'est du vieux code d'avant que je ne me mette à la bibliothèque standard du C++ (vecteurs, maps, etc) qui est encore plein de malloc(sizeof(x)*n) et qui manque de if(i>n) return; si vous voyez ce que j'veux dire

Cursor for picking tiles ...

• [done] move cursor around
• [done] load/store tiles from the cursor
• [done] dismiss cursor
• [done] clicking the sheet moves the cursor
  
• [done] fix 32x32 grid edition
• [done] meaningful buttons in "file" window
• [done] fix sheet-to-sheet copies
• [done] decouple grid/sheet size
• [done] toggle grid size when "zoom" button is pressed.

Bon anniversaire, Bilou

Eh oui, ça fait maintenant deux ans que je bricole sur ma DS. Et figurez-vous que en voulant retracer l'historique, ma mémoire m'a fait défaut. Elle n'a apparemment retenu que les évènement "vie réelle" (achat de maison, mariage, conférences, changement de voiture, etc) et éventuellement greffé les bouts de développement DS qui s'y rapportaient.

Calme plat ... il fallait s'y attendre :P

C'est la grande reprise de "runme", qui jusque-là pouvait télécharger des fichiers par wifi, voire en afficher certains (.pcx, .spr, .it ...) mais c'est tout. Deux petites lib' releasées au bon moment (l'attente de ma thèse relue) vont permettre la pierre d'angle de mon développement DS : l'auto-update par wifi, ou comment un programme va récupérer une nouvelle version de lui-même et la démarrer sans autre intervention qu'un clic de l'utilisateur.

Suivra une ré-écriture de SEDS pour qu'il puisse gérer plus de sprites (multi-page) et "sortir" vers runme (qui sera aussi en mesure de lancer SEDS), qui sera annoncé sur les forums (à partir de Player Advance) vers la mi-octobre.

"Use the Source, Luke"

montre moi ta VRAM et je te dirai qui tu es ...

analysis paralysis ?

• [just started] la gestion des bordures. Même si je garde au départ un système tile-based, les plate-formes mobiles et autres sables mouvant devront être capable d'altérer le comportement des sprites
• [ongoin] les pentes. Je veux que Bilou puisse se déplacer sur des plate-formes qui ne soient pas uniquement horizontales.
• [done] l'animation modulaire. ou "à la rayman", qui me demande un éditeur d'animations spécifique en plus des ajustements dans le moteur de jeu
• [done] les collisions perso-bloc qui soient plus maniable que juste le "petit bonus" que j'ai pour l'instant. Plate-formes qui disparaissent, échelles, etc.
• [done] des réactions aux collisions perso-monstre. Avec une question pertinente "et comment fait-on perdre une vie, au fait"

un autre mot sur la VRAM

BG Mode
Engine A BG Mode (DISPCNT LSBs) (0-6, 7=Reserved)

Mode  BG0      BG1      BG2      BG3
0     Text/3D  Text     Text     Text
1     Text/3D  Text     Text     Affine
2     Text/3D  Text     Affine   Affine
3     Text/3D  Text     Text     Extended
4     Text/3D  Text     Affine   Extended
5     Text/3D  Text     Extended Extended
6     3D       -        Large    -

Xargon : may the source be with you ...

int cando (int n, int newx, int newy, int ourflags) {
 int x,y,temp;
 int flagor, result;
 int startx, endx, starty, splity, endy;

 startx=newx/16;
 starty=newy/16;
 endx=(newx+objs[n].xl+15)/16;
 endy=(newy+objs[n].yl+15)/16;
 splity=(objs[n].y+kindyl[objs[n].objkind]+15)/16;

 flagor=f_notstair;
 result=0xffff;
 for (y=starty; y<endy; y++) {
       if (y>=splity) flagor=0;
       for (x=startx; x<endx; x++) {
         temp=(info[board(x,y)].flags|flagor)&ourflags;
         result&=temp;
       };
 };return (result);
};

int trymove (int n, int newx, int newy) {
 int ourflags;
 ourflags=f_playerthru;

 if (newy>objs[n].y) ourflags|=f_notstair;
 if (cando (n,newx,newy,ourflags)==ourflags) {
    moveobj (n,newx,newy);
    return (1); // successfully made it to new location.
 } 
 else if (cando (n,objs[n].x,newy,ourflags)==ourflags) {
    moveobj (n,objs[n].x,newy);
    return (2); // could only move vertically
 }
 else if (cando (n,newx,objs[n].y,ourflags)==ourflags) {
    moveobj (n,newx,objs[n].y);
    return (4); // could only move horizontally
 };
 return (0);    // couldn't move at all.
};

World Collisions

The approach of "the nature of a tile" is thus interesting: it can express (through flags) who can do what over that tile. This is a concept used both in Xargon and (afaik) in the side-scrolling Rayman game, where you have "monster-walls" that monsters can't cross (though Rayman don't feel them). This is imho an elegant solution to many level design problems. Let's take the walking block of "Inside the Machine", who wanders around its initial location, "guarding" a virtual spot even if it could theoretically walk further. Morukutsu relied on a "distance" counter that is increased/decreased through the animation code, which won't let you alter the 'coverage area' of the ennemy through level design, but only through implementation ... not so fun.

if cando(dx,dy) then (x,y) := (x+dx,y+dy)
elsif cando(0,dy) then (x,y) := (x,y+dy)
else { 
  (x,y) := (x,align_on_tile(y+dy)); 
  trigger_testfail_event 
}

So, do we still need any testpoint ? after all, Xargon's cando() used in controller-specific code seems to be fine. Actually, there's something that cando() cannot catch: mixed situations. The controller will be able to tell the game engine that it's no longer possible to fall, but it can't tell whether we are now landing, diving, or bouncing against a corner. This is where we *really* need test-points, and you'll notice that testpoints are only used for state transitions.

I still have to figure out the best way to convert my codebase to this new approach -- the fact that i'm busy working on the real-world house not really helping -- but i think it might be what i've been looking for since the start of the project.

• [done] extract persistent state (found in map and accessible by other classes)
• [done] iGobPubstate::cando(x,y,flags)
• [done] manipulate tile_flags array (that translate tile type into tile flags) from the script
• [done] controllers report "fail" when no "cando()" can be applied
• [done] who updates coordinates ?
• [done] update GameObject::play() and trymove()
  

BBL metadata.

1. Bloc, Floor, Wall ou ciel (-)
2. Pickme : l'objet peut être ramassé pour l'inventaire
3. g, l ou r : gravité normale, vers la gauche ou la droite. Les autres combinaisons ne sont pas reconnues.
4. a : bloc animé,
5. t: réagit au contact
6. bonus/malus : H=hitpoints, x=kills, + : score
7. L = 1UP, K=clé/porte.

1c (r01 c13): 400100000000000000ffff1b64001c0400010000  --ga-x-  (a1b,100)(h-1)
^    coords   |--- complete hex dump of meta-data ---|  |flags|  |---details--|
+- block number

Le Bilou Nouveau est arrivé...

Suivre le développement du projet ...
Read progress reports

parallaxe ... foireux.

• [done] have the "level exit" activated when enough apples have been picked.
• [done] increase homogeneity of collision detections
• [done] pre-define values when initializing GOBs in script (e.g. set Funghi's counter)
  
• [done] blocking ennemies: e.g. you can't pass through Funky
• [done] bilou can tell whether he has been "hit" by an ennemy or an apple
• [done] code cleanup : upgradable "block info"
• [done] register "action on counter back to zero"
• [think..., done] substrate for "shooting" (dust clouds, stars, etc.)
• [wish] code cleanup: more states, more anims (array -> maps in GameScript)
• [wish] support multi-palette environment (by now, i'm just lucky it works fine !) or 16 color backgrounds
  
• [wish] provide a cleaner way to have parallax scrolling (and more maps)
• [done] make sure we can change/end level!
• [done] add sound fx support
• [wish] add music selection in the GameScript!
• [done] loading SpriteSet with odd number of colors properly
  
• [done] execute scripts non-interactively in demos.

bilou.cmd

• [done] composition de contrôleurs
• [now][done] gobs dynamiques (tirs, étoiles-bobo, etc) et état "nil" pour les détruire, qui utiliseraient de nouveau un mécanisme de liste auto-itérée pour leur gestion
• [done] utilisation d'actions externes dans les expressions de la machine d'état

Sound Effects

95% done.

• Techniquement, donc, le moteur de jeu est prêt pour la prochaine petite démo.
  
• Artistiquement, je voudrais encore améliorer un peu le feuillage des arbres.
• Niveau gameplay, je dois finir le comportement de l'appleman et rendre visible la sortie du niveau 1, histoire que vous puissiez essayer le niveau 2 ^_^

Un Bilou tout neuf.

Level 2 is merely there to demonstrate we can now have multiple levels.

• démarrage simplifié, un seul fichier grâce à l'EFS de Noda
• musique de Pierrick H et (quelques) bruitages grâce à la libntxm de 0xtob
• gare à Funki Funghi (image de droite), le champignon écrabouilleur
• gare à l'appleman, débonnaire en apparence, mais tenace
• il vous faudra au moins 16 pommes pour passer le panneau du 2eme arbre (cf. image de gauche)
• un deuxième niveau non-terminé
• plein, plein, plein d'améliorations internes dont vous ne vous souciez probablement pas mais dont je suis super-fier

En cours de jeu, sautez avec X ou Y et dirrigez le personnage (la boule bleue, faut-il le répéter) avec le Dpad. Start passe le jeu en mode pause debugging, L+START revient au mode normal.

The sign points to the left: you haven't collected enough apples to access the second half of the level.

• sound & music by Pierrick H thanks to 0xtob's libntxm,
• ease-of-use thanks to Noda's EFS
• new monsters
• improved controls
• one extra (draft) level
• 5 hitpoints per lives and unlimited lives
• a few hidden places you needn't to find
• some more gfx
• parallax scrolling

Sprites à Priorité Dynamique

Handling of slopes.

• dx : horizontal speed for this step.
• tile(x) : returns the tile holding a given coord.
• end_of_tile(x, dir) : last pixel of tile containing x ends when you go towards dir.
• next_tile(x,dir) : first pixel of the tile after tile containing x when you go towards dir. next_tile(x, dir) == end_of_tile(x, dir) + (dir>0)?1:-1
• ground_height(x,y) : in the tile under (x,y), the height of the ground at specific location (x,y). 0 means "this is a sky tile", there is no ground to stand here. -1 is the lowest pixel of the tile, at -7, you should be on the highest pixel of the tile, and at -8, you should actually not be on this tile, but on the lowest pixel on the one just ahead.
  

Enfin, des pentes qui marchent !

Slopes, Cont'd.

limitations of Tony PA's engine

The reason why I want slopes is level design : they allow a regular "walker" ennemy to find itself in a better tactical position (above you -- "in your functional blind box", would say Kirby Kid), as anyone who played Commander Keen knows. Until a "sloped level" is properly built, I altered the part of my level 1 that features appleman with all possible slope combinations. Walking right-to-left, you'll encounter (g), then (h) and (e) near the wall. So far, only (h) causes coding trouble: Bilou just stop at the top of that "spike" and refuses to move any further. The Applemans happily work around this situation by either turning back (if Bilou is not in sight) or jumping over the spike to attack Bilou. Cases (f) and (h) are automatically covered by the cando() tests that complement hotspots in my engine.

The algorithm I presented a few weeks ago is still mostly unmodified, but it had a major defect: it only moves you along a slope. The fact is that it should also inform the caller whether 1) we are on normal ground (and thus will fall if we can) 2) or on a slope (and thus don't fall) or 3) if we just couldn't move because there's something in our path. A bit more critical thinking is needed here to lay things down properly.

Tracking Memory Bugs

FileWidgets

Monsters & Levels.

grimpons, grimpons

Bon, c'est pas le tout de dessiner des pixels de lianes/vignes sur lesquelles grimper. Maintenant, il va falloir coder ça, aussi. La base est relativement simple : un nouveau type de tile qui permet l'utilisation du comportement "grimper", au même titre que le sol permet de marcher.

1. le joueur appuie-t-il sur la flèche vers le haut ?
2. Y-a-t'il une liane à laquelle s'aggriper ?

C'était bien ça ...

Vuoi una mela ?

TrackSequence : public Animator

Ce coup-ci, c'est fait: j'ai enfin la possibilité de programmer des séquences d'actions en réutilisant la partition musicale comme "séquenceur". Ce n'est encore que moyennement utile vu le petit nombre d'actions disponibles dans le "dictionnaire" de guns.cxx, mais ça me permet par exemple de faire tourner une petite musique "Level Clear" avant de lancer le démarrage du niveau 2. A terme, je devrais pouvoir y insérer fade-in, fade-out, etc.

Small step for me, Giant leap for Badman

vsnes à la rescousse...

Yahoo!

Goro mode activated

• [bugfix] : la "petite main" réapparaît quand je sélectionne qqch dans la spritetable de droite, AnimWindow
• [bugfix partiel] : si je réouvre une animation 2-mains, elle est "promue" animation 3-mains-3-pieds :P
• [now] : si je sauve par START+R+R, l'animation en cours n'est pas réécrite dans la feuille d'animations avant la sauvegarde (et donc pas sauvée).
  

deep ink pit mockup tout moche

Happy New Year !

Picking a Tile size.

2 tiles de haut contre 1 de large. Pour un personnage bipède, c'est l'idéal, si je tire les conclusions qui s'imposent de la lecture du Sonic Physics Guide. Attention, je parle ici de la zone de collision. À aucun moment celà n'implique que l'on doive caser tous ses dessins dans un rectangle de 20x40 comme dans le RSD game-maker, hein ?

Difficile de dire si c'est le cas ou non pour Bilou, par contre. Ok, il est loin d'avoir les proportions de l'homme de Vitruve, et sera plus proche de 16x24 pixels dans la school zone qu'autre chose. Difficile aussi de lui appliquer la règle "un obstacle doit plus ou moins arriver à la ceinture pour avoir l'air un rien costaud"... Mais je garde ça en tête pour la révision de Badman...

fusion!

Grand merci à sepcot pour son tuto. Mes déviations "moteur de collisions" (newcollide) et "moteur d'animation" (companim) sont maintenant intégrées sur le "tronc" de développement, là où se trouve également runme, qui intègre transfers wifi, lancement des éditeurs et petit moteur de jeu pour le prototypage rapide pendant le temps de midi. On va pouvoir attaquer la school zone plus sérieusement ^_^ A commencer par un dumblador qui marche ...

Compound Gob: release

Where You See is Where It Is

• 3 mars: fusion du code expérimental pour les nouveaux sprites composites dans le moteur de jeu. Il faudra quand-même pas mal chipoter pour pouvoir éditer la school zone dans LEDS
• 18 mars, le fichier de commande pour dumblador est écrit. C'est lui qui servira de démonstration des nouvelles capacités du moteur de jeu, mais rien à l'écran ne trahit encore la présence de dumblador :P
• 24 mars, release source du moteur de jeu et de ses outils.
• 26 mars, "reality check": pour pouvoir positionner Dumblador dans un niveau, he dois faire une révision d'AnimEDS pour qu'il enregistre la miniature à afficher;
• 25 avril, je peux ajouter des dumbladors qui font quelques pas (sur-place) mais il me manque des outils pour définir quelle portion de l'espace ils occupent dans le jeu.
• 7 mai, comme d'habitude, j'ai zappé la case 'feedback à l'utilisateur' et mes outils sont à la limite de l'utilisable.


• 15 mai; ok. Je peux enfin positionner de manière fiable un dumblador dans mon niveau

Là, j'ai AnimEDS, LEDS et le moteur de jeu qui sont d'accord sur la manière d'interpréter la position d'un personnage composite dans un niveau. Ça n'aura pas été sans mal.

J'ai même le début de la définition des déplacement, quoi que ce soit encore très "courbes elliptiques en espace discret toroïdal", si vous voyez ce que Bouli veut dire ... non ? bon, bin Dumblador reste sur place pendant presque toute l'animation, puis arrive d'un coup à une position improbable qui n'a pas grand-chose en commun avec le déplacement qui était prévu, donc:

1. faire en sorte d'avoir en mode émulateur (sur toutes mes machines) une animation de déplacement, histoire d'éviter de re-faire l'animation à chaque test;
2. éliminer les effets du type "la position de la tête n'est remise à jour que si la tête est déplacée (relativement) dans l'animation.
3. garantir que l'info du type "verouillé sur le membre #3" est maintenue à jour quand on se déplace le long de la timeline.
4. trouver le bug.
5. Faire en sorte que les repères de positions dans LEDS restent corrects quand on se déplace dans le niveau ^^"

Dumblador turns back

anim1 = spr:0
anim2 = spr:3
statL0 :anim1 {
using walker
selfmove
test 0 (2,4)-(8,14) 0001
area 0 (0,0)-(8,4) 000A
}

statR1 :anim2 {
using walker
selfmove
test 0 (2,4)-(8,14) 0001
area 0 (0,0)-(8,4) 000A
}

statL0->statR1 on fail (100 :0)
statR1->statL0 on fail (100 ~ :0)
statL0->statR1 on hit0 (100 :0)
statR1->statL0 on hit0 (100 ~ :0)
end

transanims get rolling!

pullmask working!

First multi-palette LEDS screenshot

throwing bladors

• [done] looping move should only be generated for looping animations
• [done] initial Mx,y statement should be ignored by the game engine (actually, everything that delays the rendering of the first frame of the animation should be skipped). That will partly solve the "landing bug".
• [todo] most of blador's debugging could have been avoided if we had the state-initialisation expression feature implemented.
• [done] not detaching an attached GOB when "throwing" it may have weird effects, but I would have liked the display list to be re-ordered so that such side-effects wouldn't have systematically occured.

More slopes

J'ai envie d'avoir plus de souplesse dans les pentes que juste "45° dans quel sens?". Si ça n'apporte pas grand-chose au niveau du gameplay en tant que tel (un ennemi-marcheur en haut d'une pente garde un avantage stratégique même pour d'autres formes de pentes), ça permet de construire des niveaux plus "organiques", ce qui n'est déjà pas si mal.

En revanche, j'ai déjà saturé le nombre de "type de blocs" dont je dispose vu ma technique d'encodage. L'idée cette fois serait de combiner le "type" (encodé par élément 8x8) avec la position du tile au sein d'un bloc de 64x16. Si ça reste jouable au niveau du moteur de jeu, ça demande un support spécifique dans l'éditeur de sprite pour "préparer" ces blocs de 64x16 contenant 16 tiles alloués de manière contigüe dans la SpriteRam (alors qu'ils sont normalement alloués par bloc de 4) puis de les disposer conformément à ce qui est prévu pour un des type d'obstacles souhaités.

En comparaison, le moteur de SMW (selon Lunar Magic) offre 3 angles de pente: 'normal' (22.5), 'gradual' (11.) et 'steep' (45). Au niveau du gameplay, les pentes 'steep' étaient les seules à pousser d'office le joueur vers le bas (si ma mémoire est bonne).

Un grand pas en avant ...

Souvenez-vous: dans Apple Assault, si les pentes fonctionnaient presque correctement, il me restait une certaine probabilité que Bilou se "bloque" arrivé au sol, et ce n'est qu'avec la révision du moteur de jeu en Septembre dernier que le bug fut corrigé. Mais on était pas tiré d'affaire pour autant...

Commençons par un rappel du fonctionnement des pentes dans mon environnement découpé en pavés (les "taïlze/tiles"). Bilou n'y est qu'un rectangle qui doit pouvoir naviguer sans rentrer dans les tiles solides (noirs). Il possède en plus un point de référence (hot spot, en rouge vif sur l'image) qui doit rester en contact avec le sol lorsqu'on suit une pente. Pour avancer d'un pixel vers la gauche, le hot'spot passe d'abord dans un tiles complètement vide (gh=0) où il n'y a pas de sol à suivre. La fonction do_slopes détecte ça et teste du coup le tile situé juste en dessous. Son pixel le plus à droite correspond à une hauteur gh=-8. On se retrouve ré-aligné sur le prochain pixel ... tout va bien.

Le problème apparaît seulement lors d'une transition pente/trou, comme j'en ai ajouté sur le bord des livres. Ici, lorsque'on regarde sous le tile vide, il y a ... un tile vide. Pour do_slopes, celà signifie qu'il n'y a plus de pente à suivre.  Idéalement, on devrait donc juste se retrouver "le long de la ligne bleue" inférieure, qui empèche Bilou de tomber jusqu'à ce qu'il l'ait complètement quitté. Mais voilà, à ce moment-là, on est pas encore sur le sol! Du coup, lorsqu'on teste s'il est possible de tomber d'un pixel, la réponse est "oui" et le contrôleur envoie un FAIL.

Seulement, voilà, l'échec du contrôleur n'implique pas forcément une chute. C'est à travers les transitions du comportement de Bilou que les choses vont maintenant se jouer. Tomber d'un pixel ne serait pas impeccable, mais celà nous conviendrait. Seulement, pour celà, il faudrait que le point-test placé au sol indique du vide ... et étant décalé sur la droite, il est toujours dans la pente! Du coup, c'est vers l'état "do_slopes. C'est ainsi qu'on parvient finalement à quitter le livre après ce qui semble être un instant d'hésitation.

NSMB Editor !

School level delivered!

Special Blocks

• each special block has 4 [0-3] digits laid out on the map that identifies the block type
• block % statements allow to link collision areas 
• first digit identifies who can interact with the block
• second digit gives the properties that the block should have. So far, x0yz behaves like an empty tile, x1yz like a water tile, x2yz like a wall tile and x3yz like a floor tile. Perferably, dedicated properties would be used, requiring an update of infiniMap::getTileType.
• 
  

2D + 3D = ^_^

edit: huzzah! it works!

runme3D

Collision avec le monde

Au milieu de ma série de scans sur le thème "Critical Link", je retombe sur un diagramme UML représentant la séquence d'action qui découle d'une collision entre un personnage et un bloc spécial. Comme il va prochainement me falloir gérer des collisions entre crayons fixes et taille-crayon, je blog en stock ...

pinky LEDS

Les tiles ... du C64 à la NDS

Chose plutôt inhabituelle, après pas loin d'un an de bidouille, mon premier article sur le site de la BilouCorp est finalement en ligne. J'avais envie d'y faire une rétrospective sur ce qui a fait de certaines machines des plate-formes assez merveilleuses pour la programmation de jeux vidéos et de jeter un coup d'oeil à la façon dont leur caractéristiques techniques ont formatté les jeux qui ont tourné dessus. Le premier jet, c'est donc sur les les tiles, ces petits pavés graphiques qui m'ont accueilli sur le C64 dans "Space Mission" et que je reprogramme dans SEDS pour vous faire les jeux de Bilou. Bonne lecture.

Keen: ClipToWalls()

Pour éviter que Keen ne passe à travers les murs ou ne reste bloqué en bas d'une pente, les niveaux attribuent à chaque bloc de 16x16 pixels un ensemble de propriétés. C'est la technique des "tiles" bien connue de la plupart des lecteurs. Ce qui est particulier dans le moteur d'ID software, c'est la possibilité de définir séparément l'animation, la pente de sol, le comportement en tant que bloc spécial (valeur du bonus, couleur de la clé, etc.) et la polarité du mur.

La notion de "polarité des murs" est intéressante. Lorsque le personnage se retrouve partiellement dans un mur, c'est cette polarité qui décide si Keen est repoussé vers la gauche ou vers la droite. On aura donc jamais de situation comparable au "zipping" des jeux NES où Megaman se met à traverser le niveau à vitesse super-sonique lorsqu'il rentre dans un mur simplement parce que les programmeurs se sont contenté de "si on est dans un bloc solide, on repousse Megaman sur le tile suivant". Evidemment, ça suppose que les murs font toujours au moins deux tiles de large.

A Zipping technique in Megaman. Propelled at 1 tile/frame or so.

Air Grab

• Dedicated "grab-mid-air" animation and gameplay state makes it obvious to the player that something happen, and how it spans in space-time.
• The animation itself is fun. J.l.n, my 2-year-old boy goes laughing when he realize he can press A/B buttons to make Bilou roll mid-air in a flash. And fun is important in a video game: that's our primary reward.
• Moving from demanding hitbox (purple one on picture below) to welcoming hitbox (light-blue one) will make it more open to learning.
• You'll still have to learn how your speed evolves with the swing if you want to reach high places or gain stupendous momentum. The potential for power-play is not lost.

Au-delà de la performance technique, l'idée est d'agrandir la marge de manoeuvre des joueurs qui veulent s'accrocher à une éponge. J'ai tenté de reporter sur l'image ci-contre la marge de manoeuvre avant (en mauve) et après (en bleu clair). En rendant le fait d'attraper l'éponge moins élitiste, j'espère -- selon les conseils de KirbyKid -- les rendre aussi plus amusantes.

See you, bloggers.

Emunit-testing

100 bytes for a level

Il m'aura fallu me promener dans le code désassemblé de Super Mario Bros 1 pour finir par y croire. Oui, sur cette cartouche de 40KB, les niveaux sont extrêmement compacts. Oui, la technique pour en faire le rendu est à la base de ce que j'avais observé avec l'éditeur pour NSMB: bien que le hardware travaille avec des "tiles", le niveau est décrit par une série de commandes (un byte de coordonnées, un byte indiquant le type de commande et éventuellement une taille). On aura ainsi des "un tuyau de 3 blocs de haut" puis "une rangée de 5 briques" et "un escalier de hauteur 3". Voire même "un trou dans le sol de largeur 4". Pas de "patterns extensibles" derrière ces codes, mais directement du code assembleur!

Un monde de différence, donc, avec le stockage brutal d'un tableau de MxN éléments que j'utilise dans LEDS (avec des niveaux de 32 ou 64KB. Plus gros que l'entièreté du jeu SMB1, donc), mais qui me permet en contre-partie une souplesse totale pour que les livres ne soient pas tous exactement les même. Allez, apparemment, une simple compression .zip pourrait réduire les niveaux à une taille d'environ 8KB.

Nathan Am Error

Costumes, folks.

Je vais appeler "costume" un ensemble alternatif d'animations pour un personnage qui ne change pas fondamentalement le comportement du personnage. Ce sera le cas par exemple de Mario quand il grandit. Bien sûr, mario-grand est capable de faire des choses que petit-mario ne sait pas faire, mais les animations modifiées vont bien au-delà des nouveaux mouvements. Devenir Mario-tanooki, c'est enfiler un costume. Devenir Mario-feu ou Mario-Marteaux aussi. Devenir Mario-Grenouille (SMB3) change fondamentalement l'ensemble des mouvements du personnage, la physique des déplacements et ne peut clairement pas être assimilé à un costume comme défini plus haut.

La question qui se pose pour le développement de Bilou est de choisir le bon moyen de réaliser ce changement d'apparence. Vu la complexité de la machine d'état, plus franchement question de doubler l'entièreté des états pour tenir compte de la disponibilité ou non d'un power-up.

Autre alternative possible, on se la joue Sonic et son espèce de bouclier transparent. Ici, le sprite de base et toutes ses animations restent inchangées: il suffit de faire suivre Sonic par un sprite supplémentaire suffisamment creux pour qu'on voie encore le personnage par-dessous. Jouable pour Bilou aussi, j'imagine.

Je choisis un système moins rétro mais mieux adapté à mon moteur de jeu: j'introduis des sections conditionnelles dans les animations elles-même. L'idée est d'éviter de devoir modifier les infos liés à l'état -- il continue à ne connaître qu'une seule animation -- mais de profiter du fait que j'ai déjà des instructions type RISC pour les animations (déplacer tel OAM, changer l'image utilisée par tel autre, etc.). Du coup, il est assez facile d'ajouter une "instruction d'animation" qui est en réalité un saut conditionnel dans la séquence, sur base d'un des compteurs de bonus ou d'une des variables internes du personnage. Reste à construire la séquence correctement. Ça, ce sera le rôle du lecteur de scripts. Les animations elles -- et leur éditeur --

Enfin ... le ROM mapping de SMB3 est peut-être un peu plus compliqué que ça. On voit sur la vidéo de Bisqwit qu'une seule "page" de 256x16 pixels est utilisée à la fois pour Mario, or il y en a 4 différentes par "costume" de Mario. Selon l'action en cours (marcher: +0, courir et tenir une carapace +2, voler +3), la page choisie est différente.

Its all sketched in the book!

early bugs to be caught.

N'allez pas vous imaginer que j'utilise une autre excuse-de-BMX pour ne pas fignoler School Rush! J'attendais juste un moment un peu plus calme où je ne serais pas occupé à faire des trous dans les murs. C'est tout. Et nous y voilà justement, avec un sympathique changement d'illustrations pour guider le joueur dans son aventure et le renseigner rapidement sur les mouvements possibles.

---

(2016-05-05) [coding][PUNCH][FLOAT][milestone][rush][user interface]

Augmentons la Gravité ?

Mon principal retour pour le moment concerne la prise en main, que je trouve assez raide. De plus, le fait que le jeu soit assez mou rend le tout assez hardcore, même en facile ... Côté contrôles vous devriez avoir un air control progressif (de moins souple à beaucoup plus souple), et ceci marié à une gravité plus forte rendra la prise en main plus réactive et agréable. Par contre pour retrouver la même hauteur de saut il faudra augmenter la valeur de l'impulsion.

Mais changer la gravité, c'est changer beaucoup de chose. En plus d'ajuster la puissance de l'impulsion, je dois aussi ajuster la vitesse de déplacement de Bilou puisque le temps qu'il passe en l'air, lui a été réduit. Sans celà, il faudrait revoir tous les obstacles du jeu.

Les autres pentes

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.)

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°

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)"

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.)

power-button bug

MMU9 write32 to undefined register 04001058h

cando grow?

Tout ça m'aura demandé pas mal de gribouille pour m'assurer que je comprends bien tous les cas de figure et éviter de devoir mettre un grand nombre de tests excessifs pour traiter plusieurs micro-cas (parce que certaines valeurs sont nulles dans certains cas). Peut-être même que je n'ai plus besoin, désormais, du système qui transmet des consignes d'alignement (avec le centre, le bord supérieur ou inférieur) ... mais ça, ça demande à être prouvé, et on verra plus tard.

Refactoring de dingue!

J'hallucine. J'ai pris une de mes plus vieille classes -- InfiniMap, responsable à la fois du scrolling et des collisions sprites/map. J'ai renommé ça en "CommonMap", appliqué les changements partout sauf aux sites de construction. J'ai ensuite déplacé le code utile dans un nouvel InfiniMap, déclaré l'une ou l'autre méthode comme purement virtuelle dans CommonMap ... et recompilé.

whipseey

You have a lot of "one block wide" or "character width wide" platforms. I find this irritating. They put a lot of stress on the mechanics and they also slow down the gameplay a lot. Open the platform spaces up some more.

1-ups... At last.

Retro-game mechanics explain: golden!

Which tile is activated during sprite/tile collision is determined by a point that is a mix (blue) between the the sprite's position (green) and its clipping box (red). If that point is not within the tile that was activated [...] there will be block duplication.

In order to reduce the number of distinct objects, some power-up blocks have different contents depending on their X coordinate on screen.

School Zone: aftermaths

Voici 5 ans, je vous faisais un jeu-anniversaire avec Bilou dans la zone de l'école. Quelques semaines plus tard, en septembre, mes p'tits n'veux me faisaient me rendre compte qu'il me fallait quelque-chose d'autre comme niveau pour introduire les mécaniques du jeu. Ce niveau non-tutoriel est depuis devenu le premier niveau de School Rush.

Download SchoolRush - JLN build.

Aujourd'hui, le développement de School Rush prend fin. Ce fut long, parfois fastidieux, mais je voulais l'amener jusqu'au bout. Comme dans tout jeu, il y a des choses qui ont été abandonnées en cours de route. Soit qu'elles ne convenaient pas, soit qu'elles m'écartaient du but premier du jeu... soit qu'elles promettaient de devenir un gouffre de développement rendant irréaliste toute sortie tant que je serais en solo sur le développement. Que ce jeu soit mon cadeau à tous ceux qui ont écrit du code free software que j'utilise tous les jours, les musiques que j'écoute en codant, les vidéos sympa qui m'ont donné envie de continuer. Merci à tous pour votre travail.

Tile Engine Revision

Sandopolis Zone and Mega-tiles.

Pas dans Sonic. Selon qu'on va plus ou moins vite, on passe ou non. Selon qu'on trouve le bon bumper ou non, on va assez haut. Et quand on n'est pas assez haut, il y a de toutes façons une route inférieure à suivre. 

Level Editor vs new engine

Mes cogitations pour rénover la gestion des maps dans mon moteur DS commence à porter ses fruits, au point que je peux commencer à réfléchir à l'impact que ça aura sur l'éditeur de niveaux. ça me tient à coeur parce qu'avec le système actuel, je ne vois de bonne solution pour réaliser les cours d'eau souterrains que mon frère avait mis dans les niveaux historiques de la Grande Aventure.

a + b = idea

+

+

Il y avait par contre un truc qui ne collait pas avec le thème de la pyramide: les zones qui forcent Bilou à avancer dans une direction précise. C'est le cas avec la rivière que j'aimerais introduire dans la version revisitée du niveau 1-1 de Bilou, à la placedu tapis roulant que mon frère avait dessiné en guise de passage à sens unique. Parce que cette rivière justifie la révision du système de "propriétés des blocs", en cogitation depuis le début de l'année.

FlatWorld : public iWorld

• ni --load-type=1 ne semble marcher
• ni un build plus ancien
• ni --cflash-path=SchoolTest (et recherche dans les fichiers)

FlatWorld.artmap

Rush to Flatworld

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 ;)

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

DoSlopes

Higher Order Blog ...

Un tout bon blog, qui continue à nous proposer des conseils pour implémenter un jeu de plate-forme 2D depuis facilement 2007, époque où j'ai dû le rencontrer pour la première fois. Mais en repassant dessus il y a quelques mois (magie Twitter), je me rends compte qu'il y a encore un bon nombre de fonctionnalités discutées que je n'ai pas encore implémentées dans mon moteur à moi (échelles, plate-formes dont on peut redescendre), et d'autres qui sont en cours de révision (pentes, plate-formes uni-directionnelles). Je repasserai dessus dans les jours à venir (j'espère)

Mais une particularité de l'article de Rodrigo Monteiro, c'est qu'il ne se limite pas aux jeux basés sur des tiles: il discute aussi le cas des niveaux modélisés par des vecteurs (Braid), à positionnement forcé sur des tiles (Prince of Persia, Flashback) et basés directement sur un bitmap (Worms). Et là, je trouve qu'il a peut-être été un peu léger en oubliant de mentionner Lemmings. Bon, d'accord, l'article est bien plus ancien que le talk de Mike Dailly présentant le fonctionnement (et l'éditeur de niveau :P) de Lemmings 1 et 2. Bon, on est d'accord: ni Lemmings ni Worms ne sont à proprement parler des jeux de plate-formes, mais ils restent en vue latérale avec de la gravité, et à voir la physique du personnage dans Fury of the Furries, je dirais qu'on pourrait bien en avoir un troisième.

A noter que traiter la map comme un gros bitmap n'implique pas forcément de stocker la map comme un gros bitmap. En fait, pour la majorité des machines d'avant le CD-ROM, ç'aurait été tout simplement impensable même avec des niveaux de taille modeste comme ceux de Lemmings (5 écrans). Pour faire tenir tout ça sur une diskette, les gens de DMA design ont construit leur niveaux sur base 1) d'une palette de 'brosses' (des bitmaps de taille quelconque provenant de Deluxe Paint) et une série de commande 'ajoute la brosse A aux coordonnées (X, Y)'. L'éditeur permettant d'ailleur de garder une idée du nombre de 'coups de pinceau' utilisés jusqu'ici dans le niveau.

Bon, vous l'aurez compris, cette technique bitmap pour les données d'un niveau marche surtout bien pour les jeux où l'environnement est complètement destructible (chose qui devenait moins vrai avec Lemmings 2, prévu pour consoles 16-bit) et à un style graphique plus proche d'un Rayman que d'un Mario. D'une façon assez amusante (mais foireuse), c'est aussi ce qui était utilisé pour la version BASIC de Bilou's Adventures ;-)

3 rooms milestone.

On dirait bien que mes éditeurs sont maintenant prêts pour le travail sur Bilou's Dreamland. Support des nouveaux types de collisions et de pentes, support du choix de palette sur les deux plans. Et les spritesheets/tilesheets ont été nettoyées et prêtes à l'emploi aussi.

Il me faut donc un prochain objectif, et ce sera les trois portes salles. Une pour chaque environnement, pas trop grande, mais assez pour qu'on puisse y placer les différents éléments de gameplay critiques pour le jeu comme les cascades, l'eau qui change de niveau, le sable qui glisse, les portes, les plate-forme crocos, les branches qui plient, etc.

(Eh, CJ, ça fait penser à tes niveaux-téléporteurs du jeu d'origine, ça, non?)

3 Rooms - Release Early

Download: Dreams.nds updated Dreams.nds for new year

Voici donc (enfin ?) quelque-chose de téléchargeable avec les environnements que j'ai l'intention de faire évoluer pour y amener toutes les nouveautés de gameplay de Bilou's Dreamland. Alors, soyez avertis quand-même: c'est vraiment une version 0.0.0.1 là. Pas même une ébauche, tout juste un canevas. Y'a des retouches à faire par-tout. Y'en a tellement que je n'aurais même pas le temps d'en dresser la liste avant d'aller me coucher. Mais qui sait, ça vous amusera peut-être.

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.

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 ?

tapis roulant!

C'est que pendant qu'on avance, on appelle régulièrement la fonction do_slopes, voyez-vous. Et même si le sol annonce "je te pousse de deux pixels sur la gauche" alors qu'on est sur une pente, on finira bien 2 pixel à gauche et 1 pixel plus bas si nécessaire. Mais rien de ce genre dans l'état "immobile sur le sol". Et notre fonction do_slopes est prévue pour aller directement corriger la vitesse et les déplacement retardés du personnage, or l'idée du "sol qui pousse", c'est justement de manipuler la position dans un premier temps et de laisser le code qui traite la vitesse tranquille. Sans ça, sur un tapis roulant trop rapide, vous verrez Bilou se retourner pour marcher tout seul vers la gauche plutôt que de le voir s'échiner à avancer vers la droite tout en reculant malgré tout vers la gauche. Pas terrible.

Comme toujours avec les pentes, les problèmes commencent quand le sol n'est plus dans le prolongement horizontal de celui utilisé une frame plus tôt. On se retrouve dans ce cas-là soit avec Bilou qui s'arrête au milieu de la pente, soit continuant à se faire pousser, mais à l'horizontale. 

Bref, inspector widget, ddd, j'ai pu sortir toute la panoplie. Presque (pas les unit-tests, cette fois). Mais l'éditeur de niveau m'aura bien cassé le rythme.

(wow. Le soir est tombé, j'ai encore une machine à faire tourner et je n'aurai pas fait plus de homebrew de cet aprèm' libre que de vous raconter tout ça :-P)

Et un Bangbash qui marche ! ...

edit: avec un peu plus de travail sur les animations, la position des images par rapport à la "boîte-position" du personnage, ça donne enfin (4 janvier) ce que voulais que ça donne. Bon, évidemment, ça ne satisfait pas J.L.N qui demande "il attaque déjà ? " et "on peut lui envoyer des taille-crayons ?" ... pas encore, mon p'tit loup ... pas encore ...

Hang on!

I started with a summary of how Bilou can hang below spongebops in School Rush ... something we don't see a lot in the blog, mostly because Bilou is supposed to *ride* the sponges, not hang under them. Hanging was added as an "else" branch of another "else" branch:

when you hit the "HANDS" button mid-air, Bilou does a roll move trying to grab what's nearby. that is AIRGRAB state. The original idea was to test what was *below* him and either pick-up a dumblador or ride a spongebop... but the move shows the hand grabbing in front and rear directions as well ... so it would feel natural that Bilou could grab a sponge even if he's on the same horizontal line, like in the sketch on the left. Yet, snapping Bilou on top of the sponge from this location felt glitchy.

Bon, j'ai un p'tit Bilou suspendu sur une page de mon cahier-agenda depuis le début 2024 ... j'en ai un autre sur la bannière du blog ... je crois que l'appel du pied est assez clair: il serait temps de prototyper un peu ça, d'autant que cette fois ci, ce ne sont pas les coins de niveau où s'accrocher qui manquent dans le livre-secret-du-level-design.

Et pour "commencer simple", l'idée était de faire subir à Bilou le comportement des éponges. tout en réutilisant un des états codés pour l'interaction avec les éponges: rester suspendu (la feinte). Chose qui m'a tout de même demandé de me replonger dans pas mal de gobscript, parce qu'à la base, il est prévu que Bilou s'accroche *par-dessus* les éponges, et pas qu'il pende en-dessous. Le côté "pendu" n'a été rajouté que dans les derniers 20% du projet, entre deux séances de playtesting parce "bin, oui, c'est vrai au fait: pourquoi Bilou ne pourrait-il pas rester suspendu s'il était trop bas pour escalader l'éponge au moment ou la joueuse a appuyé sur (B) ?"

So instead, Bilou will enter AIRHOP move, getting an automatic double jump and automatically tracking the sponge's position. That feels fairly naturally when playing, that gives you a sort of "fair second chance" but it might fail anyway: you may fall below sponge's position again without having reached the "riding spot", with no hope of catching up. and *that* is the time when we finally switch to HANGING. 

There will be other objects to hang to in the game, especially bookmarks, vines, and the like. Some of them could be entities like spongebop (maybe moving a bit less), but sometimes it might also be nice to have tiles you can hook to. I have code to make some tiles react to collisions with the player, but that was not enough: the hitboxes used to detect spongebop explicitly search for baddies. And because I'm testing 3 areas over the course of the animation, I'm out of options to also test for friendly areas (which has been the case for all pick-ups so far ^^"). But hitting a tile can trigger an animation, and it can spawn an entity with proper hitboxes so that Bilou could hook to *that*. You couldn't really hook to a tile, anyway, because the BlockArea created during the collision test is immediately recycled, so you could not attach to it. 

Mon idée était ensuite d'utiliser un type de bloc spécial pour servir de point d'accroche, et d'aller "poker" quelques blocs de ce genre à des endroits bien sentis de la map "green" de la démo. ça non plus, ça n'a pas fonctionné comme j'espérais. Entre autres parce que quand Bilou cherche à s'accrocher à quelque-chose pendant sa pirouette-en-l'air, il cherche parmi la liste "EVIL" ... et les blocs interactifs, eux se présente automatiquement comme des "HERO".

Bon, ce n'est pas bien grave: puisque je voulais que Bilou s'attache au point d'ancrage, il fallait de toutes façons que j'introduise un GOB (game object) généré à partir du bloc spécial, un peu comme les scintillements qui suivent Bilou quand on ramasse un smiley bleu. Ce gob pourra être dans la liste que l'on veut. Pour éviter qu'on ne génère des quantités ridicules de gob-points-d'ancrage, on va (enfin) utiliser une animation de la map elle-même pour désactiver puis réactiver les propriétés du bloc pendant que le gob est présent. Exactement le comportement des blocs-question de SuperMario quand on les coup-de-boulise.

(It turned out meanwhile that using sprite 'ffff' did not work as intended, so I ended up adding a bbox statement to that animation -- effectively making it a special 8x8 tile rather than a 16x16 special block -- and fixed the code that plays mapanim so that "props" instruction is executed immediately rather than cached until the next "spr0" instruction)

anim9 spr:2 {
   spr0 7      # visuals for the "tile replacement",
   delay 5     # here just a Bilou hand ...
   done
}

state63 :anim9 {           # behaviour for that hand :
   using freemove          # just stay there, 
   area 0 (0,0)-(8,8) 1010 # accept GRAB hits.
}

state62 :anim9 {   # should have been the persistent state when Bilou hooked...
   using freemove
}

state63->state62 on found 0 [wc $1010 ?] (t) # detecting the actual hook-up hit
state63->nil on done                         # and disappear otherwise

using shgob(state63 is e:=1:6) as 6          # a special action to spawn the hooked hand
                                             # oh ... and it's an evil hooked hand.
block 06 {
    is gndhook "ff3c7cfebe2a2a00"  # the special tile 
    area (0,0)-(7,7) 1010          # will also detect GRAB hits
    on hit [t] (x6) :anim6         # and the 'x6' will invoke shgob registered 'as 6'
    props fc0
 }

That should have done it. I could see the hand showing up, and getting away, but I couldn't ever hook to it. I couldn't get an evidence of why it failed, but I believe it is rooted to the fact that bilou's own bbox must overlap the tile in order to trigger the "on hit" transition. but since all the hitboxes with the GRAB flag tend to be off-center, the second collision (with state63 entity) doesn't occur because there's no overlap.

Alors oui, je vous balance le script directement dans le browser. Parce que ça ne fonctionne pas. Enfin, après avoir corrigé la gestion de l'animation pour ne pas dépendre des changements d'affichage (qui expliquent le bout de terre manquant dans le screenshot là-haut), ajouté une "bbox" à l'animation (pour que le code sache qu'il ne doit manipuler que 8x8 et pas 16x16), je finis par avoir un objet qui est créé tandis que le bloc devient inactif puis se réactive ... le hic, c'est que il faut pour ça que le "corps" de Bilou soit en contact avec le bloc interactif alors que ce sont ses *mains* qui vont essayer de l'attraper. Et la zone à attraper est réduite à 8x8, de toutes façons mal positionnée... bref, je n'y arrive que 1 fois sur 5-6, donc le joueur n'y arrivera pas.

Il vaut bien mieux que je me décide à dessiner un graphisme dédié (une racine ?) et que je fasse juste un GOB dédié... il y aura des import/exports mercurial à faire ... 

At some point I thought "hmm. I'll just have the little tile be a 8x8 hitbox in the middle of a 24x24 special box, that will do the trick", but it wouldn't work either: that 24x24 region around the corner of a pillar (for instance) would have "jump-through ground" on one tile, and "air" everywhere else... how could a single "props" instruction fix that ? okay, I could introduce "props(-1,0) fc4" to change one specific tile of the block but that sounds like the coding equivalent of "just stab me now" ... 

So, likely, I should forget about that "hook to tile" thing, accept that there's very little hookspots in the Dreamland levels anyway and kickstart my NDS to draw some root sprite in green.spr ... 

stopping waters

(full page scan: https://mastodon.social/@PypeBros/114759901752072759) 

Une possibilité serait de proposer ça par l'intermédiaire d'un TileGun.

L'autre option serait d'intégrer directement une fonction "déplacement" à l'intérieur des MapAnims 

Mario in Godot

Refaire Super Mario World dans le game-maker "Godot" ... j'ai envie de dire à la fois "tout ça" et "rien que ça". Pourtant, l'idée de Wye n'est ni de proposer un Mario World Studio ni son Mario World 3. L'idée, c'est de comprendre le fonctionnement du jeu d'origine en le reconstruisant dans un nouvel outil tout en apprenant l'outil lui-même. Et ça, ça me parle. C'est le genre de bouquin que je dévorerais mais ici, ce sont des vidéos youtube.

"In Super Mario World, Mario was considered fully underwater if both his head and body interaction points are touching water tiles. [...]

"When Mario body is in the water but not his head, that means he is near the surface."

Du point de vue des collisions avec le niveau, Mario n'est pas une boîte. Il est ... une sorte de constellation de points qui ont chacun leur préférence sur le type de terrain 8 en tout, mais dont certains ne seront évalués que dans certaines conditions. Pour déterminer s'il faut nager ou non, ce sont par exemple ce sont les tests du milieu et de la tête qui entrent en ligne de compte. Et pour déterminer si on peut sauter hors de l'eau ? Bin il faut que le corps de Mario soit dans l'eau mais sa tête hors de l'eau. On évite en fait les complications du type "la surface est à la fois de l'air et de l'eau" dans lesquelles je me suis embarqué.

Une pente qui tombe à l'eau

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

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. 

20 ans de Nintendo DS

Comme j'avais envie de revenir un peu sur tout ça, j'ai fait un petit récapitulatif de la première année de développement et blogging sur bsky ... et d'une façon assez surprenante, ça a explosé les réactions.

Et ils n'ont pas encore vu cette ligne du temps tortueuse qui reprend les milestones, les releases et les interventions et commentaires de "guest stars"