CompoundGob::RefreshPage

I guess you can hardly tell what's going on on the picture below, and I can't blame you for that. It's supposed to be a stomped scorpeye shell, but since I've added crawling animation for the scorpeye, we see that glitchy mess of sprite parts instead.

Ah oui, je m'étais fait un joli scorpion qui marche, mais si vous parvenez à l'assommer, tout à coup, il ne ressemble plus qu'à un tas de pixels complètement glitché. Comme j'envisage de passer refaire un coucou au "gaming club" de vendredi, ça ne serait pas mal de corriger un peu ça.

La cause du problème, je la connais: l'animation de la marche est construite avec 5 sprites hardware: un "large" pour la carapace du scorpeye et un carré pour chaque "patte". En revanche, les animations "carapace seule" et "carapace qui tourne parce qu'on l'a lancée" sont toujours inchangées et n'utilisent que 3 sprites hardware. Et le couac, c'est qu'en plus, le sprite large n'est pas sur le même d'une animation à l'autre. Il était donc temps que je me gratte un peu la tête et que je retrouve les fonctions-clé pour gérer ça, en particulier loadAnim() dans CompoundGob et setupOAM() qui peut redéfinir les tailles et aspects des sprites.

What happens is that you have dedicated bits in the hardware sprite entries to indicate whether you want a square, tall or wide sprite and of what size. So far, in my engine, those properties are defined once when you allocate hardware sprites for an object and then preserved as we just update coordinates, VRAM location and optionally palette slot of each sprite as we animate them. But by mixing the new crawl and the old spinning animations, I'm breaking an old habit of sharing the same structure for all animations of a given game object. So I need to extend the game engine with the following function:

  void refreshPages(const GobAnim *ani) {
    unsigned nlimbs = ani->getnlimbs();
    unsigned i;
    pages = ani->getpages();
    for (i = 0; i < nlimbs; i++) {
      if (oam[i]==NO_OAM) continue;
      pages[i]->setupOAM(sprites + oam[i], 0 /*?*/);
    }
    for (; i < nboam; i++) {
      if (oam[i]==NO_OAM) continue;
      sprites[oam[i]].attribute[0] = ATTR0_DISABLED;
    }
    nboam = nlimbs;
  } 

Je dois dire qu'au départ, je m'attendais à plus compliqué, mais la petite fonction ci-dessus et une brave ligne de plus, les animations se sont réparées presque d'elles-même. à utiliser avec prudence tout de même: le système ne se déclenche que si les deux animations ont un nombre différent de sprites.

To be honest, I was expecting it to be harder to code. It was a bit tedious to locate where to act in the code (state transition? animation loading ?) and I spent a significant part of a holiday afternoon in ddd setting conditional breakpoints to figure it out. Then I got puzzled by the update/setup/allocate functions manipulating hardware sprites through the "SpritePage" class: the one that is used at every frame to update what we see on screen keeps aspect ratio and size of the sprite unchanged... but after all, it was just a matter of a small function called when we detect that the current number of OAMs (aka hardware sprites) is different from the number of limbs the animation uses. Pretty and straightforward.

GobAnim vs. GobAnim

Something went 'oops' when trying to upgrade the 'bouncing feet' behaviour for dumblador's behaviour. I edited new animations for the feet in AnimEDS (mostly to take advantage of the bounding box edition feature), but when I injected that into the ongoing test level, I simply didn't see any feet anymore.

Armé de mes nouvelles petites anim' pour les pieds baladeurs de Dumblador (et des zones de collisions associées), je venais tout juste de faire les ajustements à blador.cmd, mais en lançant le jeu dans l'émulateur, j'ai juste eu droit à une avalanche de "oops? endless looping" sur la console de débugging. Un p'tit breakpoint bien senti sur iprintf (oui, carrément) m'a permis de voir que je faisais fausse route: ce sont des GOBs "simples" (comme dans AppleAssault) qui sont créés pour les pieds et non pas des CompoundGobs comme Bilou et Dumbladors. Du coup, l'interprétation des données d'animation est erronnée. Je vais devoir passer plus de temps que prévu sur ce point-là.

