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.