Mon FPS est plus grand que le tiens

Votre jeu est-il en 60 FPS ou en 30 ? Ou bien c’est pas grave car il est en 1080p ? Est-ce que 720@60 est mieux que 1080@30 ? Et d’ailleurs, c’est quoi ça, au fait, un FPS ? First Person Shooter c’est ça ? Qu’est ce que tout ça vient faire dans des débats sur l’image la plus belle et la plus fluide. À moins que…

(à la fin de l’article, vous trouverez de quoi jouer avec les FPS)

On respire un coup

À longueur de forum ou de fil Facebook, en commentaires dans les news du plus célèbre au plus obscure des sites de jeu vidéo, les débats font rages pour savoir quel jeu à la plus belle image, le plus beau rendu. Au point qu’il est difficile parfois de savoir si le jeu offre une expérience ludique intéressante.

L’un des termes, dégainé rapidement, est l’argument du FPS, Frame Per Second. À la décharge des commentateurs effrénés, ce ne sont pas eux qui ont commencé, mais bien le service marketing de certains gros hits ou de techno qui ressortent régulièrement que si tu n’as pas ton gros FPS, t’es rien qu’un produit dérivé de F2P en Flash qui spam les amis Facebook.

Vous voyez la bataille faire rage, mais vous n’êtes pas très sûr de vous ? Vous ne voulez pas engager le bout de l’orteil dans une suite de commentaire où vous vous feriez traiter de n00b sur sept générations ?

Voici quelques éléments pour vous aider à ne pas entrer dans le débat, à prendre un peu de hauteur ou de recul, selon votre choix. Ou plutôt, d’y aller à votre vitesse.

Frame Per Second

Le principe est simple : combien d’images est-ce que la machine affiche en une seconde lorsque vous jouez ? Cette mesure qui ne sert pas seulement à bomber le torse est importante car elle donne une idée (partielle) de la fluidité perçue. Et de cette fluidité va découler l’immersion, la réactivité du jeu et une partie du plaisir de jouer.

L’illusion du mouvement par une suite d’images profite de notre vision imparfaite pour faire bosser notre système oculaire et surtout le cerveau qui est derrière afin de donner l’illusion du mouvement. Ce n’est pas différent du cinéma et ça se fait tout seul. Il n’y a pas besoin de forcer.

À combien c’est bien ?

C’est très variable. Le cinéma ordinaire est normalisé à 24 images par seconde, les télévisions française en SECAM à environ 25 images par seconde et américain/japonaises à 30 images par seconde. Les écrans cathodiques correspondants étant rafraîchis respectivement 50 et 60 fois par seconde (tout simplement car le courant à la prise est à cette fréquence, c’était juste plus simple).

Ça suffisait bien. Alors qu’apporte plus d’images : une plus grande fluidité, moins d’effort sur le système oculaire et donc moins de fatigue. Globalement, c’est plus agréable.

De plus, les images de synthèses et digitales sont plus crues et plus nettes qu’une image filmée. Les mouvements étant moins lissés par le flou, les sauts entre les images se voient un peu plus. Plus d’images permettent de garder une image générée propre et nette sans avoir recours à des procédés de flous de mouvement. C’est beau, c’est net, c’est précis.

Les écrans cathodiques, c’est dépassé

Cette phrase, qui fait hurler les amateurs de retro gaming par amour du pixel baveux, sous entend que les problèmes de rafraîchissement, initialement dus au balayage d’un faisceau d’électron sur la surface du tube, n’aurait plus court.

Il se présente cependant toujours, bien que différent. Mais l’image doit bien être rafraîchie, et chaque pixel change de couleur à un moment où à un autre. Pour le confort de la perception, mieux vaut que l’image soit cohérente lors du changement.

Cette cohérence est assurée par la synchronisation verticale ainsi que par l’adéquation du nombre d’images générée avec la vitesse de rafraîchissement de l’écran dans sa globalité (c’est-à-dire que l’on fait abstraction de la technique physique de l’affichage ici).

De la cohérence avant tout

