Ce document se concentre sur la sortie vidéo de la console : vers quelles cibles, avec quelle qualité et quelles caractéristiques, selon quelles modalités ? Même si l'essentiel des discussions portera sur la connexion vidéo à une télévision, on pourra aussi étudier d'autres supports, tels que les moniteurs d'ordinateurs, les vidéo-projecteurs, les lunettes 3D, et tout ce que l'on pourra imaginer ...
[se référer aussi à la section homologue de Clonic Tree]
Trois standards :
Deux fréquences de rafraichissement :
Bien que de plus en plus de téléviseurs soient compatibles 60 Hz et NTSC, les constructeurs de consoles préfèrent utiliser en Europe le PAL à 50 Hz pour toucher un plus large public, bien que les jeux soient nativement prévus pour s'exécuter en NTSC. Ce qui pose le problème des conversions, souvent bâclées dans chaque jeux faute d'avoir été prévue au niveau de la machine elle-même (cf Le 26ème Virus Informatique, juin 2004, p.20)
En la matière, peut-être que le mode bâtard PAL 60 Hz serait le meilleur choix (sous réserve que le téléviseur supporte le 60 Hz, bien évidemment !).
Signalons enfin un nouveau standard, la TVHD (pour Télévision Haute Définition), qui, avec ses 1 050 lignes, supplantera la télévision classique et ses 625 lignes, mais qui nécessitera que toute la chaîne, de la production d'images à leur restitution (caméra, traitement de l'image, émetteur, téléviseur, etc.) soit mise à jour afin de supporter ce nouveau standard de qualité. Cela prendra du temps (arrivée prévue dans les années 2 010 !)
Des connectiques (vues depuis la console) :
Pour commencer, il faut préciser que, au moment de la définition des standards vidéo, le cas d'utilisation retenu était celui où il y avait beaucoup plus de consommateurs d'images (télévisions par exemple) que de producteurs (consoles de jeux par exemple). Le choix naturel fut donc de simplifier autant que possible la réception et le décodage des images, quitte à compliquer leur production.
L'autre grande contrainte structurante était que l'élément critique de la chaîne vidéo est la bande passante, de telle sorte qu'il faille trouver des formats d'encodage aussi économes que possible, même si souvent cela oblige à faire des concessions sur la qualité des images.
Beaucoup des producteurs d'images (comme les consoles) génèrent du RGB, pour Rouge(Red)-Vert(Green)-Bleu(Blue), trois grandeurs qu'ils manipulent nativement. Notamment pour les besoins du transport, ces informations peuvent être codées en un autre trio appelé YCrCb ou composant.
Cet autre trio est formé de la luminance (Y = a.R + b.G + c.B, qui transmet l'intensité lumineuse, et qui se calcule donc comme la somme pondérée de R, de G et de B, avec a, b, c étant trois constantes) et de deux autres canaux (Cr = R - Y et Cb = B - Y, qui transmettent la couleur).
Ce choix permet de diminuer la bande passante nécessaire au transport des images et de mieux résister aux distortions de gain (une composante plus amplifiée que les autres se remarque plus en RGB qu'en YCrCb), tout en conservant exactement les mêmes informations que celles stockées dans le format RGB, car avec Y, R-Y et B-Y on peut facilement déduire R, G et B (bijection que l'on peut représenter sous forme matricielle) :
R = Y + CrG = (1-a-b) * Y - a/b * Cr -c/b * CbB = Y + CbPour être plus précis, notons que le signal Y ne décrit pas exactement la luminance, puisque dans la plupart des cas il résulte d'un traitement de gamma-correction non-linéaire : l'oeil humain ne percevant pas les couleurs (longueurs d'onde) uniformément (il constitue un filtre), il convient d'appliquer le filtre inverse pour un meilleur rendu, ce qui correspond au post-traitement de la correction gamma, négliglable en première approximation.
S'il est encore nécessaire de diminuer les besoins en bande passante de la transmission vidéo, les deux canaux Cr et Cb peuvent être mélangés dans un seul, appelé chrominance. Ce procédé est utilisé par le S-VIDEO, qui au lieu de transmettre trois canaux comme pour le RGB ou le YCrCb, en transmet seulement deux, la luminance et la chrominance, au prix d'une certaine dégradation (assez peu sensible) de la qualité des images.
Chacun des signaux Cr et Cb se trouve temporellement compressé de manière à ne garder que 50% de sa taille, et Cr et Cb sont alternativement transmis sur le canal partagé chrominance (multiplexage temporel). A la restitution, le traitement inverse permet de les séparer.
Pour diminuer encore la bande passante nécessaire, on peut mélanger les deux signaux précédents, luminance et chrominance, en un seul, appelé composite. La diminution de la qualité est dans ce cas assez importante, car luminance et chrominance ne peuvent être complétement séparées par le récepteur, du fait du recouvrement de leur spectre.
Le format composite se décline selon trois grandes normes : le NTSC (format américain) , Le PAL (Europe) et le SECAM (la France et quelques pays). Ces différents systèmes permettent de faire passer un maximum d'informations en un minimum de bande passante, en tâchant de minimiser la dégradation du signal.
Au-delà de la suite des pixels formant l'image, il est nécessaire de créer les signaux de synchronisation horizontale (pour indiquer à la télévision quand passer à la ligne) et verticale (pour indiquer à la télévision quand redessiner une nouvelle image), et ceux pour gérer les bandes noires qui entourent l'image (blanking et les questions d'overscan). Cela se fait communément à l'aide d'une ou plusieurs horloges (oscillateurs, ex : quartz) qui pilotent l'ensemble du circuit de conversion et, partant, le dispositif de rendu, en l'occurence la télévision.
A l'autre bout de la chaîne, la télévision effectue les traitements inverses du générateur d'images, et utilise les informations RGB décodées sous forme de tension pour dévier en accord le faisceau d'électrons, afin d'illuminer les cellules colorées et créer les couleurs et les images.
Dans l'optique de faire une console de jeu, il est proposé de tester une sortie graphique de type S-VIDEO, qui semble constituer une solution plus efficace que le composite :
Il faut savoir que la prise Peritel peut véhiculer aussi bien du signal composite qu'un signal où luminance et chrominance sont séparés [Plus d'infos]. On aurait dans ce cas "seulement" les signaux suivants à gérer sur la Peritel :
A noter que le choix le plus tentant aurait été d'utiliser la prise Peritel pour véhiculer directement les signaux RVB, qui sont produits nativement par la console. Hélas, virtuellement aucune télévision actuelle n'accepte du RGB en entrée. Reste donc la possibilité du S-VIDEO, qui supplante nettement le composite. La question est dès lors : est-ce que toutes les télévisions supportent de recevoir par la prise Peritel chrominance et luminance séparées ? Ce n'est pas impossible, car cela devrait être facile à faire dès lors qu'elles acceptent le composite, ce qui est le cas général.
En tout état de cause, deux prises, transmettant le même signal logique, sont envisageables : la Peritel et la S-VHS ou Ushiden. Comme la première pourrait prêter à confusion (des utilisateurs disposant d'un téléviseur ne supportant pas le S-Video pourraient s'y tromper), il est sans doute préférable de privilégier la prise S-VHS, qui n'est pas ambigüe : quand on a la prise, on est sûr que le téléviseur est compatible.
Le son pourra être véhiculé avec une connectique séparée, telle que les deux prises RCA classiques, pour la stéréo.
Comme notre console se voudrait, idéalement, modulaire, on pourrait imaginer qu'elle supporte aussi plusieurs modes de sortie vidéo (ex : PAL ou NTSC), plusieurs fréquences de rafraîchissement (50 ou 60 Hz), avec une connectique S-VHS et RCA, ou Peritel. Néanmoins, les préconisations évoquées précédemment seront retenues, et les variations proposées n'apparaîtront probablement que si le besoin s'en fait réellement sentir.
L'image affichée par un téléviseur est un rectangle de hauteur V et de largeur H. Le format de l'image est le rapport H/V. La normalisation internationale définit les formats suivants :
Des expériences montrent que le spectateur a une impression de réalisme plus grande avec une image de format plus allongé, C prenant une valeur comprise entre 5/3 et 2. C'est ainsi que le CinémaScope, puis les nouveaux standards TV, ont adopté la valeur 16/9.
Du fait de contraintes liées aux tubes images à balayage (cadrage, synchronisation et retour du spot), l'image visible a une définition moindre que celle transmise ; soit D le nombre total de lignes dans la période d'image et Dv le nombre de lignes visibles ; pour la télévision, on a : Dv = 0,922.D (par exemple : pour D = 625, on obtient Dv ~ 575)
Le principe d'affichage des images de télévision est l'entrelacement de trame, cela consiste à ne restituer qu'une partie de l'image à chaque champ affiché (trame) ; la restitution totale de l'image se fait ainsi sur plusieurs trames. Dans le cas de la télévision, l'entrelacement est d'ordre 2, c'est à dire que l'on affiche successivement une trame contenant les lignes paires puis une trame contenant les lignes impaires. Pour une bande vidéofréquence donnée, l'image à D lignes entrelacées est de meilleure qualité qu'une image à D' = D/SQR(2) lignes non-entrelacées, ce qui justifie l'entrelacement de trames. On admet, sur la base d'essais, que la qualité d'une image à D lignes entrelacées est la même que celle d'une image à D' (~0,6 à 0,7.D).
La problématique, comme on l'a vu, est assez complexe : nativement, une console de jeu disposera en interne d'informations RGB (séparation rouge-vert-bleu), stockées dans sa mémoire vidéo. Donc le format graphique de sortie le plus naturel de son point de vue sera cette information RGB (qui est numérique), assortie d'informations de synchronisation, afin de piloter le dispositif de sortie, typiquement l'écran (envoi des messages de fin de ligne et de fin d'écran, appelées aussi HSYNC et VSYNC).
Hélas, les télévisions classiques prennent leurs informations en analogique encodé (non plus des valeurs binaires, mais des grandeurs physiques continues, mélangées avec les règles déjà expliquées), si bien qu'il est nécessaire, pour une console, de convertir ses signaux si elle souhaite s'afficher sur les téléviseurs. Cette conversion n'est pas immédiate à réaliser.
La solution de facilité est de recourir à un circuit intégré prenant en charge, de lui-même, la conversion. En dehors de la frustration de devoir incorporer un circuit "tout fait" dans la console (à relativiser puisque par exemple on pourrait raisonner ainsi pour le processeur principal alors qu'il n'est certes pas envisageable de concurrencer les fondeurs), le seul vrai souci est le prix de ces composants, qui n'est pas négligeable à l'échelle du coût de revient escompté d'une console.
La fréquence du circuit de conversion est en autres limitée par celle de la lecture de la mémoire vidéo (RAM) et par celle des convertisseurs "numérique vers analogique" (DAC), d'où le terme de RAMDAC utilisé pour les cartes vidéo. Le circuit que l'on évoque dans cette page correspond d'ailleurs à une carte vidéo élémentaire (sans accélération d'aucune sorte pour ce GPU primitif).
Pour combler les puristes souhaitant tout faire par eux-mêmes, remarquons que le dispositif de conversion constitue un tout indépendant du reste de la console, si bien qu'il est tout-à-fait envisageable de commencer par s'aider d'un circuit intégré avant, s'il en est décidé ainsi, de lui substituer un circuit maison, censément moins cher et mieux adapté.
Ce sous-circuit, cette carte vidéo qui ne dit pas son nom, pourrait aussi, grâce à son processeur embarqué (GPU), prend en charge matériellement (du point de vue du processeur central) une plus grande partie du rendu que la simple conversion finale vers le téléviseur. Ceci d'autant plus qu'il peut nous être aisé de le surdimensionner pour prendre un processeur semblable au processeur principal (cela évite d'avoir à se familiariser avec trop de processeurs différents), et que de toute façon ce que ne fera pas l'un, l'autre devra le faire.
On pourrait ainsi imaginer au niveau du circuit vidéo, comme évoqué, une correction gamma, de l'anti-crénelage plein écran (FSAA, full screen anti-aliasing), voire de communiquer entre CPU et GPU par un langage de plus haut niveau que le simple envoi de pixels : le CPU pourrait transmettre des primitives que le GPU se chargerait d'exécuter (ex : au lieu de transmettre tous les pixels d'un cercle, seule les informations de type centre, rayon et couleur transiteraient par le bus graphique, ainsi considérablement désengorgé), à la manière d'OpenGL par exemple.
La question connexe est le transfert des données au GPU (ex : pour la 2D, images, pour la 3D : géomètries et textures), qui n'est pas obligé d'avoir lieu sur le bus central et de requérir des traitements de la part du CPU principal. On peut ainsi concevoir un bus graphique reliant, à la manière d'un DMA, les tampons de lecture d'un contrôleur de stockage à la mémoire vidéo embarquée.
Enfin, être à même de gérer correctement au niveau système (c'est-à-dire de la console, uniformément, et non au niveau de chaque jeu) les informations de fréquence de rafraîchissement (50 ou 60 Hz) serait un plus, que les consoles commerciales contemporaines n'ont toujours pas réussi à surmonter dans tous les cas.
Si vous avez des remarques à formuler, ou si vous disposez d'informations plus détaillées ou plus récentes que celles présentées dans ce document, si vous avez remarqué des erreurs, oublis, ou points insuffisamment traités, ou si vous avez envie d'apporter une aide, aussi petite soit-elle, envoyez-nous un courriel !