I had to rely on some DDD to figure out that gob shooting currently systematically create a SimpleGob instance, but that attaching a AnimEDS animation to a SimpleGob just results in non-sense (and likely no display). I thus have to merge a bit more those two co-existing animation parsing (binary and textual) and rendering (compound or simple). The easy way out would be to claim "oh, I can also shoot compound gobs", but the reality is that 90% of shots (weapons, dustballs, feet) will be simple gobs. Only monster generators and Bosses may need something else.

• [done] GobAnim::parse() should use AnimUser encoding, rather than AnimCommand {} structs. Keep the API (GobScript syntax) unchanged.
• [done] SimpleGob::play() should align to that new encoding.
• [done] enable BBOX, origin and pageno's colours bits from anims.
• [ok] ensure a 1-limb AnimEDS encoding can be used to create SimpleGobs in GameScript::GobCommand() 
• [done] GameScript::setGobState() no longer blindly cast to SimpleGob to call setstate()
• [done] GobGun::shoot() no longer blindly generates SimpleGob()s

Landing bug, from the state machine

Since the introduction of 1st September release, I observed curious behaviours with Bilou landing. First, it could occur that Bilou looks "dislocated" just when landing, which would last for a few frames before he starts walking. That can be explained by the fact the OAMs the hardware uses have received new graphics, but still with the ordering (and layout) of the last frame. It "sticks" that way because the "walking" animation starts with a 'MOVE' command, which actually instructs the game engine to wait for the GOB to have accumulated sufficient amount of inertia to be able to "step" by 3 pixels to the right. This has been fixed just yesterday.

La dernière release a un bug bizarre: quand Bilou atterrit, on dirait qu'il se retrouvé désartibulé un moment (cf. capture), puis tout revient dans l'ordre au moment où il commence à marcher. la raison, c'est qu'au moment de changer d'animation, les sprites hardware ont déjà reçu leurs nouvelles images, mais leur coordonnées (et leur ordre d'affichage) reste inchangé. Si ça ne se voit pas la plupart du temps, c'est que la prochaine image n'est généralement pas bien loin, sauf dans le cas de l'animation de la marche qui commence par une commande MOVE indiquant au moteur d'attendre que le personnage ait accumulé assez de "crédit de déplacement" pour pouvoir faire le premier 'pas' (ici de 3 pixels).

But there's another, harder to catch, subtle bug that hides in the "state machine" that controls Bilou, more precisely between "fall", "idle" and "walk" states. In those rare cases, Bilou lands in "walking" state although you're no longer pressing the DPAD in any direction. He keeps walking forward at a very slow rate (~1px/second), unless some block prevents him from doing so or you press some button on your DS.

There sure are curious things in that state machine, such as clearing the DPAD memory before entering idle state so that you force dpadController to generate an event for "getting pressed". I have the feeling that none of this remains useful now that I have "impact speed" variables that can offer a direct fall->walk transition.

It looks like the bug was in the momentum controller code, however: it would fail to decrease any speed below 8/256th of pixel per frame, and would generate no event for "reaching speed zero".

Un autre effet bizarre lié à un bug dans la machine d'états de Bilou se déclenche quand l'atterrissage se fait alors qu'on vient de relâcher le DPAD. Bilou donne alors l'impression d'avancer trèèèèès leeennnteeeemmeeeennt avant de s'arrêter complètement. Il faudra sans doute que j'aille corriger dpadController pour qu'il perde la mémoire des dernière directions avant d'entrer dans l'état 'attente'. Je ne devrais plus en avoir besoin maintenant que je peux capturer la 'vitesse d'impact' quand on atterrit. Ah, et un p'tit bug dans le contrôleur d'inertie qui oubliait de me signaler l'arrivée à une vitesse nulle, restant bloqué à 8/256e de pixel par frame.

