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 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. Laissez-moi 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 :
- 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 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,
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 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 à
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 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) >