Votre esprit affûté a sans nul doute remarqué que pour les US, 30 était la moitié de 60 et que pour la France, 25 était la moitié de 50 (à vrai dire, la division par 2 fonctionne de la même manière dans les deux pays… ce n’est pas le sujet).

C’est la partie adéquation. Le nombre d’image généré comme une division entière du nombre de rafraîchissement est une bonne idée. En effet, si il y a plus d’images (finales) générées que de rafraîchissements, il y aura des images en trop qui au mieux ne serviront pas, au pire étaient calculées pour facilité le travail d’interprétation du spectateur. S’il y a moins d’images mal réparties, il peut y avoir un effet de saccade.

Par exemple, 2 images sont générées pour 3 rafraîchissements. Au mieux, 1 image sera affichée pendant un rafraîchissement et les 2 autres pendant un autre rafraîchissement. L’alternance d’une image deux fois plus longue que la suivante va être désagréable.

Cet effet, un peu moins prononcé, était très visible avec les magnétoscopes qui transcodaient le NTSC à 60 Hz vers le PAL à 50 Hz. Particulièrement dans des séquences avec une image de décor se déplaçant horizontalement ou verticalement pendant quelques secondes.

Et de la synchronisation

La partie synchronisation est celle qui attend que le système d’affichage signal qu’il a fini son rafraîchissement et va en commencer un nouveau pour présenter au système une nouvelle image toute prête.

(petite aparté ici : j’évoque les systèmes affichages courant et majoritaire, il y a des exceptions dont je pourrai parler une autre fois)

Cette partie, lorsqu’elle est ignorée (ou désactivée) permet à un système de ne plus être esclave du taux de rafraîchissement. Le prix à payer est un méchant effet de déchirement horizontal de l’image : la partie haute et la partie basse de l’image ne correspondent pas. Pire, l’endroit de la déchirure peut varier d’une image à l’autre.

Mais moi je veux du 50 !

C’est vrai ça ! Pourquoi parler de 60 FPS, ou 30 FPS, alors que le rafraîchissement des télévisions françaises est à 50 FPS ?

Car il ne l’est plus obligatoirement depuis un bout de temps maintenant. Sur la fin de l’ère cathodique, les écrans télé étaient déjà capable en grande partie de se rafraîchir à 50 Hz ou 60 Hz. Les moniteurs d’ordinateurs eux, étaient capables d’afficher à plusieurs taux. Mais pas n’importe quel taux tout de même.

C’est encore plus vrai avec l’ère des écrans numériques/plats.

Bon mais alors pourquoi 60 et pas 50 ? Par adéquation au standard américain j’imagine. D’un point de vue jeu vidéo, cela signifie qu’il y a moins de temps pour le rendu d’une image. Pour la perception visuelle, 60 est meilleur que 50. Aujourd’hui, l’important est surtout de respecter la cohérence du système de rafraîchissement et de rester constant.

60 Hz est d’ailleurs ce qui va sortir de votre console dernière génération sur votre télé pas trop vieille. Lorsque vous jouez sur un ordinateur personnel, la fréquence peut être différente.

La constance

On l’a déjà vu, caser 2 images dans 3 rafraîchissement, ça donne quelque chose de désagréable. Plus qu’un FPS élevé à tout prix, l’importance primordiale est de maintenir un FPS constant. Et les variations seront plus désagréables, pour une image synchronisée à l’affichage, que le FPS sera important.

Un jeu qui oscille entre 60 FPS et 30 FPS amènera une forte impression de saccade si le jeu est dynamique.

D’ailleurs, si beaucoup d’observateurs d’écran ne font pas la différence entre du 60 FPS ou du 30 FPS (si si, même des professionnels), à peu près tout le monde détecte l’inconstance.

Les variations de FPS ont qui plus est des effets de bords. La simulation physique la plus simple qui soit est mise à mal par une variation. En effet, le jeu doit calculer la position de chaque élément à l’écran pour l’image suivante. Pour les objets en mouvements, il faut donc prévoir une position cohérente avec sa vitesse simulée. La position étant une fonction du temps, les calculs se font en choisissant quel sera le temps passé entre l’image affichée actuellement et la suivante en train d’être calculée.

