Et ben rien du tout 🙂 C’est l’optimisation qui fait faire un régime sec à notre système de raycasting, en évitant dès que possible le travail inutile. Ceci se fait de plusieurs façons.
La première consiste à commencer par le haut. Car les chances sont plus grande qu’un objet sur un autre recouvre celui-ci. Là aussi il y a deux points à regarder, d’un côté la Scene qui contacte ses Elements un par un dans son sens inverse de rendu (dans le cas présent de la Scene Iso – isomérique) et d’un autre l’Element lui même qui possède potentiellement plusieurs Sprites, dès lors Element générique les empiles et donc le contrôle se fait en commençant par le haut.
Ensuite, même si déjà fait dans mon code précédent, on peut épargner des contrôles de bounds si au moins un a été touché par le point.
Vous remarquerez que le contour du tronc n’apparaît plus en noir.
La seconde, consiste lors du test d’un Sprite de détecter s’il a des bounds (bords pour la détection) et ensuite, s’il en a, une fois les calculs de repositionnement effectué, on test si le curseur est au minimum dans le cadre virtuel de l’image du Sprite.
Le tout combiné, entre les optimisations côté Iso et Element, nous donne ceci :
On remarque que seuls les Elements qui sont susceptibles d’être en contact avec le point ont été marqués, ce qui signifie que le calcul n’a été fait complètement que pour ceux-là. Vous imaginez donc, entre la première photo de cet article et cette dernière, l’avantage directe de cette optimisation.
Dans la continuité, je me suis attelé à m’occuper des interrogations précédentes, car sans un pointage efficace il sera difficile de bien comprendre ce qui se passe, surtout en cas d’erreur. Du coup, aujourd’hui, c’est la révolution du curseur !
Premièrement, il a fallu ajouter une méthode pour savoir si on est sur un Element ou non, quelque soit l’algo, et ainsi le dire à la Scene pour qu’elle s’arrête au plus tôt (économie) et puisse déterminer la position, ou ne rien trouver.
On part du fait que la souris donne sa position, je vous passe le trafic des événements, et on pose le curseur à la coordonnée reçue.
Premier point : le curseur se met au niveau zéro et c’est chiant, car avec l’élévation, l’œil humain se perd et à du mal à coller la grille sans repère. Donc on va s’occuper de ça directement.
Il s’agit d’insérer l’Element curseur sur le dernier Element de type Ground de la coordonnées, donc après si on regarde la liste des Elements de cette coordonée. Il ne faudra pas oublier de le retirer au prochain déplacement significatif de la souris (x ou y différent).
Ensuite, on peut revenir sur la détection du curseur, et là on fait du raycasting (lancé derayon), car la position de la souris sur base de la grille n’est pas suffisant, la souris touche quelque chose et pas forcément le niveau zéro d’une case de la grille. J’ai donc opté, pour commencer quelque part, par le cadre de l’image au complet.
En gros on va prendre le chemin inverse du rendu. Au lieu de commencer au plus haut on part du plus bas, en remontant inversement les Elements dessinés.
Les images finales en fin d’article démontrent clairement ce que j’exprime ici, vous verrez.
On se base sur le point de repère de l’image, on ajuste en fonction du point de pivot (basex, basey), le tout en prenant la bonne frame du sprite et ses caractéristiques et surtout, on oublie pas de ramener tout aux coordonnées 0, 0 de l’écran (client du navigateur). Sinon comment comparer une position de souris avec une image quelque part à l’écran, les 2 avec un système de coordonnées différentes.
On a donc un premier jet fonctionnel, mais vous remarquerez directement que ce n’est pas idéal, on compare des rectangles théoriques avec des losanges visuels, l’utilisateur ne comprendra pas, et c’est normal.
On peut améliorer ça si on se donne un peu plus de mal, et là j’ai cherché comment détecter un point dans un polygone, mais entre Math complexes et obscures, librairie fermée et autres, les possibilités sont nombreuses et pas toutes idéales (vitesse, facilité, …). J’ai opté pour une ligne dans un triangle et là j’ai découvert qu’en fait c’est 3 fois une comparaison du point avec une droite, de quel côté le point est. En sens horlogique, les valeurs négatives sont à « l’extérieur » de la droite si on considère le triangle comme 3 droites qui ferment le polygone. Du coup on peut augmenter le nombre de droites, tant que le tout reste un polygone convexe. Ce qui nous donne après plusieurs encodages des données de points :
C’est beaucoup mieux n’est-ce pas ? Plus précis surtout. Là il ne faut pas se tromper, on démultiplie les tests, donc il ne faut pas oublier de couper court dès qu’on sait si on touche au moins une fois l’Element.
Suite aux expérimentations, tout fonctionne, mais on perd le curseur dans la zone grise quand on a pas de Ground présent sur la grille. Cela vient du fait que le rayon n’a percuté personne donc ne rend rien, du coup il faut revenir à l’ancien système de coordonnée de souris vers coordonnée du monde, tout simplement, comme avant.
Ceci dit, ce monde démarre en 0, 0 et les valeurs négatives sont refusées par une des méthodes, je dois encore regarder à ça, mais pensez-y.
Notez également un problème avec le resize, le curseur se démultiplie bizarrement visuellement, mais rien de clair actuellement sur la raison. Il faudra inspecter l’état de map ou subsetmap, et ce n’est pas du tout une mince affaire…
Le chargement chaîné
Depuis le début, une des problématiques est d’avoir les infos quand elles sont disponibles et nous sommes dépendant de chargement de Sprite. La Scene s’occupe du chargement de ses Elements mais aussi des Sprites via le service Resources. J’ai modifié ça, et je pense améliorer l’idée et la mécanique en mettant le chargement de l’image dans l’Element et en modifiant fortement la manière dont Resources s’en occupe. Désormais, le premier Element qui veut charger un Sprite, va créer un Observable dédié et s’y accorcher. Le second Element qui a besoin du même Sprite ne va pas recréer mais s’accrocher tout simplement à l’Observable déjà créé. Ainsi, quand le Sprite a fini, il prévient tous ceux accrochés. Je rajoute que si le Sprite a déjà fini de se charger quand on le demande, on renvoie un Observable auto clôturé, ce qui donnera l’info directement que c’est bon, c’est chargé.
L’avantage direct est l’initialisation de l’Element sur base des infos des Sprites dont il a besoin. Pensez animation et c’est direct le bordel dans la tête. Un Sprite contient les définitions du possible, l’Element contient l’état actuel. Ainsi l’Element, lors de son update(), cherchera les infos de l’animation courante qu’il a décidé de jouer dans le Sprite. Chacun son rôle, mais si Sprite n’est pas chargé quand vous voulez initialiser Element ça ne fonctionnera pas car pas encore disponible.
Initialement, je faisais cet initialisation au premier update de l’Element, car là on savait que tout était chargé. Il ne peut y avoir d’update d’une Scene que si celle-ci a obtenu le feu vert du chargement des ressources.
Maintenant, au lieu d’un « if » perpétuel, valable qu’une seule fois, dans la fonction update, on a une initialisation propre et un update tout aussi propre.
Plusieurs Sprites pour un Element
Un sujet qui traîne depuis une refonte, c’est le fait qu’un Element peut avoir plusieurs références de Sprite, ceci pour un objet composé comme un arbre, un personnage etc.
Mais que faire au niveau de base de Element, toutes les méthodes actuellement prennent le premier de la liste et ne s’occupent pas du reste. Pire il n’y a pas de contrôle ou d’adéquation entre la configuration envoyée à l’Element et sa nature (je suis une fougère…).
Du coup, j’ai complété une idée précédente, encore un POC, mais qui tient quelque chose. J’ai créé un service DTD (document type definition) et créé 2 listes de références pour déterminer le chaînage entre des Elements et une autre pour déterminer de quoi est fait un Element typé. En plus clair, si je suis un Tree (arbre), j’aurais besoin d’une définition pour Trunk (tronc) et une pour Foliage (feuillage), sinon comment l’Element de type Tree pourra savoir qu’il a bien reçu les Sprites dont il a besoin s’ils ne sont pas identifiés ?
Nous avons donc maintenant un Element (générique), qui reçoit son type par la configuration et une suite de références de Sprites, on passe cette liste par une moulinette de contrôle grâce à la DTD de types et nous avons là une liste identifiée de références propres au type de notre Element.
Là de suite ça n’apporte pas grand chose, juste un contrôle de ce qu’on reçoit, ne prendre que ce qui est possible pour notre Element typé. Un Tree ne va pas s’occuper d’une référence de roché par exemple, il l’ignorera. Nous sommes d’accord que ce cas de figure n’a pas lieu d’être, sauf si édité à la main avec erreur.
L’avantage de ceci est que si nous créons un éditeur pour TARS/Nahyan, en cliquant sur un Element, on recevra sa cartographie via son type et donc on pourra créer un formulaire pour choisir les Sprites attendu par le composant. Prenez un arbre tronc et feuillage, sélectionnez le, modifiez le tronc de chêne par un tronc de bouleau et un feuillage d’automne plutôt que d’arbre mort, un choix de texture typée pour un Element ayant une définition venant de la DTD.
S’il n’y a pas de définition, un type par défaut englobe tous les cas où il n’y a qu’une seule image pour l’Element, ce qui facilite les encodages, les réduits et n’oblige pas de faire une sous classe par type si la seule différence est cette notion. On a donc un Element générique capable de beaucoup de chose à lui tout seul.
Dans notre cas d’arbre, l’Element Tree doit dessiner un tronc et un feuillage. si vous vous rappelez un article précédent sur l’empilement, il suffisait de faire X Element et de les mettre dans l’ordre à une coordonnée, l’empilement aurait fait le travail, mais vous n’auriez pas la possibilité de donner un comportement global et programmé à votre arbre. Vous voulez une interaction, et peut-être que le tronc fasse 4 hauteurs de bloc avant de mettre le feuillage, il vous faut donc une extension de la classe Element, en étant générique, elle ne traite pas les particularités, c’est un peu le but.
On créera donc une nouvelle classe Element pour notre arbre, on l’appellera TreeElement et on surchargera uniquement la fonction de dessin et de contact pour le raycasting. En fonction de paramètres spécifiques, prévus dans la définition de la configuration possible des Elements, nous pourrons dire la taille de notre arbre, qui sera le multiplicateur du tronc par exemple (si on considère un tronc comme un bloc de tronc).
C’est là que la définition par le type de nos références de Sprite a de l’importance, car notre TreeElement pourra explicitement faire une référence aux Sprites dont il a besoin par leur nom prévu. Il sait qu’il peut manipuler un Sprite nommé Trunk, et un autre nommé Foliage. Ainsi il saura quoi faire lors du dessin et lors de la détection, vu que les 2 dépendent de comment le dessin final est monté.
C’est complexe a expliquer, mais une fois que l’on comprend le rôle de chacun, la nécessité de séparer proprement les concepts, la manière dont c’est utilisé etc. alors cela devient simple pour vous. Mais je vous accorde que c’est un exercice de pensée qui n’est pas aisé surtout avec juste des explications et quelques illustrations sommaires.
La suite ?
Toujours le pathfinding et l’objet NESW, qui restent la suite logique de ce qui a été fait jusqu’à présent. Ainsi que les quelques bugs décelés : valeurs négatives refusées sur la grille, considérer le haut d’abord dans la détection de contact et le soucis de curseur lors du resize, entre autres.
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.
Encore 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.
Merci POC Sonic 🙂 ! Ceci dit, cela démontre également l’importance d’un Sprite Packer, ce n’est pas rien, mais tant qu’on est pas plus avancé je ne vais pas investir, et continuer de bricoler un peu. Quand on sera plus avant, il sera toujours temps de regarder les options (shoebox, texturepacker, …).
Comme vous pouvez le voir dans ce gif tout pourri (pas merci OBS et convertio), tout est rendu avec la nouvelle technique utilisant l’animation. Il reste a optimiser update() et draw() des objets sans animation, mais quand on y pense, ils auront tous au minimum les 4 directions NESW, mais on a pas encore décidé si Sprite divisé ou non, imaginez la composition du truc…
Quand on parle d’animation on oublie qu’il y a plusieurs genres, ici c’est l’animation des Sprites, mais il y a également le mouvement (déplacement en Z par exemple ou variance de x,y), ainsi que des particules ou effets par exemple, qui combineraient les 2.
La suite ?
Ayant récemment mis au point sur papier le pathfinding (trouver son chemin suite à un clic sur la carte), c’est la direction suivante que je vais prendre. Ceci comprendra l’orientation NESW, faire un élément Hero, regard suivant la souris, réactiver le clic, le curseur et les événements avec propagation, le déplacement en évitant les obstacles, du coup le zoom aussi tant qu’à faire (même si c’est réservé à l’éditeur, donc à voir).
Allez encore 25 TODOs sans cette liste précédente ^^…
Petite victoire suite à l’article précédent, j’ai réussi à déplacer la fonction de dessin au sein d’un Element, proprement en supprimant la dépendance cyclique, tout en affinant les objets de bout en bout. Ce qui est amusant c’est que j’ai supprimé 50-80 lignes de code pour un résultat amélioré et identique au rendu, c’est toujours agréable.
Notez qu’on avait déjà refait le subset (portion de la carte à rendre à l’écran – optimisation), en considérant la somme du Tile suivit des Items à la même coordonnée ([Tile, Element, Element, …]) et ainsi faciliter le rendu tout en corrigeant la notion de couverture d’un Tile sur un Element : un morceau de terre recouvre l’ombre du second arbre dans l’image ci-dessous, sans ça l’arbre était dessiné après et donc l’ombre recouvrait le bloc de terre qui n’a rien à voir. Ainsi c’est plus juste visuellement tout en ayant une boucle plus facile à traiter.
Du coup map (contenant tout le monde chargé) a subit le même lifting que subset (le schéma de données d’entrées aussi), soit la somme directe de tous les Elements et on supprime Tile qui perd de sens si on donne Z à Element (c’était la seule différence). Du coup on pourra étendre Element pour les objets composés.
Ensuite, étant lancé, on (avec Boudine) a continué sur l’empilement et donc la notion d’animation, toujours dans la fonction draw de Element. Le résultat comique quand oublie qu’un objet a une taille, c’est qu’ils s’écrasent au niveau 0. Ensuite, si vous oubliez que initialement vous considériez le haut du sol comme point de base, et qu’ensuite vous mélangez la nouvelle notion de taille avec les ancienne valeur de base, vous avez un sol à l’ancienne place et des arbres qui volent ^^, car eux ont suivit l’élévation incrémentée et le sol non.
En résumé un Sprite contient la notion de taille de l’objet représentée, selon la frame d’animation (ou la seule image par défaut), et le système de rendu sur base d’une hauteur de base donnée, incrémentera de la taille de l’objet rendu, additionné de son élévation Z. Ainsi vous pouvez avoir un arbre sur un arbre comme dans l’image ci-avant. Et pour illustrer l’élévation vous avez les blocs de terre qui montent ou descendent, ce qui est dessus suivra naturellement.
Tout fini bien quand les petits correctifs sont appliqués. On a donc un rendu avec code mieux réparti (le bon endroit), une mécanique d’initialisation et de rendu améliorée, des lignes et procédures inutiles retirées et le sentiment de progresser dans le bon sens.
La suite ?
On a ouvert la porte à la structure d’animation, le système de rendu de Element doit encore être amélioré pour traiter ça complètement, car Element n’a pas encore de gestion des ses animations. Pour cela le code du POC Sonic servira de base car il couvrait pas mal de possibilités variables. Il restera à faire un cas de test. Notez que je sais qu’un logiciel libre existe pour composer lui-même sur base d’image un Sprite, me reste à le trouver et voir s’il rend en sortie également les références de positionnements, ça aiderait grandement.
Sinon, on peut également repartir sur l’intégration des events, qui doivent transiter par Game ou directement aux Scene actives, à voire, et ainsi reprendre le dessin du curseur et le zoom. Reste à savoir où mettre tout ça et comment raccorder.
Nahyan, ça fait un bout de temps dis donc et en en reparlant avec certains membres de l’équipe originale, ça n’a pas prit une ride (Merci K-you). Ça tombe bien j’ai toujours pas abandonné !
Reprenons la situation
Reprenons quelques instant un mini résumé de la situation : « Seul je ne sais pas faire le jeu tel que pensé et il faut arrêter de croire que je serai aidé ».
Ensuite, dans l’optique « j’y arriverais malgré tout », il faut reprendre ce qu’on a comme acquis permettant de démarrer : je suis développeur web et pas illustrateur. Il faut donc que j’amoindrisse mon ambition, sans casser le projet ou perdre l’envie de le faire, rester motivé et prendre du plaisir à le faire.
Du coup on repars un an en arrière, j’étais développeur web en mission pour Auchan et j’ai développé, entre autre, un éditeur de plan de masse (en gros la vue du haut des meubles d’un étage de magasin). Ceci a été fait sous Angular en Canvas et c’était bien amusant de le faire. Du coup quand c’est sympa on explore et on chipote, on fait ça encore mieux, etc. Ce qui donne ceci :
Vue partielle de l’éditeur
En gros on a comme possibilité de sélectionner, drag/droper d’une liste vers le plan ou du plan vers le plan (déplacer un meuble), molette de souris pour faire une rotation du meuble ou zoom du plan (min-max), visibilité de la sélection dans une liste sur plan ou inversement au survol, etc… Le tout avec les optimisation possible pour ne dessiner que ce qui est nécessaire tout en se faisant plaisir avec les petites ombres par exemple.
Exemple de rendu d’objets : 3 meubles de différents type, une caisse et un escalator
Ici on a un exemple de certains éléments graphiques créés directement en code.
Tant qu’on y est…
J’étais lancé et je ne pouvais pas explorer plus avant les possibilités de cet éditeur, du coup je me suis créé un petit projet perso pour tester les animations en sprite. En fouillant un peu j’ai retrouvé ce bon vieux Sonic.
Ainsi j’ai pu chercher comment découper, afficher, animer, retourner, etc. notre petit héro bleu. Ensuite, me casser les dents sur la physique de déplacement du personnage mais ça on va zapper…
Oui mais ensuite ?
Ensuite la mission s’est terminée et j’ai eu quelques jours au bench. Du coup je me suis occupé en tentant de renforcer mes compétences Angular, surtout sur la partie mise en place d’un nouveau projet. Car c’est facile d’utiliser ce qui a été mis en place par d’autres, mais le faire soit même c’est de la découverte casse-gueule…
Coder c’est joli, mais un rendu c’est mieux, Canvas c’était sympa et comme j’avais déjà fait un POC (preuve de concept) isométrique en canvas à la maison, je me suis dit que mélanger les deux rendrait la chose plus amusant, Angular et Canvas pour un moteur isométrique. Il manquait un truc : les éléments graphiques, et c’est pas le plus simple.
En fouillant je suis tombé sur l’excellent site opengameart.org, fait par un développeur, Clint Bellanger, d’un jeu gratuit et open-source nommé Flare, de lien en lien je suis également tombé sur son blog partageant ses études du sujet isométrique et de son jeu et moteur graphique.
C’est dans la même suite de recherches que je suis tombé sur le magnifique logiciel MagicaVoxel. Ce truc est terrible, pas évident au début mais très agréable. C’est là que je me suis dit : » tu n’es peut-être pas graphiste/illustrateur, mais t’as les notions et la créativité pour faire de ce logiciel l’instrument qui te manquait « .
Du coup j’ai fait ça :
Un morceau de terrain isométriqueOui c’est un arbre
Ok je me suis bien amusé, j’ai chipoté et fait un rendu isométrique par le logiciel et puis ?
Ensuite j’ai transposé mes précédents essais et morceaux de code du projet Auchan, Sonic et compagnies en un POC de rendu isométrique. Ce qui donne, après de nombreux chipotages et réflexions sur les calculs de rapports entre écran et monde, monde et écran, en incluant les notions de zoom, d’offset et d’élévation :
Tadaaa… ok ça ressemble à rien mais en une matinée c’était pas mal (une demi journée de recherche à tourner en rond sur le net et un début de rendu). Évidemment ce n’est pas suffisant, il nous faut un objet et un curseur pour contrôler et vérifier les formules de positionnement, de zoom etc.
Et avec un objet pour vérifier la superposition, l’ombrage et l’élévation :
Du coup ça fonctionne, un POC de +650 lignes, données incluses, ça fait plaisir, et on est à 1 jour et demi. Puis en chipotant sur des dessins et en repensant au plan de masse d’Auchan, je me suis dit, qu’est-ce que ça donnerait en isométrique ? Il m’a suffit de dessiner un meuble au l’autre, changer la carte de données, corriger des superpositions et ordonnancement pour avoir ce petit magasin :
Vue isométrique test d’un plan de masse
Ça a fait beaucoup rire les collègues 🙂 .
On s’arrête au POC ?
Bien entendu non, j’ai réussi une étape, c’est bien, je l’avais déjà fait mais là c’est plus abouti. La base est là et vérifiée, on peut continuer ! Cependant c’est un POC tout dans un seul fichier, c’est pas propre et continuer là dedans c’est pas une bonne idée. Du coup, on décompose le code en morceaux, on crée des classes, on structure son code, on découvre les joies des inclusions cycliques, des prises de têtes de » Où mettre ça ??? « , etc… Il m’aura fallu presque une semaine pour transposer le code et en arriver presque au même point qu’au POC :
Test de rendu d’un terrain variable avec objets
Là on a une version complète et fortement améliorée pour son côté structuré et flexible. Manque le curseur et le zoom qui n’ont pas encore été recâblé pour la simple et bonne raison que je me suis concentré sur le système de rendu, la structuration des données, simplification/factorisation du code et correctifs divers.
En parallèle
À coté de ça, j’ai tenté de m’installer un espace de travail propre, un petit GitLab sur le serveur daaboo, mais quand on a la moitié de RAM que nécessaire… et pas de redmine encore car GitLab pourrait peut-être suffire. Mais on est loin du compte encore. Le top serait d’avoir le moteur graphique séparé de l’usage Nahyan, on lui a trouvé un nom » TARS « , je vous laisse chercher pourquoi.
La suite ?
Là ça fait une semaine que je m’échine à refondre la structuration Sprite et Element, suite de ce que je disais avant, fondre et refondre pour trouver le bon équilibre de séparation des concepts, stockage des données, etc. J’y suis presque, l’idée est d’avoir un Sprite qui s’occupe de stocker l’image et les infos descriptives de cette image (points de référence, hauteur/largeur, frames d’animations, …) et de l’autre un Element faisant référence à un Sprite tout en ayant ses valeurs propres. Ainsi 2 Elements « brin d’herbe » utilisant le même Sprite pourront être animé séparément et ne pas avoir cet effet ringard de tous les mêmes élément animés en même temps.
Dans cette refonte j’essaye d’inclure directement la notion d’animation et d’objet composé.
Il y a encore pas mal de travail avant d’avoir à nouveau une base propre, stable et bien pensée, même si on sait d’avance que ce n’est pas le dernier refactoring du code de base.
Pour détails du jour
Pour ceux que ça intéresse ou pour le souvenir :
Usage de la classe Bloc au lieu de l’interface périmée
Suppression de Tile au profit de Element contenant une propriété Z (élévation).
Nettoyage et fixes suite à la disparition tragique de Tile
La grande question est… (non pas celle là) comment transférer Draw de Scene dans Element vu qu’on a un Camera, un incrément de bloc et des coordonnées d’écran
Stacking mis en place au niveau du subset
Hero est un set de données x, y en dur
Cursor désactivé, mouse event aussi
Autre question est comment mélanger Iso et rendu standard au sein d’une scène, mélange de méthode et de services
Pour info il y a 30 TODOs qui traînent dont 19 rien que dans Iso…
Pourquoi diable un article sur Badawok 7.x ? Car en fait je l’utilise encore et continue de faire progresser sa branche, même si la 8 a été démarrée. D’un côté car il est en prod et qu’il faut suivre parfois les petits couacs potentiels, et puis, surtout, car je développe un nouveau site client, et donc, avec une version stable et pas en dev, comme je peux me le permettre avec Comitards.
Que dire ? Plein de trucs !
Depuis le début de la 7, une page peut prévoir des remplacements, textes pour 99% de l’utilisation mais également d’insertion de module, via les accolades ( {class:method|params|...} ). Une erreur a été corrigée au niveau de la détection des params, jamais utilisé jusqu’ici, et très fortement utilisé dans mon projet actuel. Quatre ans plus tard, une fonctionnalité voit son plein potentiel, et ça fait plaisir !
De même, une bonne surprise de conception, l’ordre des étapes de rendu permet de passer des arguments via PHP : {class:method|params|<?php echo $maVar ?>}.
Ainsi une problématique récurrente a pu trouver une nouvelle solution : la traduction de données.
Le système de langue étant dynamique, le nombre de langue varie et la maintenance de formulaires est pénible, coté front et coté code avec les checks etc. On découpe tout ça autrement.
Brutalement on imagine une table avec un seul id, mettez ce que vous voulez comme champs, excepté du texte. Coté formulaire vous ne vous occupez que de vos champs et vous insérez là où vous voulez l’appel au système de traduction ({trad:displayOne|params}) les params pouvant définir, dans un ordre définis, l’id du champs, son maxlength, etc. Je vous passe les détails.
Dynamiquement le formulaire sera complété de vos champs et ceux-ci seront pré-rempli si existant. Côté back, 2 méthodes, une de check des required et langue par défaut et une de sauvegarde multi-lingue.
Maintenance plus aisée, tant pour l’utilisateur que le développeur 🙂 !
Avec le même système d’insertion de module, et sur retour d’expérience du site terragusto.be, où la colonne de gauche devait être préparée par chaque action, ici notre menu/sous-menu principal est composé de 3 insertions, un par menu. Ainsi on ne met pas de code dans le layout non nécessaire et le rendu de manière centralisée avec les appels préparatoires qui vont bien et toujours les ACL qui vont avec.
Encore un autre usage et amélioration, la barre d’admin, d’habitude dans le layout sur condition ACL (Access Control List) et ici en centralisé avec config pour le global et la possibilité à chaque action de déclarer un menu potentiel, dont l’ACL activera ou pas l’affichage.
Enfin, un système de message d’erreur ou confirmation centralisé, inspiré de l’univers ZF. On envoie le message, on le configure pour son apparence et hop, le prochain affichage possible les affichera selon le template défini.
Cette version a encore du poil de la bête et n’a pas encore tout donné, c’est un plaisir personnel de voir son propre framework capable et fonctionnel :).
Le 13 janvier 2009 Fozzgog est arrivé, non sans mal. Et quelques années plus tard il se tût… Violet ayant fait faillite, racheté, re-faillite, abandonné et la communauté à réussi à obtenir les codes sources et le domaine nabaztag.com.
Je vous passes les détails de l’histoire, c’est long et internet en est gorgé. La question est, après autant de temps, puis-je encore le faire fonctionner comme « avant » ou presque ?
La réponse est « oui » !
En cherchant je suis tombé sur le tuto de Pierre Dandumont utilisant OpenJabNab avec l’aide de la communauté. L’article est déjà vieux et n’est plus tout à fait à jour, j’ai du bricoler un peu, d’où cet article pour en faire la mise à jour.
Je vais essentiellement reprendre ses étapes et retirer/ajouter la différence. Principalement je ne suis pas sous mac et n’utiliserais pas le service Bonjour. L’OS de base n’est plus tout à fait le même non plus.
Mon idée est de pouvoir promener mon lapin chez moi et en dehors moyennant une prise de courant. Il est quand même la mascotte de la Famille du Band Bleu 🙂
Mon matos :
Un Raspberry B (r2), alim etc.
Carte SD 4Go
Mon Nabaztag:tag, alim etc
Un routeur WI-FI
Clavier, souris, écran HDMI (ou adaptateur etc. dans mon cas)
On branche plein de fils
Le Raspberry
Le brol
Cannibaliser l’arcade
Sur la carte SD j’ai mis une version de Raspian Jessie Lite, pour n’avoir que le nécessaire et sans interface graphique. J’ai essayé Noobs mais sur la 4Go, la mise à jour n’avait pas assez de place. Après de toute façon il ne nous faut que de la console :).
J’ai utilisé win32diskimager pour mettre l’image sur ma carte SD.
On branche et on allume. Oubliez pas que le login/pw de base sont pi/raspberry.
Config de base
Un fois connectez on va mettre les bonne conditions de départ, tapez sudo raspi-config, vous aurez un bel écran d’interface avec un tas d’options :).
Activez SSH s’il ne l’est pas, réglez votre langue et étendez le file system à toute la carte. Dans notre cas on est déjà console, pas besoin de désactiver l’interface graphique au boot. Mais vous pouvez régler la mémoire vidéo à 16Mo.
Dans les options avancées il y a aussi hostname, ne l’oubliez pas, donnez un nom à votre terrier :). Ça évite de toucher aux fichiers (hosts, hostname) manuellement par la suite.
Là normalement vous pouvez ping, mais non ! Dans cette version il y a une erreur connue. Vous devrez d’abord exécuter : sudo chmod u+s /bin/ping .
Ensuite tentez un ping vers ce que vous voulez pour vérifier votre connexion réseau.
Maintenant qu’on a du réseau on met à jour.
sudo apt-get update
sudo apt-get upgrade
Ensuite on fixe son IP. Dans mon projet de promener l’installation ça a d’autant plus d’importance.
sudo nano /etc/network/interfaces
Mon réseau est en 192.168.1.x, vous devrez adapter les configs selon votre cas. Vous devez modifier la ligne iface eth0 inet dhcp en :
On sudo reboot, on débranche clavier souris etc, on laisse juste alim et réseau. On retourne a son bureau, on s’installe confortablement, on prend putty et on se connecte :
ssh pi@192.168.1.150
Serveur DNS
Comme le dit le tuto de Pierre, le truc chiant c’est que le lapin a besoin d’un nom de domaine pour se connecter au serveur. Donc il nous faut notre propre serveur DNS local.
C’est parti pour plein de config. Perso j’ai eu du mal sur cette partie du fait des mises en pages des contenus. Pour infos je me suis basé sur mes configs de domaines, le tuto de Pierre et une doc.
On va créer notre nom de domaine : terrier.loc avec son sous domaine ojn.terrier.loc .
sudo nano /etc/bind/named.conf.local
Attention la deuxième partie est l’envers de notre réseau.
zone "terrier.loc" {
type master;
file "/etc/bind/db.terrier.loc";
};
zone "1.168.192.in-addr.arpa" {
type master;
file "/etc/bind/db.192.168.1.inv";
};
Maintenant il nous faut les 2 fichiers précisés.
sudo nano /etc/bind/db.terrier.loc
$TTL 604800
@ IN SOA ojn.terrier.loc. root.terrier.loc. (
1 ; serial
604800 ; refresh
86400 ; retry
2419200 ; expire
604800 ) ; negative cache TTL
;
@ IN NS ojn.terrier.loc.
@ IN A 192.168.1.150
;
ojn IN A 192.168.1.150
;192.168.1.150 IN A 192.168.1.150
# Generated by resolvconf
domain home
nameserver 192.168.1.1
nameserver 192.168.1.150
Particularités ici, si vous avez un soucis d’accès lors de test du domaine, commenté la 1.1. Si vous rebootez elle sera décommentée.
Enfin, on active le serveur de cache pour accéder au net. On décommente la partie forwarders et on met l’ip de la passerelle.
sudo nano /etc/bind/named.conf.options
options {
directory "/var/cache/bind";
// If there is a firewall between you and nameservers you want
// to talk to, you may need to fix the firewall to allow multiple
// ports to talk. See http://www.kb.cert.org/vuls/id/800113
// If your ISP provided one or more IP addresses for stable
// nameservers, you probably want to use them as forwarders.
// Uncomment the following block, and insert the addresses replacing
// the all-0's placeholder.
forwarders {
192.168.1.1;
};
//========================================================================
// If BIND logs error messages about the root key being expired,
// you will need to update your keys. See https://www.isc.org/bind-keys
//========================================================================
dnssec-validation auto;
auth-nxdomain no; # conform to RFC1035
listen-on-v6 { any; };
};
Redémarrez et testez, ping google.com, ping ojn.terrier.loc. Cf. ma remarque d’avant avec les ligne nameserver.
Vous pouvez également tester depuis votre poste en modifiant votre connexion réseau et en précisant le serveur DNS à 192.168.1.150.
Le serveur
On y est, on va mettre le serveur en place et on va utiliser un Apache, comme dit Pierre, il y aura pas des milliers de lapins.
Tapez l’ip de votre OJN (dans mon cas 192.168.1.150) pour y accéder. Vous devriez avoir le message « Problem with OpenJabNab ! » signe que tout va bien 🙂 Si vous avez une page d’index c’est que votre mod rewrite n’est pas activé.
Maintenant c’est compilation ! Yeah 🙂
sudo apt-get install qt4-qmake qt4-qtconfig qt4-designer qt4-dev-tools libqwt5-qt4-dev build-essential
cd /var/www/OpenJabNab/server
sudo qmake -r
sudo make
cd /var/www/OpenJabNab/http-wrapper/ojn_local/plugins/
sudo wget http://down.dandu.be/nabaz-lang-mp3-fr.tar.gz
sudo wget http://down.dandu.be/nabaz-ojn-mp3-fr.tar.gz
sudo tar xvfz nabaz-lang-mp3-fr.tar.gz
sudo tar xvfz nabaz-ojn-mp3-fr.tar.gz
Et on lance !
sudo ./bin/openjabnab
Techniquement ça devrait démarrer sans erreur. Du coup on va dans l’admin du terrier 192.168.1.150/ojn_admin.
En bas de page on peut voir les infos, ce qui montre ce qui a été chargé, preuve que ça fonctionne.
Il vous faudra créer un compte, le premier sera mit en admin automatiquement.
Le lapin
Ensuite il faut ajouter le lapin, dans account, donnez lui un nom en suivant les contraintes et entrez sa mac.
Prenez votre lapin, allumez le en appuyant sur son bouton de tête, il devient bleu. Connectez vous à son Wi-Fi et rendez-vous sur son ip 192.168.0.1.
Le lapin a du mal à se connecter en Wi-Fi (peut-être mon lapin), déjà le WPA il a du mal mais y arrive parfois (nabaztag:tag), le v1 lui ne sait faire que du WEP. Je n’ai pas envie de chipoter, j’ai un routeur, une connexion invisible, ça suffira, j’ai désactivé la sécurité. Faites en fonction de votre projet et de votre lapin !
Dans la config avancée, désactivez le DHCP, donnez lui une IP fixe (192.168.1.151) ensuite renseignez le serveur ojn.terrier.loc/vl.
On sauve, le lapin redémarre et si tout va bien ça s’allume ! Le lapin bouge les oreilles et vous sautez dans tous les sens, votre lapin se reconnecte !
Lancement automatique
J’ai essayé en vain la solution du daemon. Je n’ai peut-être pas trouvé de solution suffisamment à jour. J’ai donc utilisé la solution barbare mais fonctionnelle de Pierre :
sudo nano /etc/rc.local
#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.
# Print the IP address
_IP=$(hostname -I) || true
if [ "$_IP" ]; then
printf "My IP address is %s\n" "$_IP"
fi
sudo /var/www/OpenJabNab/server/bin/openjabnab
exit 0
Dans les possibilités de suites, car OJN ne gère pas/plus les chorégraphies ça serait de développer le plugin le permettant, tout à l’air d’être à disposition pour y arriver. Il n’y a quasi pas de doc donc ça sera empirique mais pourquoi pas essayer.
En local TTS et Taïchi fonctionnent bien. L’API pour le coucher, lever, TTS aussi. C’est déjà une bonne base pour redévelopper avec. Reste à voir si il peut le faire en autonomie.
Prenons le cas où vous avez votre domaine, vous configurez un compte mail et le raccordez à un compte GMail pour plus de facilité. Classique.
D’un autre côté vous avez votre serveur et vous envoyez des mails avec le même compte mail.
Et bim, vous voilà avec un compte bloqué !
OVH sécurise vos comptes mails en surveillant la provenance de connexion. GMail est en Amérique et votre VPS (par exemple) en France, du coup, en même temps vous êtes connecté à 2 endroits = piratage de compte détecté.
Une fois que ça vous arrive, ils vous suffit de déclarer un incident chez OVH et de leur expliquer la situation. Ainsi, plus de soucis.
Évidemment, cela n’arrive que dans le cas où votre GMail rapatrie ou envoie des mails pendant que votre serveur effectue également un envoie de mail. Mais c’est toujours bon à savoir.
Notez que pour débloquer votre compte il vous faudra vous rendre dans votre manager et saisir un nouveau mot de passe (ou le même). 5 à 10 minutes plus tard le statu sera revenu à la normal.
Suite au fait que les emails envoyés par certains de mes sites ne sont plus reçus, j’ai cherché et trouvé une solution qui fonctionne conformément à mes attentes.
Contexte : VPS sur OVH, domaine OVH qui pointe vers ce VPS.
Première chose, j’utilisais déjà PHPMailer, une version précédente et domaine configuré pour SPF et DKIM. Donc mise à jour vers la source github de PHPMailer.
OVH n’est pas clair dans sa documentation quand vous en trouvez une qui est cohérente avec le reste et à jour. Basez vous sur le mail reçus lorsque vous créez votre compte. Le mail vous donne les ports et adresses à utiliser ainsi que l’indication très importante : connexion POP3 avant SMTP.
Par bonheur, la doc de PHPMailer fourni un exemple complet en ce sens.
//Authenticate via POP3.
//After this you should be allowed to submit messages over SMTP for a while.
//Only applies if your host supports POP-before-SMTP.
$pop = POP3::popBeforeSmtp('pop3.example.com', 110, 30, 'username', 'password', 1);
//Create a new PHPMailer instance
//Passing true to the constructor enables the use of exceptions for error handling
$mail = new PHPMailer(true);
try {
$mail->isSMTP();
//Enable SMTP debugging
// 0 = off (for production use)
// 1 = client messages
// 2 = client and server messages
$mail->SMTPDebug = 2;
//Ask for HTML-friendly debug output
$mail->Debugoutput = 'html';
//Set the hostname of the mail server
$mail->Host = "mail.example.com";
//Set the SMTP port number - likely to be 25, 465 or 587
$mail->Port = 25;
//Whether to use SMTP authentication
$mail->SMTPAuth = false;
//Set who the message is to be sent from
$mail->setFrom('from@example.com', 'First Last');
//Set an alternative reply-to address
$mail->addReplyTo('replyto@example.com', 'First Last');
//Set who the message is to be sent to
$mail->addAddress('whoto@example.com', 'John Doe');
//Set the subject line
$mail->Subject = 'PHPMailer POP-before-SMTP test';
//Read an HTML message body from an external file, convert referenced images to embedded,
//and convert the HTML into a basic plain-text alternative body
$mail->msgHTML(file_get_contents('contents.html'), dirname(__FILE__));
//Replace the plain text body with one created manually
$mail->AltBody = 'This is a plain-text message body';
//Attach an image file
$mail->addAttachment('images/phpmailer_mini.png');
//send the message
//Note that we don't need check the response from this because it will throw an exception if it has trouble
$mail->send();
echo "Message sent!";
} catch (phpmailerException $e) {
echo $e->errorMessage(); //Pretty error messages from PHPMailer
} catch (Exception $e) {
echo $e->getMessage(); //Boring error messages from anything else!
}
Il vous suffit de mettre les valeurs qui vous sont transmise et … ça n’ira pas encore.
Il va vous falloir vous connecter également à SMTP.
//Whether to use SMTP authentication
$mail->SMTPAuth = true;
//Username to use for SMTP authentication
$mail->Username = "yourname@example.com";
//Password to use for SMTP authentication
$mail->Password = "yourpassword";
Il vous suffit de modifier SMTPAuth de false à true et d’ajouter les 2 lignes et c’est fini !
Badawok
Note à ceux qui utilisent le framework badawok (v7 dans mon cas), vous aurez un conflit entre votre classe mailer et base_mailer car badawok utilise déjà un PHPMailer.
Supprimez l’extend de la classe base_mailer et ajouter les require_once des classes : phpmailer, smtp et pop3. Créez un répertoire vendor dans votre projet pour y mettre proprement les 3 classes de PHPMailer et le tour sera facilement joué.
La v7 étant uniquement patchée pour le moment, cette modification ne sera pas répercutée.
Avant
