où est mon crayon ?

I guess I should have kept Google+ and blogger accounts separated, but for some reasons, I wanted to open the circles of "readers" for this blog, and I thought enabling g+ would have been the good way.

But all of sudden the little "pencils" and "wrenches" icons that let me edit the content easily got lost.

Hopefully enough, I'm not tool-less to investigate such annoyances. First, Firefox 10 comes with the ability to inspect elements: with just a right-click, I can open the inspector mode (Q) and explore the content of the web page much more efficiently than source exploration would have offered. it's a span.item-control.blog-admin ... neat. It has display:none because of an obscure rule in 1937454905-widget_css_bundle.css ...

I guess I shouldn't have tried to enable "share post" buttons on a layout as custom as mine, but I did. Since the problem only occurs on one machine (and since it's not affecting anyone than myself), I can take local action: somewhere in $HOME/.mozilla/firefox/*/chrome/, there's a file dubbed userContent.css that allows overriding of CSS properties at will. I can then say that

.item-control { display: inline !important; }

And that will show the icons back. Well, it's a bit extreme: it shows icons on any blogs, including thoses where I have no edition rights. And it might do other things on other webpages as well. I could have used a @document domain(sylvainhb.blogspot.com) to work that around, but unfortunately, G has also decided not so long ago that the webpage I'd visit would depend on the country I'm in. When visiting torino, I'd end up on sylvainhb.blogspot.it in no time, with my rules (potentially) not applying anymore.

So I hope I can come back with a real explanation and a fix soon ... I'll have to live with that hack running in-between.

'nuf said. Back to dumblador throwing. I need to ensure we don't grab some when we're carrying some.

edit: all of sudden, I need to swap a bool in about:config to be able to use my userContent.css file ... oh well ...

En voiture!

Je continue de suivre ma petite carte de développement, une fonction à la fois. Après les panards baladeurs, après la correction des bugs d'animation, voici le transport de dumblador.

First occurence of a transported GOB tonight: stunned dumblador will not simply follow Bilou (as BerryBat): it sticks to a defined position relative to Bilou. A nice "proof of concept" before I try to make it look as professional as possible. [done]

Un nouveau "contrôleur" qui utilise directement les coordonnées de Bilou (après attachement) pour aligner le dumblador. Ça n'est pas encore aussi impeccable que je le souhaite, et on peut observer un léger décalage qui dépend de la vitesse de Bilou, comme avec les plate-formes de Zool. Il faut donc que j'aille jeter un oeil aux listes d'animation pour ajouter le support de ces bits "pending" pour arranger ça.

Puis j'irai chercher une technique de "costumes" à la Monkey Island pour que les mains de Bilou reste sous le Dumblador.

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.

Jongleries ...

Bon! Il reste encore du travail avant que ces choses rebondissantes puissent être associées aux pieds de DumbBlador qui tentent de retourner auprès de leur maître, mais au moins, elles se dirigent bel et bien vers l'objet qui les a lancées. Le mécanisme d'attachement fonctionne, et le contrôleur associé également. On va pouvoir poursuivre :)

Neat! Things are thrown when one bops a blador, and once they stop, they'll move back and track the GOB they come from. If there's a wall blocking them, they'll jump higher to pass it. It's far from looking like "feet that go back to their body", but at least the mechanic works.

gob->attach(that)

J'ai trouvé un cas de figure pour tester la fonction "attacher un GOB à un autre" qui doit me servir entre-autres pour transporter Dumblador ou pour faire de SpongeBob une plate-forme mobile.
Je veux dire, "un cas de figure qui ne dépende *que* de cette nouvelle fonction".

Starting to work on a set of new features such varied as "grab bladors and throw them onto other ennemies" usually raise the problem of "where do we start". Among all the features (aligning Gobs onto each other, tracking them, etc.), I need a first one that is simple enough and demonstrate the bare bones needed in the code logic: attaching objects at run-time. It seemed that bladors feet could be a candidate. When I draw Bilou bopping a dumblador, blador's feet are stretched away from its body. And when Bilou throws bladors at pendats, the feet are gone, leaving just a large chunk of steel ... a living weapon.

It would be easy to have feet "thrown away" when blador gets bopped on, but then, what should we do when the blador recovers? It magically rebuilds up wherever its feet are gone, like New Super Mario Bros' drybones ? I'd rather not.

Actually, I'd rather have feet attached to their blador although they have been thrown, and guided by a controller that pulls them back in place. The blador's body (the initial GOB) would then stay stunned until both feet have returned. Not only that sounds funny to do and play with, but it also means that the terrain surrounding the dumblador will affect how long it will stay stunned if you stomp it, and thus how tricky it is to grab it before it recovers. A nice interplay approach, imho.

Je m'étais amusé à imaginer Dumblador perdant ses pieds au moment où Bilou lui saute sur la tête ... eh bien, c'est exactement ce dont j'ai besoin. Les pieds deviennent des GOBs autonomes, mais restent "attachés" à leur Dumblador d'origine, ce qui permet de définir des contrôleurs qui les ramènent vers celui-ci. On verra par la suite si celà crée un gameplay intéressant, mais pour l'instant, ça semble un test prometteur.

• Le mécanisme "pending" qui garanti que l'objet auquel on fait référence a déjà été traité n'est pas encore complètement opérationnel.
• Lors de la génération des "tirs", ceux-ci sont assimilés aux objets passifs d'une collision alors que le "tireur" est l'objet actif.

C'est le tronc qui ment le moins.

J'avais pas mal tatonné au moment de faire le tronc de l'arbre pour la forêt de Bilou. Un des éléments qui m'avait été indiqué sur pixelation était le manque de "volume" retranscrit par mon graphisme. Et là, en faisant une petite promenade matinale dans les parcs de Torino, je constate avec stupeur que le tronc des arbres n'est absolument pas éclairé "principalement d'un côté, l'autre dans l'ombre.

Que se passe-t'il donc dans ce parc qui défie les lois de la physique ?

Eh bien, tout simplement, l'arbre a un feuillage suffisament large et dense pour faire de l'ombre à tout son tronc. Résultat, aucun éclairage direct pour lui. La lumière qui lui parvient est le résultat de la diffusion (tous azimuts) notamment par le sol. De plus, le tronc est rugueux, et pas lisse. Les rayons de lumières y sont eux aussi écartelés et n'auront donc pas de zones "highlights" comme le ferait une surface plus lisse.

Bien sûr, dans son jeu vidéo, on est libre de choisir les conditions d'éclairage de son arbre, tout en veillant à ce qu'elles soient cohérentes avec celles des objets alentours. Et si jamais on décide de faire un arbre au tronc assombri, il reste un élément qui peut lui donner du volume: la distortion des motifs. Ici, l'écorce de l'arbre s'est craquelée en une sorte d'entrelac de lianes sur un fond plus rougeâtre en vieillissant. Globalement, l'écart entre deux "lianes" est le même partout, mais on l'observe plus serré sur les bords qu'au centre.

Voilà. Dessinez bien, moi je vais tenter de rattraper mon retard de sommeil.

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.

tint'm'up!

Avec les nouvelles version de SEDS et AnimEDS, je n'aurai plus à rougir de la variété des Koopa Troopa. Me voilà également capable de créer des personnages animés en changeant la teinte des différents sprites utilisés. Voilà qui complète agréablement les modifications apportées à mon éditeur de niveau début septembre. Je vais peut-être bien pouvoir en profiter pour faire un premier essai de "pendat" en 2D, même si au départ, j'avais prévu d'utiliser des polygones pour ce perso (et pour BangBash, d'ailleurs).

Ain't 'fraid o' Kolorful Koopas. No more. With my latest updates on SEDS and AnimEDS, I can use up to 8 distinct palettes for the sprites I use to build character and monsters animation. The same "hands&feet" spritesheet can be used for Bilou, Dumblador and even Pendats, with two separate shades for foreground and background. That should be quite enough.

Now I've got to focus on the thing I've left behind for a while: make the game engine support all this as well. Right now, the 'schoolzone test' has a 'donkey kong return' look: only the owl-styled background has colours, and everything else is plain black ^^". But not right now. Right now is Ravioli time.