Sprite : réduire l'effet "patinage" en jeu ?

Pour toutes les questions concernant le Pixel Art, ça se passe ici.

Modérateur : Pix Modos

Avatar de l’utilisateur
onilink_
Pix Animator
Pix Animator
Messages : 3856
Inscription : 02 août 2010, 11:00
Localisation : Montpellier

Re: Sprite : réduire l'effet "patinage" en jeu ?

Message non lu par onilink_ » 08 août 2014, 19:44

Je pense que le soucis viens en grande majorité de l'animation.
La v2 est juste horrible a cause du décalage du corps, qui rend le tout complètement saccadé, et pour la v1, dans l'ensemble ça va.

D'après le peu d'expérience que j'ai dans le domaine, je pense que ça viens avant tout du nombre de frames.
Perso, pour mon platformer, avec un perso de ~16x48, j'utilise 2x4 frames pour la marche, et 2x5 frames pour la course. Sachant que plus un sprite est gros, plus il faut de frames pour limiter l'effet de saccade, 6 frames pour la marche ça me parait vraiment trop peu.
L’œil a du mal a comprendre comment se déplacent les pieds, et du coup ça donne un effet chelou car il arrive pas trop a tout reconstituer.
D'autant plus que les deux pieds sont assez sombre, alors c'est encore plus dur de distinguer l'un de l'autre au niveau de l'animation.


Un conseil pour la suite, si vous faites d'autres animation, avant de la texturer essayez la in game pour pas vous retrouver couillonné.
J'ai eu le soucis avec une anim de marche qui au final ne collait pas du tout avec la vitesse que le joueur devais avoir, du coup j'ai du la refaire alors que j'aurais pu me passer de ça en la testant direct :D

PypeBros
Baby Pix
Baby Pix
Messages : 1
Inscription : 08 août 2014, 22:13

Re: Sprite : réduire l'effet "patinage" en jeu ?

Message non lu par PypeBros » 08 août 2014, 22:20

De mon côté, je me suis construit mon petit éditeur d'animation dans lequel je peux "clouer un pied au sol". L'éditeur calcule les déplacements du personnage de sorte que le pied reste sur le même pixel, puis suit le pied suivant pendant l'autre partie du mouvement.

Dans le code, je garde une "accumulation" des déplacements qui n'ont pas été possibles. On ne passe à l'image suivante qu'après que l'accumulateur offre au moins autant de pixels que ce que l'animation réclame ... mais bon, c'est surtout utile pour un jeu où on veut pouvoir régler la vitesse du personnage. Si la vitesse est connue à l'avance, tu peux calculer les délais de façon à ce que le déplacement soit homogène et en tenir compte lors de sa création.

fil_razorback
Baby Pix
Baby Pix
Messages : 1
Inscription : 25 août 2008, 20:42
Contact :

Re: Sprite : réduire l'effet "patinage" en jeu ?

Message non lu par fil_razorback » 09 août 2014, 21:11

Tentative d'explication de ma part. L'image qui me sert de référence est un emprunt à ce site trouvé sur Google Images.

Quand on code un jeu en 2D, il est pratique pour les programmeurs que le centre de gravité des sprites soit toujours au même point à l'intérieur d'une frame (typiquement, au centre). Du coup, tout le monde a tendance à travailler directement en respectant cette contrainte:
Image

