Il s'agit de la plus belle opération de FUD depuis un bout de temps.
OpenGL a existé des années avant Direct3D, le pendant d'OpenGL sous DirectX, mais il n'a jamais décolé dans l'industrie du jeu video. Les raisons sont multiples :
Tout d'abord OpenGL n'est pas un système qui permet facilement le rendu 3D temps réel, ca n'est pas sa vocation. OpenGL est une bibliothèque graphique de gestion de rendu. La première chose que l'on fait quand on écrit un programme OpenGL est de définir quelle sera la qualité du rendu, en d'autres termes quelle précision de calcul on veut. Cette option va de GL_Default jusqu'à GL_Nicest.
OpenGL es un système ouvert dans tous les sens du terme. Notamment il est très facile d'y ajouter carte par carte des extensions spécifiques. Or très peu de cartes graphiques grand public, et même très peu de consoles de jeux sont exploitable dans le cadre d'un jeu video moderne sans faire appel massivement à ces fonctions étendues. Lesquelles sont évidement non portables, ou tout du mois spécifiques à certaines familles de puces graphiques.
OpenGL gère l'ensemble du pipeline de rendu graphique de la carte vidéo. Ce qui est très bien pour un rendu de précision, mais qui pose un véritable problème dans le cadre d'un PC de bureau. Si vous lancez une application OpenGL, elle va mettre la main sur tout un pipeline de rendu. Donc si vous lancez une seconde application OpenGL, soit vous avez une carte graphique professionnelle avec Autant de pipeline que nécessaire, soit la seconde application ne sera pas accélérée 3D et passera en mode pur soft. Sous Direct3D il est tout à fait possible d'accélerer simultanément plusieurs rendus, car c'est le système et non l'appli qui fait le dispatch des traitements. C'est pour celà que sous Vista et 7 tant que l'on a pas désactivé Aero, les performances OpenGL sont assez limitée. Bon Microsoft a sorti un patch qui fait que si l'appli OpenGL passe en plein écran aero va faire dodo et on a des perfs correctes, mais en fenétré c'est une catastrophe.
OpenGL ne s'occupe que du graphisme, et seulement dans la qualité voulue. Si par hasard vous vouliez vouer du son ou ajouter des éléments de calcul dans votre appli, à vous de vous démerder pour synchroniser tout çà. Dans DirectX ce sont les modules DirectInput et DirectSound qui se démerde à ne pas saturer trop en évènement le processeur pendant les phases de forte charge. Bon on fini souvent par être obligé de tricher un peu. Mais on a pas à tout faire à la main tout le temps
OpenGL comme DirectX ont subis des changements de paradigme important. Tant au niveau interne que vis à vis des langages et des méthodes de programmation. DirectX 5.0; Dirext 7.0 et DirectX 9.0 font appel à des concepts de programmation graphique suffisament différent pour que l'expérience de l'un ne soit pas utile aux autres. Néamoins c'est DirectX qui reste en tête. Tout simplement parcequ'il est nettement plus adapté au jeu vidéo...
Pour finir OpenGL a de nombreuses applications en dehors du jeu video, il ne viendrait à l'idée de personne de faire une imagerie médicale pour irradiation avec Direct3D (encore que...) Mais cette puissance à un prix, les objets OpenGL sont beaucoup plus pointus et beaucoup moins flexibles que leurs contreparties Direct3D. De fait le temps de programmation est rallongé d'autant.
Quand Microsoft a présenté la suite DirectDraw (Qui allait devenir DirectX 1.0) aux devs de jeux, il se sont foutus de leur gueule. Un moteur 3D ou 2D à l'époque ca se codait à la main et ca se lancait en DOS.
Au départ ni DirectX ni OpenGL n'ont décollé. En fait l'élément perturbateur a été 3DFX avec le Glide. API propriétaire tournée exclusivement vers le jeu. C'est là que ca a fait tilt. Microsoft a sorti un set d'instruction d'accellerations 3D sous la forme de DirectX 3 en faisant très attention à s'arranger pour que la plupart des traitements soient faciles à réaliser soit en MMX, soit en utilisant les fonctions de rendus vidéo déjà présente dans certaines cartes haut de gamme, et qui devaient se généraliser avec l'arrivée des DVD. C'est alors que ATI s'est engouffré dans la brêche avec les cartes xpert@work et xpert@play rejoint très peu après par Matrox qui ont fait des cartes de décompression MPEG-2 avec les suppléments nécessaire pour faire tourner en hard DirectX 3.0 et le draft DirectX 4. Sauf que le Glide2 poussait à la porte, DirectX 4 n'a pas duré très longtemps et directX 5 a été créé dans la foulée pour faire front face au Glide 2.
Mais au moment de la conception DirectX 5 un certain Carmack, qui pour ainsi dire avait rendu possible la 3D temps réel sur PC de salon, décidait de sortir Quake2 en OpenGL. Carmak étant le plus gros vendeur de jeux videos du moment, on a eu droit aussi bien coté glide avec des wrappers que coté ATI et Matrox avec des versions réduites à des pilotes OpenGL un peu costaud sur nos machines.
Seulement il s'agissait de Mini-Drivers, c'est à dire de pilote conçus pour faire tourner Quake 2 et rien d'autre. Pas un vrai support OpenGL.
Après quand Half Life a utilisé une version modifiée du quake engine, ca a fonctionné car les fonctions appelées étaient les mêmes. Cependant ca a transmis un vrai message aux fabriquants de cartes graphiques : il fallait faire de vrais pilotes OpenGL complet et tout. C'est le moment ou toutes les cartes graphique sun peu péchue supportaient l'ensemble de l'API OpenGL 1.2. C'est aussi à ce moment que le groupe Lokhi a fait des merveilles en termes de portages de jeux sous Linux. Leur version OpenGL du moteur d'Unreal poussait le vice jusqu'à battre le moteur Glide2 fait par les devs originaux. OpenGL avait le vent en poupe.
Et puis OpenGL 1.3 est sorti. Et là les fabriquants de cartes graphique sont éclatés de rire et se sont tournés vers Directx7 qui était beaucoup plus raisonnable en terme de puissance demandé pour un résultat correct. C'est un petit nouveau : NVidia qui est venu mettre la pagaille dans tout çà, en annonçant coup sur coup le support du transform and Lightning sur Directx7 et le support complet d'openGL 1.3 (Bon complet du tronc principal de l'ARB, toutes les extensions officielles n'étant pas supportée). La geforce va se vendre comme des petits pains. Et les autres constructeurs corrigent leur copie pour utiliser à fond OpenGL 1.3.
Mais aucun jeu majeur utilisant OpenGL 1.3 ne sortira. Les seuls jeux qui sortent et qui utilisent OpenGL sont OpengL 1.2, basé soit sur le moteur de quake 2 soit sur celui d'Half Life. Des jeux qui auraient pu être pris en charge par des mini drivers tout aussi bien (et en fait la guerre des benchs commencant, les différents fabriquants n'hésitent pas à créer des pilotes spécifiques pour tel et tel jeu en OpenGL de façon à bosster artificiellement les perfs, en rennomant l'executable quake2.exe en quack2.exe le site anandtech observe une perte de framerate de 30% sur Geforce). Le thresh Firing Squad s'en mèle pour donner un point de vue Vitesse d'affichage vs Beauté de l'affichage qui n'est pas en faveur de la beauté du tout. OpenGL 1.4 sort dans l'indifférence générale coté fabriquant. Seul les systèmes de compression de texture et l'illumination dynamique seront implémentés.
OpenGL 2.0 est une catastrophe en regard de l'industrie du jeu, seul Carmack s'en sert un peu, mais son temps est passé et Doom 3 et Quake 3 se vendent mal (pour du Carmack). Aujourd'hui encore très peu de cartes sont capables de gérer l'ensemble du tronc ARB d'OpenGL 2.0 en pur hardware.
OpenGL 3.0 qui devait corriger le tir et devenir un direct3D Killer prend un an de retard sans pratiquement aucune communication du groupe Khronos. Finalement loin de la refonte attendue qui aurait permis de rendre OpenGL utile dans uen optique de jeu, c'est une suite logique d'OpenGL 2.0 qui sort avec ses archaisme et ses shaders séparés. La puissance de calcul nécessaire pour faire de l'OpenGL 3.x en hardware, et la complexité de programmation clouent définitvement OpenGL au sol. Son apotre Carmack prend sa retraite et pouf.
Pour l'instant pas grand chose coté OpenGL, et à moins qu'OpenGL 4.0 ne franchisse le pas que 3.0 aurait du franchir, je en vois pas comment OpenGL peut espérer devenir concurentiel un jour.
# C'est bien son truc... Sauf que c'est faux.
Posté par Jerome Herman . En réponse au journal Une analyse des librairies graphiques par un développeur de jeux vidéos. Évalué à 10.
OpenGL a existé des années avant Direct3D, le pendant d'OpenGL sous DirectX, mais il n'a jamais décolé dans l'industrie du jeu video. Les raisons sont multiples :
Tout d'abord OpenGL n'est pas un système qui permet facilement le rendu 3D temps réel, ca n'est pas sa vocation. OpenGL est une bibliothèque graphique de gestion de rendu. La première chose que l'on fait quand on écrit un programme OpenGL est de définir quelle sera la qualité du rendu, en d'autres termes quelle précision de calcul on veut. Cette option va de GL_Default jusqu'à GL_Nicest.
OpenGL es un système ouvert dans tous les sens du terme. Notamment il est très facile d'y ajouter carte par carte des extensions spécifiques. Or très peu de cartes graphiques grand public, et même très peu de consoles de jeux sont exploitable dans le cadre d'un jeu video moderne sans faire appel massivement à ces fonctions étendues. Lesquelles sont évidement non portables, ou tout du mois spécifiques à certaines familles de puces graphiques.
OpenGL gère l'ensemble du pipeline de rendu graphique de la carte vidéo. Ce qui est très bien pour un rendu de précision, mais qui pose un véritable problème dans le cadre d'un PC de bureau. Si vous lancez une application OpenGL, elle va mettre la main sur tout un pipeline de rendu. Donc si vous lancez une seconde application OpenGL, soit vous avez une carte graphique professionnelle avec Autant de pipeline que nécessaire, soit la seconde application ne sera pas accélérée 3D et passera en mode pur soft. Sous Direct3D il est tout à fait possible d'accélerer simultanément plusieurs rendus, car c'est le système et non l'appli qui fait le dispatch des traitements. C'est pour celà que sous Vista et 7 tant que l'on a pas désactivé Aero, les performances OpenGL sont assez limitée. Bon Microsoft a sorti un patch qui fait que si l'appli OpenGL passe en plein écran aero va faire dodo et on a des perfs correctes, mais en fenétré c'est une catastrophe.
OpenGL ne s'occupe que du graphisme, et seulement dans la qualité voulue. Si par hasard vous vouliez vouer du son ou ajouter des éléments de calcul dans votre appli, à vous de vous démerder pour synchroniser tout çà. Dans DirectX ce sont les modules DirectInput et DirectSound qui se démerde à ne pas saturer trop en évènement le processeur pendant les phases de forte charge. Bon on fini souvent par être obligé de tricher un peu. Mais on a pas à tout faire à la main tout le temps
OpenGL comme DirectX ont subis des changements de paradigme important. Tant au niveau interne que vis à vis des langages et des méthodes de programmation. DirectX 5.0; Dirext 7.0 et DirectX 9.0 font appel à des concepts de programmation graphique suffisament différent pour que l'expérience de l'un ne soit pas utile aux autres. Néamoins c'est DirectX qui reste en tête. Tout simplement parcequ'il est nettement plus adapté au jeu vidéo...
Pour finir OpenGL a de nombreuses applications en dehors du jeu video, il ne viendrait à l'idée de personne de faire une imagerie médicale pour irradiation avec Direct3D (encore que...) Mais cette puissance à un prix, les objets OpenGL sont beaucoup plus pointus et beaucoup moins flexibles que leurs contreparties Direct3D. De fait le temps de programmation est rallongé d'autant.
Quand Microsoft a présenté la suite DirectDraw (Qui allait devenir DirectX 1.0) aux devs de jeux, il se sont foutus de leur gueule. Un moteur 3D ou 2D à l'époque ca se codait à la main et ca se lancait en DOS.
Au départ ni DirectX ni OpenGL n'ont décollé. En fait l'élément perturbateur a été 3DFX avec le Glide. API propriétaire tournée exclusivement vers le jeu. C'est là que ca a fait tilt. Microsoft a sorti un set d'instruction d'accellerations 3D sous la forme de DirectX 3 en faisant très attention à s'arranger pour que la plupart des traitements soient faciles à réaliser soit en MMX, soit en utilisant les fonctions de rendus vidéo déjà présente dans certaines cartes haut de gamme, et qui devaient se généraliser avec l'arrivée des DVD. C'est alors que ATI s'est engouffré dans la brêche avec les cartes xpert@work et xpert@play rejoint très peu après par Matrox qui ont fait des cartes de décompression MPEG-2 avec les suppléments nécessaire pour faire tourner en hard DirectX 3.0 et le draft DirectX 4. Sauf que le Glide2 poussait à la porte, DirectX 4 n'a pas duré très longtemps et directX 5 a été créé dans la foulée pour faire front face au Glide 2.
Mais au moment de la conception DirectX 5 un certain Carmack, qui pour ainsi dire avait rendu possible la 3D temps réel sur PC de salon, décidait de sortir Quake2 en OpenGL. Carmak étant le plus gros vendeur de jeux videos du moment, on a eu droit aussi bien coté glide avec des wrappers que coté ATI et Matrox avec des versions réduites à des pilotes OpenGL un peu costaud sur nos machines.
Seulement il s'agissait de Mini-Drivers, c'est à dire de pilote conçus pour faire tourner Quake 2 et rien d'autre. Pas un vrai support OpenGL.
Après quand Half Life a utilisé une version modifiée du quake engine, ca a fonctionné car les fonctions appelées étaient les mêmes. Cependant ca a transmis un vrai message aux fabriquants de cartes graphiques : il fallait faire de vrais pilotes OpenGL complet et tout. C'est le moment ou toutes les cartes graphique sun peu péchue supportaient l'ensemble de l'API OpenGL 1.2. C'est aussi à ce moment que le groupe Lokhi a fait des merveilles en termes de portages de jeux sous Linux. Leur version OpenGL du moteur d'Unreal poussait le vice jusqu'à battre le moteur Glide2 fait par les devs originaux. OpenGL avait le vent en poupe.
Et puis OpenGL 1.3 est sorti. Et là les fabriquants de cartes graphique sont éclatés de rire et se sont tournés vers Directx7 qui était beaucoup plus raisonnable en terme de puissance demandé pour un résultat correct. C'est un petit nouveau : NVidia qui est venu mettre la pagaille dans tout çà, en annonçant coup sur coup le support du transform and Lightning sur Directx7 et le support complet d'openGL 1.3 (Bon complet du tronc principal de l'ARB, toutes les extensions officielles n'étant pas supportée). La geforce va se vendre comme des petits pains. Et les autres constructeurs corrigent leur copie pour utiliser à fond OpenGL 1.3.
Mais aucun jeu majeur utilisant OpenGL 1.3 ne sortira. Les seuls jeux qui sortent et qui utilisent OpenGL sont OpengL 1.2, basé soit sur le moteur de quake 2 soit sur celui d'Half Life. Des jeux qui auraient pu être pris en charge par des mini drivers tout aussi bien (et en fait la guerre des benchs commencant, les différents fabriquants n'hésitent pas à créer des pilotes spécifiques pour tel et tel jeu en OpenGL de façon à bosster artificiellement les perfs, en rennomant l'executable quake2.exe en quack2.exe le site anandtech observe une perte de framerate de 30% sur Geforce). Le thresh Firing Squad s'en mèle pour donner un point de vue Vitesse d'affichage vs Beauté de l'affichage qui n'est pas en faveur de la beauté du tout. OpenGL 1.4 sort dans l'indifférence générale coté fabriquant. Seul les systèmes de compression de texture et l'illumination dynamique seront implémentés.
OpenGL 2.0 est une catastrophe en regard de l'industrie du jeu, seul Carmack s'en sert un peu, mais son temps est passé et Doom 3 et Quake 3 se vendent mal (pour du Carmack). Aujourd'hui encore très peu de cartes sont capables de gérer l'ensemble du tronc ARB d'OpenGL 2.0 en pur hardware.
OpenGL 3.0 qui devait corriger le tir et devenir un direct3D Killer prend un an de retard sans pratiquement aucune communication du groupe Khronos. Finalement loin de la refonte attendue qui aurait permis de rendre OpenGL utile dans uen optique de jeu, c'est une suite logique d'OpenGL 2.0 qui sort avec ses archaisme et ses shaders séparés. La puissance de calcul nécessaire pour faire de l'OpenGL 3.x en hardware, et la complexité de programmation clouent définitvement OpenGL au sol. Son apotre Carmack prend sa retraite et pouf.
Pour l'instant pas grand chose coté OpenGL, et à moins qu'OpenGL 4.0 ne franchisse le pas que 3.0 aurait du franchir, je en vois pas comment OpenGL peut espérer devenir concurentiel un jour.