PS: the '90,000 views' bar has been hit this morning, according to Google, but I strongly doubt that it's true. Google is terribly sensitive to all those page-ranking cheaters that pretend they're referencing you just to attract your attention to their web domain.

throwing bladors

I can be glad I'm done with the "bottom things" of my summer todo list. Now the winter is starting, and what is left is what is more linked to the game logic and the revised collision engine which is waiting to prove its superior capabilities with some dumblador stunning and throwing.
De temps en temps, ça fait du bien de retourner à une "liste de choses à faire" pour s'assurer que le projet avance effectivment. Bon, des "todo lists", vous devez tout doucement commencer à en avoir une indigestion, mais je parle ici de quelque-chose qui s'approche plus d'un "planning" que des micros-tâches à effectuer sur un temps de midi. Mon dernier planning datait de mi-juin ... voyons où on en est... tous les éléments "du bas" ont été satisfaits, à grand renfort de mises à jour de SEDS et AnimEDS. Je vais donc pouvoir cet hiver attaquer sérieusement les nouveaux types d'interactions entre personnages: assomer, attraper, balancer.

On dirait que les mois à venir vont être durs, chez les Dumbladors.

At those "milestones", I can close many former todo lists, by collecting in a new one the items that remains pending but that weren't really linked to the then-going activities. And yes, this is truly a milestone, since I now have fully operational CompoundGobs, including the definition of palettes for individual limbs (altering the palette while playing the animation will be for a next milestone :P)

• [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.

Back to School!

Here's at last the demonstration of game engine improvement and new graphics for the School Zone, on a temporary soundtrack by Cyborg Jeff.
There's no "gameplay" or "mission" yet: you can navigate through a single map, bop sponges and dumbladors and track bugs (there sure are some). The ink doesn't hurt yet, but the baddies do. How many roll-jump can you chain ?

New features:

• better animations with AnimEDS
• transition animation (in jumps, mostly)
• improved parallax scrolling

Known bugs:

• Bilou may pause at the end of a downward slope. Just release the DPAD and move forward again.
• Bilou may get stuck in corners. I need to figure how and why.
• Dumbladors can be trapped mid air.
• If the bottom screen turns pink, you've entered debug mode -- known as InspectorWidget. Press 'L' trigger for frame-by-frame game or hold 'L' and press 'START' again to resume "normal" gaming.
• if all you can see is "efs:/strtrk.xm not found" on black background, you're using an incompatible linker or emulator. If you're using desmume, you need to add "--gbaslot-rom=self" on the command line.

Download SchoolTest.nds and have fun.

Oh, this is the 700th post, by the way ^_^
vu sur dev-fr.org, et - chose amusante - c'est aussi mon 700eme post sur dev-fr (et ça, je jure que c'est pas fait exprès :P)

edit: just understood and fixed the slope issues.

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.

OAM priority issues

I'm about to introduce significant complexity in the game engine for the purpose of displaying some compound animations properly. I've took the time to think about it (while drilling staircase for a kid-safety-barrier, if you ask :P) and figured out how to sort all the needed details. I just missed one point: this is absolutely not the only place where I need OAM depth-sorting.

Remember of Apple Assault's frenzy, and how you could end up not seeing that appleman that runs towards you because it's actually sneaking behind a row of stunned applemen ? That's never been fixed to date because I had no way to instruct the game engine that "those stunned applemen should be moved to the background".

Then I remembered of that "talk" by Rafael Baptista about resource management on the GBA. Before he entered the core meat of his talk, he suggested that copying OAM entries (you can think of them as sprite descriptors) could be the right time to follow a Z-order linked list and keep the "hardware" OAM entries and their "shadow" counterpart. Nice move, although I still wonder how he manages the scaling/rotation matrices along the way...

I used to have a large, one-chunk DMA transfer of all the sprites & rotation information. I would have to split that in 3-u16 slices. That sounds like I'll have to pay sverx's report on memory copies performance benchmark a second - and more careful - read... and possibly opt for an intermediate - sorted, but in-cache - version out of the vblank period and then DMA that into VRAM when the vblank is hit.