Une fois l'animation ainsi préparée, le programmeur ajoute le mouvement d'ensemble (qui correspond au déplacement du personnage dans le jeu) avec une vitesse constante et ça donne ceci (au ralenti pour qu'on voit bien):
Image
Drame, ça patine très très fort. Dans cet exemple, c'est particulièrement visible après la premier bond, quand les deux pieds sont au sol et que le sprite continue d'avancer pendant qu'il prend son élan pour le deuxième bond.

Voici un graphe où je tente d'expliquer ce qui se passe:
Image
En rouge, la position du centre de gravité en fonction du temps avec le mouvement linéaire ajouté par notre programmeur. Ce serait correct si le personnage était un tank ou un véhicule qui roule.
En vert, une allure de courbe qui représente comment un personnage qui court se déplace. En moyenne la vitesse est la même que pour la courbe rouge, mais elle change fortement au cours du déplacement. Les moments où la courbe est complètement horizontale sont les moments où la vitesse est nulle (le personnage n'avance pas, parce qu'il a les deux pieds au sol ou prend de l'élan) et ce sont ces moments où le personnage patine dans l'exemple précédent.

Pour corriger le problème, il faut implémenter ces variations de vitesse dans le déplacement macroscopique du personnage.

Étape 1: Demander à l'animateur de faire une animation correcte (toujours avec les mêmes frames). Ça devrait donner quelque chose de ce genre:
Image
Cet exemple est loin d'être parfait (je ne suis pas animateur) mais déjà bien plus convaincant que le déplacement linéaire qui précède. Si à ce stade ça patine, c'est que l'animateur fait n'importe quoi.

Étape 2: Pour chaque frame de cette nouvelle animation, mesurer la distance parcourue par le centre de gravité depuis le début de l'animation. Le programmeur va avoir besoin de ces mesures, elles peuvent être stockées dans un fichier à part, directement dans le code ou encodées dans les frames, peu importe.

Étape 3: Dans le code pour déterminer où afficher le sprite, on enregistre sa position de départ à chaque fois que l'animation boucle. A un instant quelconque, la position est déterminée en additionnant deux facteurs:
- La position de départ enregistrée au début de la boucle
- Une interpolation linéaire entre la mesure effectuée à l'étape 2 qui correspond à la frame actuellement à l'écran et celle qui correspond à la prochaine frame. Exemple avec des nombres bidons: imaginons que nous sommes entre la frame 5 et la frame 6. La frame 5 est à l'écran et a une durée de 0.10s dont 0.08s sont déjà écoulées (c'est bientôt l'heure de la frame 6 donc). A l'étape 2 on a mesuré un décalage de 24 pixels pour la frame 5 et de 30 pixels pour la frame 6. On doit alors utiliser un décalage de 24 + (30 - 24) * (0.08 / 0.10) = 28.8 pixels, que l'on arrondira à 29.

C'est une explication un peu simpliste mais ça corrige le problème. Une amélioration importante serait de ne pas utiliser directement les mesures de l'étape 2 mais de les ramener à l'échelle du déplacement total mesuré, puis de les multiplier par la vitesse que l'on veut donner au personnage. Ça permet de contrôler la vitesse moyenne du personnage dans le code et de réintroduire des idées importantes comme l'accélération.

/summon

Avatar de l’utilisateur
onilink_
Pix Animator
Pix Animator
Messages : 3856
Inscription : 02 août 2010, 11:00
Localisation : Montpellier

Re: Sprite : réduire l'effet "patinage" en jeu ?

Message non lu par onilink_ » 10 août 2014, 09:10

Par contre, si j'ai bien compris, faudrait changer la vitesse de déplacement en fonction de la frame?
C'est pas terrible dans un jeu ça, a la limite y a pas moyen de faire simple, et plutôt donner un temps différent a chaque frame? (ce qui nécessite logiquement de le prendre en compte quand on crée l'animation nan?)

En tout cas je pense pas avoir déjà vu dans un quelconque jeu une variation de vitesse, en général les gens font juste une animation bien adaptée au déplacement linéaire...
Ou sinon c'est juste que rare sont les jeux qui essayent de faire une animation vraiment réaliste, du coup l'effet de patinage n'est pas présent.
En tout cas j'ai jamais eu ce soucis.

Kyalie
Mini Pix
Mini Pix
Messages : 13
Inscription : 02 nov. 2011, 21:23
Localisation : Montréal
Contact :

Re: Sprite : réduire l'effet "patinage" en jeu ?

Message non lu par Kyalie » 10 août 2014, 19:59

Fil> Eh salut coupaing o/
Je me demandais quand même, ça fonctionne bien sur une course puisqu'il y a des moments où aucun pied ne touche le sol, mais pour la marche, il y a toujours au moins un pied qui touche le sol.
Mais merci pour ces explications, on a fait les choses à l'envers en fait, c'est-à-dire que j'ai adapté la position du centre de gravité dans son cadre pour un déplacement linéaire (sans succès forcément) alors que c'est la prog qui doit s'adapter au mouvement du centre de gravité, c'est ça ?

Avatar de l’utilisateur
farvardin
Pix Cool
Pix Cool
Messages : 83
Inscription : 20 juin 2013, 15:27

Re: Sprite : réduire l'effet "patinage" en jeu ?

Message non lu par farvardin » 11 août 2014, 18:35

franchement ça ne me choque pas l'effet de patinage dans les exemples 1 et 3 donnés plus haut (splendide décors et personnage par ailleurs...). La saccade est plus génante.

Avatar de l’utilisateur
Uubu
Master Pix
Master Pix
Messages : 691
Inscription : 28 janv. 2014, 17:24
Contact :

Re: Sprite : réduire l'effet "patinage" en jeu ?

Message non lu par Uubu » 12 août 2014, 17:33

Pareil qu'au d'ssus, félicitation pour tous ces beaux pixels !

Pour en revenir à l'animation, je trouve dommage de la restreindre à 6 frames, vu la taille et les détails de vos sprites.
ImageImageImageImage

Avatar de l’utilisateur
onilink_
Pix Animator
Pix Animator
Messages : 3856
Inscription : 02 août 2010, 11:00
Localisation : Montpellier

Re: Sprite : réduire l'effet "patinage" en jeu ?

Message non lu par onilink_ » 12 août 2014, 17:39

Oui a cette taille 6 frames c'est juste pas possible.
Déjà même des sprites standard, genre 16x32, le 6 frames ça passe pas, il en faut au moins 8. Alors ici...

alexbart
Fana Pix
Fana Pix
Messages : 22
Inscription : 05 oct. 2015, 20:30

Re: Sprite : réduire l'effet "patinage" en jeu ?

Message non lu par alexbart » 08 oct. 2015, 22:26

Je me suis pris la tête sur la question sans jamais trouver de réponse. Pour un mouvement non sacadé, j'ai utilisé par exemple les timelines sur gamemaker. Cela donne un rendu propre comme dans flashback ou prince of percia mais cela suppose d'adapter le Gameplay : le personnage aura une inertie.

A défaut, je pense qu'il faut penser l'animation d'un sprite de marche à vitesse continue et revoir donc les frames.

monsieur_ouxx
Fana Pix
Fana Pix
Messages : 15
Inscription : 10 nov. 2015, 10:26

Re: Sprite : réduire l'effet "patinage" en jeu ?

Message non lu par monsieur_ouxx » 24 nov. 2015, 16:54

La seule solution universelle pour réduire une ffet de patinage est de déterminer un point (sur le personnage) qui avance à vitesse constante. Généralement, sur un humain, c'est le torse+les hanches. (c'est déjà ce que fil_razorback a expliqué en substance ici).
Ensuite, il faut animer tout ce qui vient autour en conséquence. Peu importe comment on anime les jambes, si on fait avancer le sol à vitesse constante sous le torse immobile, ensuite il suffit d'ajuster le nombre de frames de l'animation, et les FPS in-games.
Là où ça se complique c'est s'il n'y a aucun point qui avance à vitesse constante (démarche saccadée).

Répondre