Ce titre racoleur (:p) ne fait qu’annoncer 3 choses : le retour du curseur (qui m’a fait paniquer un instant), le retour des événements et le système de pause.
Commençons par le système de pause, même si sujet technique, si vous changez de fenêtre ou d’onglet de votre navigateur, le système (canvas) se met en pause technique, et à votre retour il recommence. Jusque là ok, sauf qu’on boucle en déterminant le temps qui passe entre 2 images pour faire avancer de manière fluides les animations et autres. Du coup quand on revient c’est le bordel, tout s’excite et essaye de rattraper le temps perdu, mais vous n’étiez pas là et pour vous ça aurait juste dû s’arrêter et reprendre à votre retour.
Autre phénomène d’exemple, une vidéo, vous arrivez, on joue un son ou vidéo, vous changez d’onglet, ça serait souvent préférable de stopper l’ensemble. Évidemment ceci est soumis à une somme de variables dépend de ce que vous en faites. Un jeu se met en pause c’est sympa, ça vous préserve, mais un MMO ne se met pas en pause, même s’il faut stopper techniquement le rendu et peut-être les sons. Il y a matière à réflexion, et c’est pas demain que j’aurais les réponses, et encore moins de manière générique.
Ensuite nous avons le retour des événements, pris par le service Navigator, qui fait le pont entre le composant Angular et le programme/jeu et ses besoins. Et donc le curseur !
Pour le curseur c’est devenu très simple, il suffit d’avoir un Element, le charger et le dessiner aux coordonnées reçues par l’événement mouseMove (quand on passe la souris sur l’écran). Le truc c’est que rien ne charge le curseur, ses images, ni ne définit son animation par défaut (même si une seule image c’est une animation figée). Il y a encore de quoi améliorer bien sur. Du coup là on charge le curseur définit dans la conf de la scène, ne serait-ce que pour le Sprite et son type, sait-on jamais, ça ne coûte pas grand chose actuellement, on verra sur la durée.
Là où j’ai paniqué c’est au rendu… car j’avais pas tilté directement qu’on avait l’empilement et donc la gestion de hauteur et donc un sol au dessus du niveau 0. du coup notre curseur est dessous, mais dessiné par dessus.
AvantEncore plus de question, où devrait apparaître le curseur, ou est-ce que le sol devrait être descendu pour rendre l’idée d’origine ? La seconde option me plait, mais il faudra voir en fonction des élévation, et là on retombe sur l’idée de déplacer le curseur en fonction de la position du Ground (l’Element sol, qui n’existe pas encore comme tel). Mais dès lors, vous risque de voir votre curseur bouger verticalement alors que votre souris fait juste un passage de gauche à droit simple, car le curseur voudra s’adapter au terrain. Dilemme donc !
Il existe aussi la méthode du Raycasting (lancé de rayon), qui consiste à partir de la position du curseur de la souris à déterminer quel élément on touche. On parcoure les Elements du plus près au plus lointain (l’inverse exacte du rendu) et si la hit box 2D (= on touche le dessin ?) de l’Element attrape le curseur alors on s’arrête et on dit qu’on est là. On part donc du rendu visuel pour déterminer où on est, sans suivre la grille réelle technique. À peu de chose près.
Pour les détails, l’événement clavier a été raccordé pour désactiver la pause automatique quand on change d’onglet. Même si le débat demeure sur cette gestion de pause. De plus toutes les scènes n’ont pas besoin de l’infos de pause non plus (ex.: menu).
La suite ?
Comme dit dans le précédent article, un Element capable des 4 directions NESW et le pathfinding. Et peut-être des réponses à mes interrogations précédentes. Le nombre de TODOs ne cesse d’augmenter… ^^.
J’aimerais également sauver le code sur un git maison pour préserver tout ça, même si on enchaîne les POCs.