A final consideration: there is little chance that I need a fine-grained Z-sorting. low/normal/high priority should be enough in 99% of the cases, and the remaining case could likely be "sorted" out at GOB instanciation by internally sorting the OAMs the GOB received.

edit: I asked myself the right question: 'is that move out of DMA sync'ing gonna cost me framerate or not ?'. From that point on, I hacked a modified version of my game engine, that uses CPU-driven copy with merging of OAM and rotations into one single table (as the DS hardware expects) and started Apple Assault with aggressivity setting turned at max (so many apples that you'll experience "ghost" berry bats and shots). Good news: it still works flawlessly (that is, I can't observe any slowdown). Next: the depth-re-ordering...

edit++: just applied silly reverse-priority and order-enforcement-at-sync() in an AppleAssault check: it proves the concept: now Bilou can sneak behind stunned applemen. Useless, but you can't deny it's no longer the default z-order that is applied.

edit+++: checked that a (Simple)Gob set on zlist[0] appears in front of (Compound)Gobs set on zlist[1]... now I've got to figure out how to use that best to implement the pullmask for my "roll jump" animation ...

A new Bilou is coming soon ...

here you go: new animations for Bilou under test. I still have lot of work to do before it gets really convincing, but it's clearly an animation improvement compared to the former, frame-by-frame animation, don't you think ?

• [done]that makes too much frame to toy with manual mirroring of the animations
• [done] all the animations are looping, which makes jumping look funny and the recovery infinitely long.
• [done] I have animations that guide movements, but not yet movements that regulate the speed of animations.
• [done]in "zoomed in mode", limb selection on the frame editor widget go completely crazy.
• [found] Bilou shouldn't get stuck on the ground like that
• [found] Why is nobody climbing up that ruler ?
• Dumblador should not got stuck on structure' edges
  
• [transanim] any statJ6->statJ6 transition reset the jump-take-off animation mid-air. I should have a way to tune that.
• [done] make sure my foot stops hurting

Eh bien, voici donc ces nouvelles animations à l'oeuvre -- c'est fou tout ce qu'on peut animer en une petite journée d'immobilisation quand la batterie de la DS est bien chargée ^^. C'est encore loin d'être parfait -- sinon, j'aurais fait une "release SchoolTest", mais ça prend forme... et ça me rallonge ma liste de choses à corriger ^^"

Ah, oui. J'en ai profité pour corriger cette histoire d'encre animée. Chouettos, mais vu que Bilou ne grimpe plus le long de la latte, on ne sait plus aller voir ce que ça donne ^^'

Tout ou rien

Ça être un rien plus long que prévu: il n'est pas possible de mélanger animation normale et composite pour un même GOB à l'heure actuelle: le nombre de sprites-membres et le décodeur d'animation sont fixés à l'instanciation en fonction de la première animation utilisée pour le GOB (son état initial).

Bilou's conversion to the new animation system has started. It's pretty funny and fairly fluid, although I failed to capture a decent video of it so far. It's still very buggy, I'm afraid.

C'est donc une grande partie du fichier bilou.cmd qu'il me faut mettre à jour, alors que AnimEDS n'est pas (encore) capable de "retourner" les animations lui-même.

Celà étant dit, dans l'éditeur d'animation, cette nouvelle démarche de Bilou donne franchement bien :)

Devoir de Vacances...