Le moyen le plus simple pour faire ce choix est de regarder l’historique. Et généralement pas plus loin que le dernier temps obtenu : le temps entre les deux dernières images affichées.

C’est physique

Si ce temps était d’environ 16 ms (temps entre deux images à 60 FPS) alors les calculs de déplacement vont positionner les objets tels qu’ils devraient l’être 16 ms après l’image actuellement affichée.

Oui mais… mais… si le calcul de cet image est plus long. Oh pas de beaucoup, il suffit d’avoir dépassé et d’avoir pris 17 ms pour descendre à 30 FPS (pourvu que la synchronisation verticale soit respectée). Et bien la nouvelle image affichée présentera des objets ayant parcouru une distance pendant 16 ms… mais après une attende de 32 ms !

Autrement dit, les objets auront instantanément vu leur vitesse divisée par deux.

À partir de là, cela peut devenir catastrophique : le programme doit-il considérer que c’était une erreur et faire comme si de rien n’était, garder un temps d’intervalle de 16 ms ? Ou bien se caler sur 32 ms ? S’il fait le choix de 32 ms mais que le calcul de l’image revient sous les 16 ms, les objets vont alors voir leur vitesse être multipliée par 2 sur cette image.

Et l’oscillation entre les deux accentue l’effet de saccade.

Pour ces raisons, certains jeux bloquent artificiellement leur FPS à plus bas qu’ils ne pourraient tourner (généralement 30 FPS, très courant sur consoles). D’autres choisissent de tourner le plus vite possible et proposent de désactiver la synchro, pour éviter le côté « loupé de peu ». Certains réintègre une passe de simulation physique en cas de calculs trop longs, avec le risque que ce soit justement la physique qui soit coûteuse et donc entrer dans un cercle vicieux.

Les techniques sont nombreuses et variées.

Quoiqu’il arrive, 16 ms, c’est court, très court, et faire tourner un jeu chargé en éléments (par rapport à son époque) est une décision de projet qui demande une attention de tous les instants et une volonté éditoriale.

Et maintenant, on s’amuse

Je vous propose un petit programme pour vous amuser avec les FPS.

 

Que la couleur soit !

Après avoir parcouru un tout petit morceau des débuts de l’affichage graphique des jeux vidéo dans l’article précédent, je continue ma vision personnelle de ce voyage.

Nous avions laissé les jeux vidéos sur des machines principalement dédiées à l’affichage de texte en noir et blanc. Ajoutons dans cet article un peu de couleurs.

La couleur est un vaste problème. Le premier étant que la grande majorité des moniteurs n’a pas de couleurs. C’est une époque de domination de l’écran à affichage monochrome, vert ou ocre. Mais cela existe, particulièrement pour les ordinateurs dits familiaux.

Le problème côté informatique est que la couleur est une information supplémentaire et qu’une information, on l’a vu dans l’article précédent, cela doit se stocker et donc nécessite de la mémoire.

Extrait de publicité GAI

Extrait de publicité DAI. Scanné par Frédéric Goset pour le site Abandonware Magazines

Mais la couleur est attendue, elle est même mise en avant dans les articles qui présentent de nouvelles machines. Combien de couleurs, choisies dans une palette à combien de possibilités ?

Pour offrir de la couleur en n’augmentant pas drastiquement la mémoire nécessaire, les astuces sont nombreuses et très diverses. Certaines machines n’admettent un changement de couleur que caractère par caractère. D’autres font un compromis entre taille du pixel et couleur.

La série de Amstrad CPC, au milieu des années 80, fonctionne comme cela : il y a trois mode d’affichages appelés avec grande originalité les modes 0, 1 et 2. Tous ces modes offrent le même nombre de lignes graphiques (200) mais diffèrent par leur nombre de pixels en largeur et le nombre de couleurs simultanément disponibles.

