Animations

[TheoWinterhalter]

Je viens d'ajouter une image pour le curseur (waouh bravo !) et je pense qu'à terme il serait bien qu'il soit animé (de même pour les unités et tout). En fait tout ça a besoin d'être smooth, donc on va avoir besoin de compter le temps passé comme le fait actuellement @VLanvin dans le module FPS. Je voulais savoir comment on avait prévu de le gérer pour que ça ne soit pas trop dégeu.

De la même manière on pourrait rendre plus smooth les déplacements de la caméra.

Je sais que c'est loin d'être pressé, d'où le milestone.

[VLanvin]

Alors côté anims, je vais proposer (et adapter) ce que je fais d'habitude. Déjà, pour tout rendre plus smooth, le super truc c'est les interpolateurs. Et pour ça le fonctionnel c'est génial, un interpolateur est juste une fonction float -> unit, qui prend en paramètre le temps depuis la dernière update et fait ses opérations en conséquence. Et tu stockes tous tes interpolateurs dans un module qui se charge de tous les updater/supprimer/créer au besoin.

Par exemple, tu crées un objet Cursor avec des attributs position, scale, etc.. et les accesseurs voulus. Et bien tu peux y coller un interpolateur sinusoidal qui a chaque itération va modifier scale de telle façon que tu aies un curseur animé. Et tu peux en mettre un peu partout, pour des menus qui s'ouvrent progressivement, des textes animés, etc...

Pour les anims des unités c'est plus dur. Personnellement, j'aurais probablement créé un mixin "Animated" dont Unit aurait hérité et qui se serait chargé d'updater la texture en temps réel. Mais on a fait le choix de ne pas mélanger rendu/moteur, donc c'est à oublier. Je suppose aussi qu'on peut oublier le fait d'ajouter une variable d'état (avancement de l'animation) au module Unit et d'y coller un interpolateur, pour les mêmes raisons. Du coup, j'y ai pas mal réfléchi, et j'ai trouvé un bon compromis. On pourrait ajouter à notre grosse classe ClientData une table de hash qui référence tous les "trucs" animés, comme les unités, batiments (?), etc... et qui leur associe ce dont on a besoin, à savoir leur état (moving/idle/...) et une variable d'animation (qui, en gros, indique la frame de l'animation). Les fonctions comme draw_unit vont vérifier cette table et agir en conséquence (si l'unité n'y est pas déjà, on l'ajoute avec un état initial comme Idle, frame 0). Et histoire de réutiliser du code, quand tu veux (par exemple) faire marcher une unité (mettons que l'animation soit composée de 4 images), tu la passe en "Moving" et tu lances un interpolateur sinusoidal de période bien choisie sur sa variable d'animation qui va alterner entre les 4 images (1-2-3-4-3-2-1-...) ainsi que sur sa position (ou mieux, une variable d'offset stockée elle aussi dans la table) pour avoir un déplacement smooth entre deux tiles.

Reste un problème avec cette solution, c'est de lier la texture aux variables. La solution sale c'est de traduire directement en string, par exemple si tu as une infantrie en train de marcher et à la frame 3, tu vas chercher la texture infantry_walking_3.png. Là, j'y ai pas encore trop réfléchi. Peut-être qu'un mix à base de tilesets serait bien.

[TheoWinterhalter]

Okay. Ça me va. Par contre, est-ce la peine de créer un module pour le curseur ? Le module caméra devrait suffire ? (Même si je pense que les deux ne devraient pas se déplacer à la même vitesse, je dirais que le curseur devrait être plus rapide).

Ensuite, pour ce qui est des différentes textures, c'est un problème en effet… Ce serait bien d'avoir quelque chose de pas trop sale si, par exemple, on souhaite ensuite orienter nos sprites et éviter d'avoir des unités qui font du moonwalk sur la carte.

[VLanvin]

Le module curseur je vais y réfléchir, mais ça peut être sympa d'encapsuler sa taille/sa position dans un objet si on veut le modifier.

Pour les différentes textures, je pense que si on fait des tilesets et qu'on modifie légèrement TextureLibrary pour parser un fichier config avant de charger les tilesets ça devrait faire un truc pas trop mal.

En fait, j'ai un problème avec ce que tu entends par "smooth-er" le déplacement du curseur. Tu veux pouvoir le déplacer librement ? Parce que comme il est carré et de la taille d'une tile, ça me parrait bizarre de le voir à cheval sur deux tiles.

[TheoWinterhalter]

Par ça j'entend que le déplacement n'est pas instanné mais très rapide. Le curseur ne se téléporte pas (enfin la texture qui le représente). Je pense qu'on stocke toujours la position du curseur de la même façon. Mais que l'image essaie de le suivre

[TheoWinterhalter]

Ah, je vois qu'on ne vois pas la caméra et le curseur de la même façon. Je pensais personnellement contrôler le curseur et avoir un caméra smooth qui suivait mais toi tu as choisi le contraire.

[VLanvin]

Ah effectivement je n'avais pas compris comme ça :) C'est pas grave, et loin d'être définitif, on peut changer ça assez facilement je pense. De toute façon ce que j'ai fait ne me convient pas vraiment.

[TheoWinterhalter]

J'ai rajouté la gestion des chemins de manière dynamique (c'est une première itération puisque pour le moment on ne gère pas les points de mouvement etc. donc je n'ai pas éprouvé le besoin de faire de Dijkstra) avec une élimination simple des boucles (il y a du linéaire en la taille de la liste, mais je pense qu'on atteindra jamais des valeurs énormes).

Et là je trouve que c'est plutôt gênant de ne pas avoir de déplacement réactif. Je pense vraiment que le curseur devrait être rapide (comme avant) mais avec un caméra smooth pour le plaisir des yeux.

—— Une fois réglé on peut envisager un pull à nouveau ? Un de fin de journée (on va faire des dailies).