Bon, on est encore loin d'avoir une "school zone demo" convaincante, mais au moins, la première vague d'upgrade des outils touche à sa fin. J'aimerais avoir pour la fin de l'été une démo avec Bilou converti en animation composite (plus ou moins indispensable, vu que j'ai déjà effacé son corps pour les étapes de marche, ce qui explique le "clignotement" dans la dernière démo) et de l'encre animée qui tue (lentement si on veut).

Let me pick a chalkboard and try to map all the improvements I still have to bring to the Bilou-in-school-zone demo, so that I can identify priorities and schedule coding sessions for this summer (if we ever happen to have a summer here this year :P)

And the winner is ...

ink animation and repair Bilou walk animation

Rien que ça, ça nécessite déjà deux interventions immédiates sur SEDS et AnimEDS. Ensuite, j'aimerais pouvoir me rapprocher du look "pile de livres" proposé par Facet, mais ça, c'est plus ambitieux, et donc à garder pour une 2eme passe.

• GridWindow::save_back_tiles(), which is involved in the cursor-driven edition, already does some 32x32<->16x16 conversion. All I need to do is to move it where it really belongs -- EditorSpriteSheet : public SpriteSheet -- so that I can reuse it in FileWindow::event().
• 32x32->16x16 is now available and the ink tiles are converted.
• modifying one line in GameScript.cpp should allow to animate the ink, but there's more code cleanup waiting there, for more efficient memory management, for instance.

Dumblador turns back

Here it comes. Some final tweaks on dumblador's "walk to the right" animation last night and I now have a CompoundGob that turns back when it encounters a wall (how sweet ^_^) Dumblador avance et fait demi-tour. L'occasion de revenir sur le fonctionnement des personnages dans mon moteur de jeu. Accrochez-vous un peu: le 'gobscript' est conçu plus comme un modèle de bytecode en ASCII que comme un véritable langage de programmation, mais comme dumblador est tout simple, ça reste lisible (j'espère ^^") Please bear some GobScript since it's still a pretty simple and straightforward monster:

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 }

on commence par importer des animations depuis le jeu de sprites (il suffit de connaître leur numéro, ici n°0 pour avancer vers la gauche et n°3 pour avancer vers la droite) et on leur donne des identifiants locaux (anim1 et anim2, respectivement). Le comportement de dumblador va maintenant être construit comme une combinaison d'états réutilisant ces animations: L0 pour avancer vers la gauche et R1 pour avancer vers la droite.

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

The only thing you have to remember about your spritesheet is now the position in the animation slots where your things are. That's slots #0 (walk left) and #3 (walk right) for me. You give them animation identifiers for your monster (1 and 2, resp.) From that, you can define states walk left and walk right. Each state defines an animation being played and a behaviour. The combination of using walker and selfmove means that DumBlador will move forward at constant speed, according to what's defined in the animation, but not faster than the value defined in its internal variable v0 (x speed)

Vous pouvez penser à un "état" comme à une action que fait un personnage: s'il est dans l'état "avancer", il fait son animation "un pas en avant" et utilise un morceau de code C++ un (contrôleur) identifié via using walker qui reprend les tests "y-a-t'il du sol? dois-je suivre une pente?, etc.". Le mot-clé "selfmove" indique que c'est l'animation qui définit de combien de pixel on avance à la fois pour une meilleur synchronisation. On reste donc par exemple dans l'état "vers la gauche" tant que tout va bien. Le contrôleur génère un "fail" lorsque le personnage arrive dans un mur. À ce moment-là il va falloir choisir un nouvel état. Les commandes du types statdepuis -> statvers on fail [condition] (action) permettent de construire les transitions qui seront testées dans ce cas-là. Ici, l'action consiste simplement à écrire une valeur constante (100 ou -100) comme nouvelle vitesse horizontale (variable n° 0). "walker" is what's called a controller for the GOB. It can also report events and indicate when it failed to perform the desired movement. The two on fail statements indicate transitions from "walk left" to "walk right" and back when it's no longer possible to move forward. That could be due to a wall or the end of a platform. With this simple script, dumblador "has no way to figure out". Another part of the current behaviour is that dumblador turns back when Bilou jumps on his "head". This is achieved by the two on hit statements. It's still necessary to provide the (relative) coordinates of the hitboxes manually. Here the "hit" statement corresponds to a passive area in the state definition, which is seen in dark cyan in the Inspector widget. "000A" is the bit mask that corresponds to Bilou's stomping action or AppleAssault's attacks. I could have used "0002" to make DumBlador impervious to punch attacks and reacts only to stomps. Enfin, pour compléter le comportement décrit par chaque état, les instructions test|area n° (coin1)-(coin2) avecqui donnent les zones de collisions (rectangulaires) qui vont permettrent d'interagir avec les autres personnages. La partie un peu "magique" se situe dans le nombre hexa avecqui. Pour chaque "type" de collision, il faudra choisir un des 16 bits disponibles et faire en sorte qu'au moins deux zones de collisions (p.ex. le corps de blador et celui de Bilou) utilisent le même bit (0001) mais dans un test pour l'un et dans un area pour l'autre, pour refléter l'asymétrie frappeur-frappé du moteur de collisions. Finally, the curious (100 ~ :0) are GobExpressions. It's a minimalist encoding of "set var[0] to -100". It works as those RPN calculators, where you type "2 40 +" to compute "40 + 2". Only simple parts are used here: push the constant 100, negate it (I don't have negative constants so far ^^") and assign it to variable 0 (mnemonic: Pascal uses := for assignments). Reusing a constant here is required as the walker controller is allowed to alter the speed in the final steps towards the wall. Would you like to give it a try yourself ?

Yeah! Blading time!

Wow. I had no idea it would go so fast! Less than 24 hours after the proper alignment of dumblador on screen, I can now have it walking around in a level. Many things remain, such as making it detect edges and turn around, just like applemen and woodworms. That will be a next level. Here's the updated AnimEDS for download, although I'm pretty sure it needs more feedback hints before it becomes user-friendly.

Eh bin !? ça n'aura pas trainé. Je sentais bien que je n'étais pas loin de "dumblador qui avance", mais de là à deviner qu'en une soirée, ce serait réglé dans AnimEDS et qu'avec juste 2 heures de plus dessus ce matin (dont un peu d'ajustement de sprites), je pourrai le faire avancer aussi dans le moteur de jeu ... C'est pourtant le cas. Chouette. Je vais pouvoir commencer à ajouter la définition des zones de collisions entre sprites ... ou alors je garde ça pour un programme annexe encore un moment ?

Where You See is Where It Is

Bon, on récapète.

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

Well, it's a milestone: I can precisely place compound GOBs in a level. Neat. Now, if you don't mind, I won't translate all the tracking and focus on the impeding future: defining moves of the compound GOB in AnimEDS as well ... and then have them walking :)

A few weird things occured with this dumblador development, which should sound "normal" to any game developer: a monster that cannot be seen but hurts you nonetheless, or that can be seen at position A while it hurts and can be bop'ed on at position B ... and also a monster that "walks" without leaving position A and suddenly appears at position C when his "step" movement is done (distance between A and C being totally impossible to predict from the observation of the movement).

No need to say that in some parallel universe, dumbladors seems to have super-natural powers that make Bilou's job quite more complex. According to Bouli, that'd be because they're following elliptic curves, but on a toroïdal and discrete space...

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

devil in the details

Mouais. J'aimerais dire "#çac'estfait", mais en fait non. J'ai bien la possibilité de définir une première zone de collision dans AnimEDS, la possibilité d'aligner le bord inférieur sur la map dans LEDS et le game engine qui regarde tout ça sans broncher, je garde un désagréable goût de bicarbonate en bouche.
Il m'aura fallu plusieurs aller-retours dans LEDS pour pouvoir faire l'ajustement, les monstres se désactivant à plusieurs reprises. De plus, le minuscule dumblador affiché sur la map ne permet pas de se rendre compte si le positionnement est correct, ni de le sélectionner avec précision. Affaire à suivre.

I'd love to call it done, but let's be honest: it's not. It's merely a hack that allowed me to have *one* dumblador properly aligned after countless "there-and-back" games in the level editor. I'll have to do some polish before it could be of any real use. Much polish. "devil is in the details".

• [done] now that I can select dumbladors with their real sizes, I can't select Bilou anymore, who looks to have (0,0) dimensions -- fixed.
  
• [fix] DPAD-positioning is somehow fixed ...
  
• [workaround] but I still need to visualise the solid box of the monsters, not only their thumbnail.
• [done] monsters are rendered where they have been designed to stand.
• [done] BoxWidget becomes immediately responding to DPAD commands after the 'bx' button has been clicked.
  

Small Little Things

I've been running through a couple of fixes in the Level Editor before I could open .cmd files again ... I also injected the wizardry for guru meditation that I have for runme, which was actually easier than I remembered as there is a C++ standard way to override the "terminator" function for top-level exceptions: std::set_terminate(). (done)

At last, the monsters created with AnimEDS no longer crash the tool, and they do show up ... somehow ... It looks unfortunately like I wrote the wrong tiles in the 'TINY' sections of the .spr file >_<.

Petit retour sur le code: si le moteur de jeu peut maintenant utiliser des animations composées créées avec AnimEDS, en revanche, essayer d'ouvrir un tel niveau pour en éditer la map ou les monstres faisait tout planter. J'ai donc d'abord modifié AnimEDS lui-même pour qu'il sauve des "miniatures affichables" des animations en plus des instructions d'animations (les blocs 'TINY', un héritage des fichiers .LBM de Deluxe Paint ^_^).

Puis il a fallu s'attaquer à LEDS lui-même, pour me rendre compte qu'il plantait maintenant sur tous les niveaux, et d'une bien curieuse manière ... quelque-chose entre le Null Pointer Exception et le buffer overflow. Tout ça parce que j'avais surestimé le niveau de "tests run-time" que C++ effectue lorsqu'on utilise vector[i] >_<

Bref, tout ça est maintenant arrangé, mais l'affichage de dumblador est pour le moins corrupté ... un peu comme si j'avais capturé le contenu de la "limbs table" plutôt que les miniatures d'animations (fix). Mais je devrai regarder ça plus tard: il est temps de me remettre au travail sur ma présentation ou elle ne sera jamais prête pour la conf' à Maui ...

oh, yeah ... and dumblador's animation finally works fine in the game engine. Now, the road ahead:

• [done] L+Y to clone a frame at the end of the animation in AnimEDS -> full walk
• [wish(?)] move whole frame / animation around
  
• [done] define gob movements in AnimEDS
• [done] define gob collision boxes in AnimEDS
• [wish] limb-aligned collision boxes in game engine.
• [wish] larger TINY images (non-scaled) for small-work-area gobs.
  
• [bugfix] make the "zoomed frame editor" work
• [bugfix] still bugs in the timeline ?

and then more:

• [done] support iGobController-driven walk
• [done] also duplicate monsters set-up expression when duplicating GOBs in LEDS;
• [done] make sure loading an animation in AnimEDS preserves the movement hints;
• [done] support for full-movement animation (i.e. move on all frame, including the loop).
  
• [wish] think about managing the bbox on a large set of animations for a single character;
• [wish] allow GameScript to ignore '../' headers in .cmd files so that efs-based and fat-based readers can both use the same input script, without requiring conversions.

Ravioli code

Open a new terminal, move the ravioli into a heater directory, ./configure --enable-provence-herb and make cook.

To install the tasty-theme, you'll need to interrupt the cooking process and pour crème-fraiche.txt as tolerated by your user quota. Then just resume cooking.

You might prefer to make install in /opt/bowl, as /usr/bin/plates tend to be harder to hold while coding/debugging/cursing on your program.

So now that /dev/stomach is no longer sending seek errors, you can focus e.g. on adding support for compoundGobs in the Level Editor, since it looks like generating 'TINY' thumbnails in AnimEDS worked fine. Beware the potential fork bombs when running the foodware, though.

Compound monsters ... todo.

Some more digging and I've been able to pin-point the problem with Level Editor. Fixing it will be more complicate, though. I used information such as page number and frame number from the .cmd file to identify the picture to be used to represent the animation ... and thus the state.

Problem is that there's no such simple things when it comes to compound anim. Pages hold some limbs picture, but not the whole monster. AnimEDS creates thumbnails to display animations on the "thumbpage" ... the simplest way would be to record those thumbnails in the .spr file so that other programs (including LevelEditor) may display it more easily.

Compound Gob: release

D'aussi loin que remonte ce blog, le 24 mars, c'est le "release day". Ca a commencé en 2007 avec la première version d'Apple Rumble, puis une version de runme capable de jouer des fichier .xm envoyés par WiFi en 2008. 2009 a vu le premier d'une belle série d'outils destinés à repomper le contenu des jeux Game-Maker.

J'ai un peu triché en 2010 avec tout juste le gameplay d'Apple Assault ... et franchement loupé le coche en 2011, avec pourtant une première version de l'éditeur d'animations pas bien loin.

Ouais ... Bon ... il est largement temps que je me rattrape, quoi.

Voilà donc la première version de mon moteur de jeu qui soit capable d'animer des sprites construits dans AnimEDS. Avec tous les outils en prime, dans une belle release source ^_^.

essayez de le voir en action
24th of March ... release day ... go on sourceforge and grab the sources of the latest svn tree, which is now capable of rendering animations created in AnimEDS. Small step for humanity, but milestone for Bilou.

Maintenant, il me reste à reprendre AnimEDS et faire en sorte de pouvoir y définir les zones de collisions et les déplacement du personnage (en plus de son animation à proprement parler.

fusion!

Well, I owe sepcot a drink for his tutorial on "how to merge a Svn branch back in the trunk". Oh, sure, I could have dug the official documentation and find out by myself... in a few weeks. It's now achieved, and afaik, AppleAssault still works. Why is it of any relevance ? because runme is sticked on the trunk and that runme with the new engine means I'm able to prototype new monsters, new levels and such ... something the school zone will definitely appreciate ^_^

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

C'est ça, être branché.

Dans le monde de Bilou, le tileset et ses habitants vivent en paix. Le GameEngine maintient l'équilibre et l'harmonie de ce monde. Désolé, les amis. Apparemment, ça ne va pas durer...

Car, un funeste jour, l'horrible Mr. Pype bidouille le GameEngine et neutralise les pouvoirs du Makefile qui cherchait à le recompiler! Les GobStates, qui gravitaient autour de l'Engine perdent soudain leur stabilité naturelle ... et s'éparpillent dans tout l'disque dur! Préoccupant, non ?
Et en plus, ça fait désordre.

Dans ce monde à présent déséquilibré, d'étrange phénomènes se produisent ... des Applemen hostiles apparaissent plus vite que prévu, et quand on essaie de les assomer, ils se téléportent sur la gauche avant de revenir à la charge de plus belle ... non sans s'être momentanément transmuté en BerryBat ou en buisson ...

Remember when everything in Bilou's world was messed up to the point that Bilou turned into a jumping bush wandering around bubble-headed-trees? Well, with the regression test I applied to AppleAssault with the game-engine modification that are supposed to bring in compound animation, it appeared again. Applemen being flooded over the level rather than appearing progressively, they'd also stay stunned for much shorter and show some odd "side-effects", such as temporarily turning into berry bat on wake-up and even sometimes "teleporting" to the left while being pwned.

I had just introduced CommonGob, that captures the GobState management, including the reaction to an event (evaluating expressions, and so on), while the animation itself is still manipulated by SimpleGob (now a class deriving from CommonGob). It took me a couple of fixes to separate them right while still having the animation restarted from scratch when we switch states (and some more tests to handle the state3->state3 case). It would have been a mere lunchtime debugging session not worth mention if GDB hadn't decide to black-hole the SimpleGob class. No line numbers, no breakpoint, no variable or structure interpretation. Nothing but instruction stepping and register values >_<. I still haven't found out why, but I fixed the code nonetheless.

Bref, on aurait bien voulu appeler DDD à la rescousse, mais pas de chance: il ne parvient plus à interpréter une partie des annotations qui accompagnent les quelques classes maîtresses ... plus de visualisation des objets, plus de suivi des instructions ligne-par-ligne ... rien. sauf dans objdump. A en perdre son latin.