En fait, chaque ligne dispose de 640 bits de données. En mode 2, le plus précis, chaque bit représente un pixel, et la définition est donc de 640 par 200. Cependant, un bit ne code que deux informations, 0 et 1, soit deux couleurs différentes. Le CPC permet d’allouer à 0 une couleur et à 1 une autre couleur, les deux choisies parmi une palette prédéfinie.

En mode 0, chaque pixel est représenté par 4 bits. Cela donne un choix de 16 couleurs choisies parmi la même palette. Par contre, le nombre de pixel en largeur fait chuter la définition à 160 par 200.

Le mode 1 est le mode intermédiaire, et le mode par défaut dans lequel la machine s’allume : 320 par 200 et 4 couleurs.

Haute définition monochrome ou arc-en-ciel en gros pixels, ce type de choix était assez standard pour les machines de cet époque, lorsqu’elles offraient ce choix.

La couleur sur ce système n’est pas donnée directement mais passe par un concept de palette et de crayons. La palette est l’ensemble des couleurs que l’ordinateur est capable de générer vers l’affichage. 8, 16, 32 ou même 4096, cela dépend. À chaque crayon, dont le nombre est moins grand, est ensuite assigné une de ces couleurs.

Le nombre de crayons va déterminer le nombre de couleurs affichables simultanément à l’écran (hors astuce). Leur nombre réduit permet d’utiliser peu de mémoire tout en permettant d’utiliser une palette plus étendue.

Palette de 27 couleurs (combinaison des possibilités avec les composantes Rouge Verte Bleue à des valeurs nulles, moyennes, pleines). C'est la palette de l'Amstrad CPC.

Palette de 27 couleurs (combinaison des possibilités avec les composantes Rouge Verte Bleue à des valeurs nulles, moyennes, pleines). C’est la palette de l’Amstrad CPC.

Mais la stratégie des Amstrad CPC n’est pas la seule. Une autre consiste à se reposer sur la méthode des caractères semi graphiques déjà évoqués précédement et de donner aux blocs une couleur d’écriture (bloc allumé) et une couleur de fond (bloc éteint).

Ainsi, le ZX Spectrum code ses attributs de couleurs sur une grille de 32 par 24 qui correspond à son nombre de colonnes et lignes en mode texte. Dans chacune des cases de cette grille se trouve une couleur de fond et une couleur d’écriture. Le choix de couleur se fait sur une palette de 8 couleurs en mode soit normal, soit brillante, soit 16 teintes (en fait, 15, car le noir mat ou brillant se rend de la même façon). Chaque couleur peut donc être codée sur 4 bits, soit 8 bits pour les deux couleurs.

Cela donne 768 octets pour coder toutes les couleurs, ce qui est très acceptable à l’époque et très en dessous des 24ko qui auraient été nécessaire pour coder la possibilité de 16 couleurs sur chacun des pixels de la résolution graphique de 256 par 192.

Ce compromis provoque un artefact graphique bien reconnaissable. Comme les couleurs choisies sont forcément les mêmes pour un bloc graphique de 8 par 8 pixels, il arrive que la couleur d’un décors « bave » sur un élément en mouvement, ou inversement.

Exemple d'Attribute/Color clash (illustration du domaine publique disponible sur Wikipedia)

Exemple d’Attribute/Color clash (illustration du domaine publique disponible sur Wikipedia)

Je vous conseille d’aller jeter un œil à cette page avec des illustrations qui gèrent cet artefact.

Au fur et à mesure des générations, le nombre de couleurs pouvant être générées par la puce graphique va augmenter. Le nombre de couleurs pouvant être affichées simultanément aussi.

Progressivement vont être possible des modes marketés « vraies couleurs » où la palette est vaste et où toutes les couleurs sont affichables simultanément. Les modes où chaque pixels est codé sur 16 bits, pour un total de 65536 couleurs puis sur 24 bits, pour un total de 16 milions (et quelques) couleurs.

À ce stade là, la compétition entre carte graphique s’était déplacée sur un autre tableau dont je parlerai plus tard : la 3D.