Inside the Inkjet

Pas si simple de mettre Bilou dans un encrier, même une fois le résultat à obtenir défini. Il serait sans doute bon de reprendre les évolutions de la semaine qui se sont agglutinées dans une "todo list" qui n'était pas initialement prévue pour ça.
En premier, il me fallait un moyen de forcer les sprites à clignoter de manière sélective, et dont la définition se ferait au niveau des scripts. C'est pour un test, je ne fais pas dans la dentelle et j'introduis simplement un nouvel opérateur dans les expressions de changement d'état qui modifiera cette propriété de clignotement. En quelques essais, je peux rendre Bilou semi-transparent lorsqu'il s'est fait touché. Encourageant.

It wasn't supposed to be that long. With the desired rendering defined, I'd have thought I could implement the flickering-translucent-inkjet in one sunday afternoon at most. I started with a couple of simple checks, like blinking Bilou when hit, and then selectively blink only some limbs. That was all neat and sleek. I had forgotten, however, that 'pulling' some limbs worked only "locally" by rearranging limbs within a sprite (although 3 distinct, globally ordered OAMs lists were introduced).

Mais je ne veux pas que l'entièreté de Inkjet clignote: seulement le "patch" destiné à masquer Bilou lorsqu'il est à l'intérieur. Je change donc la sémantique de cet "opérateur-clignotant" pour qu'il reçoive plutôt des bits de contrôle et laisse le rôle de "compteur" à une variable accessible depuis les expressions du script. Je peux du coup faire clignoter seulement le corps de Bilou ou une de ses mains ... tout va pour le mieux.

Par contre, le code permettant de modifier l'ordre d'affichage des composants d'un sprite (les OAMs du hardware, donc) n'offrait jusqu'ici qu'une modification interne au sprite, faisant passer une main devant le corps, etc. mais sans permettre de placer un composant devant Bilou et un autre derrière. Or, c'est essentiel pour "entrer" dans l'encrier.
C'est le comportement "global pull" qui utilise les mêmes commandes "pullmask" qu'auparavant, mais qui force maintenant un changement de zlist pour les composants tirés vers l'avant-plan. Le code du moteur de jeu n'était pas tout à fait prêt pour ça.

Once invariants for pulling limbs into list 0 on demand were ready, I realised the path to victory was cluttered with unrevealed bugs dating from z-ordering and even per-controller-events introduction. It's all fixed now, but it leaves a kind of annoying "not-quite-professional-coding"... I guess I should have known this from the start, this being a hobby project, I can't always afford being professional :P

That being said, I definitely want to take the time to clean up the interface and provide some coherent way to define the (pullzero?, flickermask, pullmask, flickertime) variables in a cleaner way.

Il m'aura encore fallu un ou deux temps de midi pour comprendre pourquoi ce damné encrier refusait de tenir compte de mes commandes pour continuer à clignoter. En fait, il restait un bug datant de l'introduction des évènements-par-contrôleur. Qu'un seul contrôleur voie sa liste d'évènements prise en compte lorsque deux (ou plus) disent simultanément "évènement", je pouvais m'y attendre. Qu'un "évènement" et un "impossible" se traduise en "réinitialisation", franchement, je ne l'avais pas vu venir. Il aurait été plus "pro" de concevoir des cas de tests suffisament riches au moment où cette nouvelle fonctionalité a été ajoutée. Seulement voilà, un pro code aussi en-dehors des temps de midi :)