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.
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.
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 :)
Curieuses couleurs pour Bilou, alors qu'il s'agit d'une capture du rendu de l'image de la semaine dernière dans firefox sur ma LTS fraîchement réinstallée ... je vais devoir ajuster les réglages colorimétriques de firefox, peut-être ?
ReplyDeletehttps://developer.mozilla.org/en-US/docs/ICC_color_correction_in_Firefox pour une décision éclairée ...
ReplyDelete