L`Animation pour les Nuls Ou tout ce que vous avez toujours voulu

Grospixels
064/03/Sunday 20h49
L'Animation pour
les Nuls
Ou tout ce que vous avez toujours voulu savoir sur les
Hertz sans jamais oser le demander
Par Wild_Cat (février 2006)
Merci à Erhynn Megid
Merci au site Amiga Chapter One pour les gifs animés de
sprites Amiga
Si vous votre intérêt pour les jeux vidéo dépasse le stade de simple
dilettante (ce dont votre présence sur Grospixels devrait être une
assez bonne indication), vous avez sans doute déjà entendu parler
d'images par seconde. Vous savez que 60 Hertz sont mieux que 50,
et si vous avez déjà joué sur PC vous savez qu'un jeu qui saccade est
un bon signe de l'âge trop avancé de votre machine. Oui, mais
comment cela marche-t-il ? Vous êtes-vous jamais demandé pourquoi
certains jeux sont plus lents sur une console Européenne que sur une
Américaine ou une Japonaise, pourquoi la démarche de Bren McGuire
est plus fluide dans Turrican 2 sur Amiga que dans Super Turrican sur
SNES, ou ce qu'il se passe quand un jeu rame ? Et puis d'abord, c'est
quoi un Hertz ?
Cet article se propose de répondre à toutes ces questions. Si la
technique vidéoludique vous ennuie profondément, ce qui suit risque
de vous barber aussi : il va y avoir du code, du cambouis, des
http://www.grospixels.com/site/animation1.php
Page 1 sur 8
Grospixels
064/03/Sunday 20h49
consoles gisant éventrées à même le sol et zéro discussion sur la
variation dans la réponse émotionnelle du joueur qu'engendre
l'utilisation d'une narration en flashback dans Max Payne 2.
Toujours là ? Bien. Procédons.
Papa, papa, c'est quoi, un Hertz ?
C'est plusieurs choses. Tout d'abord, une entreprise de
location de voitures, fondée en 1918. Mais ça, tout le
monde s'en fout. C'est aussi un physicien allemand,
Heinrich Rudolf Hertz (1857 - 1894). Mais c'est surtout
l'unité SI de fréquence, qui tire son nom dudit physicien
Allemand. Un Hertz (Hz), au sens qui nous intéresse,
c'est l'inverse d'une seconde. C'est le nombre de fois par seconde
qu'un phénomène périodique se reproduit.
Prenez par exemple une balle qui rebondit sur le sol. Si elle rebondit
une fois par seconde, on dit que le rebondissement s'effectue à 1 Hz.
Si elle rebondit 2 fois par seconde, c'est 2 Hz... Et ainsi de suite. A
quoi ça nous sert ? J'y reviens dans quelques paragraphes. Laissezmoi juste le temps d'expliquer...
La Grande Arnaque
Je me dois de la dévoiler : depuis notre plus jeune âge, nous sommes
les victimes d'une immense supercherie. Chaque fois que nous allons
au cinéma, que nous regardons un écran de télévision... Chaque fois
que nous jouons à un jeu vidéo, nous nous faisons avoir. C'est une
immense mystification qui dure depuis plus d'un siècle, et dont le
cerveau humain, ce vil organe, est le complice.
Voilà : l'animation, c'est du pipeau.
Les images ne bougent pas. On nous
le fait seulement croire. Lorsqu'on
regarde un film, ce que l'on voit en
réalité, ce sont des images statiques
diffusées l'une après l'autre très
rapidement. Une sorte de diaporama,
mais avec 24 diapositives par seconde.
Chaque
image
est
légèrement
différente de la précédente, de telle
sorte que le cerveau croit qu'il est en
train
d'en
voir
une
seule en
mouvement.
Le
processus
est
identique que l'on soit devant un
écran de cinéma, de télévision ou
d'ordinateur. Les seules choses qui
changent sont la manière dont les images (en anglais frames) sont
affichées (projection, tube cathodique...) et la vitesse du diaporama,
ou framerate. On exprime celui-ci en images par seconde (IPS, ou
FPS pour frames per second si vous êtes un inconditionnel de la
langue de Britney Shakespeare). Pour vous faire un ordre d'idée, voici
quelques framerates typiques :
http://www.grospixels.com/site/animation1.php
Page 2 sur 8
Grospixels
064/03/Sunday 20h49
- Film de cinéma : 24 FPS.
- Dessin animé de bonne qualité (Disney au cinéma) : 12 FPS, avec
des pointes à 24 quand ils sortent les images de synthèse.
- Dessin animé de mauvaise qualité (Dragon Ball Z à la télé) : oscille
entre 4 et 12 FPS, avec une moyenne aux alentours de 6.
- Jeu console PAL (EU) : 25 ou 50 FPS.
- Jeu console NTSC (US/JP) : 30 ou 60 FPS.
- Jeu PC : P/(40*(D+1)) FPS, où P est le prix auquel vous avez payé
votre machine et D le nombre d'années écoulées entre son année
d'achat et celle de parution du jeu.
Mais, entends-je dire, c'est un phénomène périodique, ça ! Ne
devrait-on pas plutôt exprimer sa fréquence en Hertz ? C'est vrai,
mais on ne le fait pas pour deux raisons. Tout d'abord parce que cela
pourrait porter à confusion (l'unité est déjà utilisée pour autre chose
dans le domaine qui nous intéresse), et ensuite parce que rien ne
garantit que le nombre de FPS est constant sur une oeuvre donnée.
J'y reviens dans un instant.
Je veux 1000 FPS !
La fluidité d'un jeu vidéo dépend directement de son
framerate : plus le nombre d'images sur une période donnée
est élevé, et moins la différence entre une image et la
suivante est perceptible. Du coup, plus il y en a et mieux
c'est. Par exemple, la raison pour laquelle la démarche de Bren
McGuire paraît plus fluide dans Turrican 2 que dans Super Turrican,
c'est parce qu'il est animé en 50 FPS dans T2 et moins de 25 dans
ST. Dans l'idéal, donc, tous les jeux devraient avoir un framerate
tendant vers l'infini. Ce n'est bien évidemment pas possible, et ce
pour diverses raisons.
Afficher une image, ça prend du temps
Tout d'abord, rien n'est jamais instantané en informatique. Lorsque
votre ordinateur ou votre console vous fait la Grande Arnaque (c'est à
dire tout le temps), il se passe grossomodo ceci :
Afficher image 1
Effacer image 1
Afficher image 2
Effacer image 2
Afficher image 3
[...]
Chacune de ces opérations prend du temps machine, aussi minime
soit-il. En théorie, donc, le framerate maximal que peut afficher un
ordinateur donné est 1/(t1+t2), où t1 est le temps nécessaire pour
afficher une image, et t2 le temps nécessaire pour l'effacer. En
pratique, c'est moins que ça.
Les écrans ne sont pas parfaits
Un écran ne peut afficher
qu'un certain nombre d'images
http://www.grospixels.com/site/animation1.php
Page 3 sur 8
Grospixels
064/03/Sunday 20h49
par seconde : 50 pour un
téléviseur PAL, 60 pour un
NTSC, 85 à 100 pour un bon
moniteur à tube cathodique.
C'est
sa
fréquence
de
rafraîchissement, exprimée en
Hertz (ah ha !). Celle-ci, une
fois l'écran en fonctionnement
(je
vous
épargne
les
changements de résolution et
compagnie), ne varie jamais,
contrairement au framerate d'un jeu que rien ne garantit. Si l'on
envoie à un écran un framerate inférieur à sa fréquence de
rafraîchissement, les images resteront affichées plus longtemps (par
exemple, dans un jeu à 25 FPS sur un écran à 100 Hz, chaque image
restera affichée pendant 4 rafraîchissements).
Si au contraire le framerate du jeu est supérieur à la fréquence de
rafraîchissement de l'écran, on peut assister à un phénomène étrange
où l'image a changé avant que l'écran n'ait pu finir de la tracer : on a
donc à l'écran le haut de la première image et le bas de la deuxième.
Cet effet de "déchirure" est très visible lors des mouvements latéraux
de caméra quand le framerate est légèrement supérieur à la
fréquence de l'écran. Le framerate d'un jeu est donc limité par la
fréquence de rafraîchissement de l'écran qui lui sert d'affichage. Ce
qui indique du coup que sur micro-ordinateur (la seule plate-forme où
vous avez le choix), plus la fréquence de rafraîchissement de l'écran
est élevée et mieux c'est (d'autant que sur les écrans à tube
cathodique, une fréquence inférieure à 75 Hz se traduit par un effet
de scintillement très fatiguant pour les yeux). Reste une dernière
limite, la plus gênante...
Boss, qu'est-ce que je mets dans l'image ?
C'est bien beau de pouvoir afficher une image, encore faut-il savoir
quoi afficher. Un jeu vidéo est par définition interactif et donc
imprévisible. Entre l'affichage d'une image et de la suivante, le
programme doit calculer ce qu'il y aura dessus. Autrement dit, il faut
que tout ce qui est nécessaire à son affichage ait été résolu, à savoir
:
- Les commandes du
joueur ("il a appuyé sur
la gâchette droite, je
fais quoi, patron ?").
- La "physique" du jeu
(par exemple, la vitesse
de
décélération
de
Mario lorsqu'il est en
train de courir et que le
joueur
lâche
la
manette) et toutes les
autres règles. Dans un jeu doté d'un "vrai" moteur physique comme
Havok (Max Payne 2, Halo, Psi-Ops...), cela peut devenir très
compliqué très vite. Réactions en chaîne de grenades, particules,
caisses projetées en l'air qui tournent de manière réaliste avant de
rebondir sur un Warthog dont elles tuent l'artilleur... Très amusant,
http://www.grospixels.com/site/animation1.php
Page 4 sur 8
Grospixels
064/03/Sunday 20h49
mais lourd en mathématiques.
- Les scripts ("quand Gordon finit de pousser sa tondeuse à gazon
dans l'accélérateur de particules, tout commence à exploser").
- L'IA. Elle dépend souvent de scripts pour alléger les calculs, mais
dans les jeux de stratégie ou de tactique, elle tente de prédire ce que
le joueur va faire pour décider de ses actions (efficace, mais
particulièrement gourmand en ressources).
- Si le jeu utilise cette technique pour camoufler les temps de
chargement, le transfert de données graphiques depuis le disque vers
la RAM (streaming).
- Si le jeu est multijoueurs, le trafic réseau.
Sans oublier que pendant ce temps-là, diverses autres choses plus ou
moins indépendantes de l'affichage ont lieu : le son, par exemple.
Une fois tout cela fait, le programme doit encore interpréter les
données pour rendre l'image : dans Dodonpachi, on sait qu'il faut
afficher 30000 sprites parce que les 250 vaisseaux ennemis présents
à l'écran ont décidé de vider leur réserve de munitions dans la
direction générale du joueur. Dans Burnout 3, on sait qu'il faut
afficher 10 voitures à 5000 polygones l'unité, dont une est en train de
se déformer et éjecte des étincelles (particules) dans tous les sens,
calculer les effets d'éclairage correspondants, l'anti-aliasing et le filtre
de motion blur qui est plus fort sur les bords de l'écran... Mine de
rien, cela aussi consomme du temps CPU. Au final, donc, le framerate
maximal calculé d'un jeu est 1/(t1+t2+t3), où t1 est le temps
nécessaire pour rendre et afficher une image, t2 le temps nécessaire
pour l'effacer, et t3 le temps nécessaire pour calculer tout ce qu'il
s'est passé entre une image et la suivante. Mais le framerate maximal
perçu est min(f, 1/(t1+t2+t3)), où f est la fréquence de
rafraîchissement de l'écran.
Delta
"Mais, monsieur," vous entends-je
penser suite à la lecture de la section
précédente.
"Toute
cette
consommation de temps, selon ce que
je fais dans le jeu, elle ne doit pas
être constante, si ?" Et vous avez tout
à fait raison. Considérons les deux
exemples suivants, tirés de Halo :
- Scène 1. Le Master Chief est seul
dans une petite salle, face à un mur,
la tête baissée. Il ne fait rien.
Imaginez si vous voulez qu'il a été
mauvais élève et que la maîtresse l'a
envoyé au coin avec un bonnet d'âne
kaki à visière dorée. C'est un bourrin,
le Master Chief, pas un premier de la
classe.
- Scène 2. Le Master Chief est dans New Mombassa, sur un pont
suspendu à perte de vue, en train de résoudre à lui tout seul, depuis
son tank, tous les problèmes de surpopulation des Covenant pour les
10 générations à venir. Un bus vient d'exploser sous l'effet d'une
grenade à plasma, projetant en l'air un Ghost qui malgré tout
http://www.grospixels.com/site/animation1.php
Page 5 sur 8
Grospixels
064/03/Sunday 20h49
continue de tirer. Un Banshee est en train de se crasher et le cadavre
de son pilote d'atterrir sur les restes du bus. Dans le lointain, un
Scarab sème la terreur avec son canon à plasma lourd. Une musique
vient de démarrer, et Cortana explique qu'il faudrait que le Master
Chief se bouge le popotin, parce que c'est pas tout ça, mais il y a des
gens qui se font tuer plus loin dans le niveau et le sergent Johnson va
bientôt tomber à court de vannes.
Cela ne vous surprendra pas d'apprendre que la seconde scène prend
beaucoup plus de temps à rendre que la première. On se heurte alors
à un problème épineux : si rien n'est fait pour l'empêcher, le
framerate d'un jeu varie. En quoi est-ce un problème ? Et bien à vrai
dire, sur micro, pas. Le jeu doit tourner sur un nombre incroyable de
configurations distinctes, qui produiront chacune des framerates
différents dans des situations différentes (par exemple, une machine
avec une carte graphique moins puissante mais un meilleur
processeur traite les variations plus vite mais demande plus de temps
de rendu)... Bref, c'est un casse-tête insolvable, alors la plupart du
temps on ne limite rien et on laisse les hardcore gamers qui viennent
de claquer 1000 euros dans deux cartes vidéos state-of-the-art
admirer leurs pointes à 400 FPS dans Far Cry (même si, comme
expliqué plus haut, ça ne sert à rien parce qu'aucun moniteur ne
rafraîchit à 400 Hz).
Mais sur console, on a l'avantage de savoir exactement sur quel
hardware le jeu tournera. Alors on peut se permettre quelques petites
folies, comme par exemple garantir un framerate constant dans tout
le jeu. Cela a l'avantage (deux avantages en réalité, mais le second
est une pomme empoisonnée -- j'y reviendrai un peu plus tard)
d'augmenter encore la fluidité apparente du jeu. En effet, l'oeil
humain est très sensible aux variations, et un jeu qui tourne tout le
temps à 30 FPS paraîtra plus fluide qu'un dont le framerate est plus
élevé en moyenne mais varie sans cesse (par exemple, entre 15 et 60
FPS).
Yes limit
Pour ce faire, il faut imposer au framerate une limite inférieure et une
limite supérieure, les plus proches possible l'une de l'autre.
Te presse pas, y'a pas le feu
Imposer une limite supérieure (pas plus de n FPS) est trivial. En
effet, si le travail a été terminé en avance, il suffit d'attendre un petit
peu pour coller au planning. Sur console, on utilise une astuce de
programmation appelée synchronisation verticale, ou VSync (rien à
http://www.grospixels.com/site/animation1.php
Page 6 sur 8
Grospixels
064/03/Sunday 20h49
voir avec un quelconque boy's band -- ça veut dire Vertical
Synchronization), où l'on ne permet au programme d'afficher une
nouvelle image qu'au début du rafraîchissement de l'écran. Autrement
dit, tous les 1/60 secondes en NTSC (1/50 en PAL). Lorsque le
programme veut afficher une nouvelle image, il doit attendre la
prochaine "fenêtre de tir". Ceci a pour effet de limiter le framerate
calculé du jeu : elle est au plus égale à la fréquence de
rafraîchissement de l'écran.
On peut également décider de limiter le framerate en créant une
fenêtre de tir artificielle (c'est ce qui est fait sur micro, où les
fréquences de rafraîchissement des écrans ne sont pas les mêmes
d'une machine à l'autre et où l'on ne peut donc pas compter sur le
VSync). C'est à peine plus compliqué : on mesure le temps écoulé
depuis la dernière image affichée, et s'il est inférieur au délai minimal
entre deux images (autrement dit 1/fr, où fr est le framerate
maximale désiré), on attend.
Chewie, il me faut cette image, et il me la faut maintenant !
C'est la limite inférieure (au moins n FPS) qui pose problème. Là, il
n'y a pas vraiment de secret, il faut optimiser le jeu jusqu'à obtenir
ce qu'on veut en toutes circonstances. "En toutes circonstances"
signifie ici "dans la section la plus chargée du jeu". En effet, comme
expliqué dans "Delta", si l'on prend la pire situation possible dans le
jeu (du point de vue de la consommation de ressources) et qu'on se
débrouille pour que le jeu y affiche le framerate désiré, celle-ci sera
fort logiquement facile à atteindre pendant le reste du jeu. Souvent,
c'est cette limite inférieure qui dictera la limite supérieure : si l'on
n'arrive pas à garantir 60 FPS constantes, le jeu sera en 30 (n'oubliez
pas, un framerate stable est préférable à un framerate élevé).
Se débrouiller avec un framerate variable
Evidemment,
toute
cette
histoire de limite inférieure,
c'est bien beau mais ce n'est
que de la théorie. En pratique,
les joueurs trouveront toujours
un moyen de trouver des
situations pires que ce que les
développeurs ont prévu. Le
framerate finira par chuter, et
à ce moment-là, il faudra
décider quoi faire.
Exclusif : dans cette section, vous apprendrez (même si vous devez
déjà avoir des doutes) pourquoi les jeux PAL sont plus lents que les
jeux NTSC. Sur micro, à cause du hardware qui n'est pas identique, il
n'y a aucun moyen de garantir un framerate minimal (il y aura
toujours un blaireau avec trop de temps libre pour installer tous les
derniers jeux sur son vieux 486 qu'il garde juste pour ça depuis plus
de 10 ans). Pourtant, si vous avez joué à un jeu récent sur deux
machines différentes dont l'une est beaucoup plus puissante que
l'autre, vous aurez remarqué que malgré la grosse différence de
confort (d'un côté, ça saccade à mort), le jeu tourne à la même
http://www.grospixels.com/site/animation1.php
Page 7 sur 8
Grospixels
064/03/Sunday 20h49
vitesse (temporelle, pas hertzienne) partout. Et ça, c'est la grande
classe.
Le ralenti, c'est mal
Sur console, les développeurs
ont pendant longtemps fait un
truc très bête (et beaucoup,
surtout au Japon, continuent à
le faire) : partir de la
supposition erronée que le
hardware est rigoureusement
identique quoi qu'il arrive
(vous vous rappelez de la
pomme empoisonnée de tout
à l'heure ?), et donc qu'en
utilisant le VSync, leur console
crache 60 images par seconde
un point c'est tout. Donc,
qu'une
seconde
égale 60
images. Et d'exprimer toutes les vitesses dans leurs programmes en
fonction des images et non du temps réel. Autrement dit, des choses
comme "Le tir de l'arme principale avance d'un pixel par frame". Le
jeu étant censé tourner à 60 images par seconde (on est en pays
NTSC), cela paraît logique et acceptable. En plus, lorsque le jeu se
met a dépasser les limites de la console (il ne tient plus la limite
inférieure de framerate), il se produit un effet de ralenti assez
agréable à l'oeil (on en trouve d'assez beaux exemples dans Gradius
III sur SFC, et à vrai dire dans beaucoup d'autres jeux sur ce
support). Sauf que même sur console, il y a quelques légères
variations dans le hardware. Surtout une en particulier : en Europe,
les télévisions (PAL) sont en 50 Hz. Elles affichent 50 images par
seconde. Vous vous rappelez du VSync ? Et bien il s'applique
toujours... Et là, c'est le drame. "Le tir de l'arme principale avance
d'un pixel par frame". Au Japon ou aux USA, cela signifie qu'il avance
d'un pixel tous les 1/60e de seconde. En Europe, c'est tous les 1/50e
de seconde. Résultat, en NTSC le tir avance de 60 pixels par seconde,
et en Europe de 50 pixels par seconde : la version JP/US est donc
20% plus rapide !
Page suivante (2/2) >
http://www.grospixels.com/site/animation1.php
Page 8 sur 8