Tout ce que vous avez toujours voulu savoir sur les Hertz sans jamais oser le demander

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 grosso-modo ceci :

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 !