J'écris ce petit journal pour vous parler d'un article que j'ai lu sur le site jeuxlinux.fr. Il s'agit de la traduction d'un article de blog d'un développeur de jeux vidéos qui s'exprime sur sa préférence à utiliser OpenGL plutôt que DirectX.
Si je viens vous en parler c'est que l'analyse est plutôt intéressante avec de bon argument, il parle du danger de s'enfermer dans un format propriétaire et casse des idées reçu sur la soit disante mauvaise qualité d'OpenGL. En plus elle a le bon goût d'être simple et accessible afin d'être comprise de tous et ce, même des joueurs qui ne comprennent pas grand chose à cela.
http://www.jeuxlinux.fr/a285-Pourquoi_devriez-vous_utiliser_(...)
Bon en gros il dit : DirectX a toujours un train de retard, n'est pas portable, demande d'avoir toujours le dernier windows pour marcher alors que OpenGL implémente en permanence les dernières nouveautés, fonctionne sur Windows, MacOS, Linux, PSP, Playstation, Wii et Iphone et que des grands noms du jeux vidéo l'utilise comme blizzard ou ID Software donc ça ne doit pas être si pourri que ça. Il ajoute aussi que faire un portage sur Mac et pourquoi pas sur Linux n'est jamais une perte de temps car ça ouvre de nouveaux marchés.
Bonne lecture.
Journal Une analyse des librairies graphiques par un développeur de jeux vidéos
18
jan.
2010
# .
Posté par Octabrain . Évalué à 4.
"DirectX a toujours un train de retard, n'est pas portable, demande d'avoir toujours le dernier windows pour marcher"
"des grands noms du jeux vidéo l' [OpenGL] utilise comme blizzard ou ID Software"
Échec épique, ID software est passé à DirectX pour développer Rage, alors qu'ils étaient avant avec OpenGL.
[^] # Re: .
Posté par Mr Kapouik (site web personnel) . Évalué à 10.
Sinon ton deuxième paragraphe montre que tu as bien lu l'article vu qu'il y a une belle référence à une interview de John Carmack de 2008 où justement il y dément utiliser directX mais une API DirectX dans son moteur afin de porter son jeu sur xbox 360. Pour info il avait fait ça déjà pour Doom 3 qui tournait en DirectX sous windows et en OpenGL sur toutes les autres plateforme.
http://www.maximumpc.com/article/features/e3_2008_the_john_c(...)
[^] # Re: .
Posté par Paf . Évalué à 2.
L'article semble bien faire la distinction dans les paragraphes. J'ai plutot l'impression qu'il utilise DirectX pour simplifier les choses.
Ceci dit pour les jeux, la SDL fait tres bien le boulot, sans poser le probleme d'avoir 10000 api sonores.
Et perso j'utilise Ogre3d + openal + ois et je n'ai pas vraiment de soucis.
.
Échec épique, ID software est passé à DirectX pour développer Rage, alors qu'ils étaient avant avec OpenGL.
Sources ?
D'apres http://en.wikipedia.org/wiki/Rage_%28video_game%29 :
Regarding the status of the Linux port after the July 14, 2008 announcement, John Carmack said "It isn't a launch platform for us, but an executable may still show up."[17] Later he said that a Linux port is unlikely in response to an email where he says "It isn't out of the question, but I don't think we will be able to justify the work." and "It probably wouldn't be all that bad to get it running on the nvidia binary drivers, but the chance of it working correctly and acceptably anywhere else would be small."[18] Three weeks later Timothee Besset, the person in charge of porting id's products to Linux, discussed the future of the Linux port in a more positive light, stating on September 13, 2009 that "Fundamentally nothing has changed with our policy regarding Linux games... I'll be damned if we don't find the time to get Linux builds done."[19]
Et d'apres http://en.wikipedia.org/wiki/Id_Tech_5 :
The engine was first demonstrated at the WWDC 2007 by John D. Carmack on an eight-core Apple Macintosh computer; however, the demo only used a single core with single-threaded OpenGL implementation running on a 512 MB 7000 class Quadro video card.
[^] # Re: .
Posté par Narishma Jahar . Évalué à 3.
# C'est bien son truc... Sauf que c'est faux.
Posté par Jerome Herman . É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.
[^] # Re: C'est bien son truc... Sauf que c'est faux.
Posté par Paf . Évalué à 4.
Ce sont les deux faces de la meme piece.
On peut soit exploiter ces nouvelles fonctions des qu'elles sortent via des extensions specifiques a la puce graphique d'un constructeur, ou attendre et voir quelque chose commun aux puces graphiques.
Ceci dit j'avoue aussi avoir ete decu par opengl 3.0.
Mais il n'empeche qu'OpenGL, de par son ouverture et ses qualites (bonnes ou mauvaises) permet de faire des jeux et qu'il n'y a pas de raison de s'en priver (voir le jeu "darkest of days" par exemple).
[^] # Re: C'est bien son truc... Sauf que c'est faux.
Posté par Stephane Marchesin (site web personnel) . Évalué à 10.
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.
Non c'est faux, ces hints sont optionnels, et en plus au moins 90% des drivers ne les implémentent pas. Et pour cause, le hardware video n'a plus de fonctionnalité pour réaliser ces hints (pour référence le dernier hardware nvidia à implementer ces hints c'est la TNT/TNT2, les générations suivantes ont l'équivalent de GL_NICEST et c'est tout).
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.
Encore une fois c'est faux. Avoir plusieurs applications OpenGL avec l'acceleration, on y arrive sous X.Org (avec compositing et tout le bordem) et aucune des instances ne tourne en soft. Tu imagines sinon ? Tu tournes compiz (== 1 appli OpenGL) et après tu n'as plus d'accélération 3D, on se ferait massacrer. Après si c'est la merde sous Vista c'est la faute de Microsoft et c'est tout, pas besoin d'accuser OpenGL. OpenGL ce n'est pas une grosse main qui attrape ta carte video et qui après ne veut pas la rendre :)
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.
Si tu parles de drivers miniport, ce n'est pas fait pour quake2. En fait miniport est une couche simplifiée entre OpenGL et le driver windows qui permet de faire un driver OpenGL plus facilement, et laisser miniport implémenter les trucs un peu tordus de manière générique en logiciel. Si tu regardes les cartes de l'époque, elles ne pouvaient pas accélerer tout OpenGL, donc elles auraient de toute façon du implémenter ces fameux fallback en logiciel. Pour résumer, les trucs que miniport faisait en logiciel, tu ne les avais pas dans direct3D.
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.
Ah voilà un exemple intéressant, celui du transform and lightning. Les applications qui étaient écrites en OpenGL 1.0 (ou plus) ont pu exploiter le transform and lighting sans avoir besoin de recompilation/modification d'aucun genre. A côté de ça microsoft a introduit DirectX 7 comme une révolution et tout le monde a trouvé géniale l'idée du Transform and lighting. Et ça m'amène au point principal que je veux soulever : c'est le marketting qui fait que DirectX/Direct3D gagne, et c'est tout.
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.
Concrètement, tu voudrais quels changements dans OpenGL ? Par exemple tu critiques les shaders séparés, mais Direct3D 10 et OpenGL 3.0 ont tous les deux des shaders séparés. Donc d'après ton critère, Direct3D 10 est aussi nul que OpenGL ? D'ailleurs les APIs sont très proches, ayant pratiqué les 2 je trouve qu'on passe de l'un à l'autre sans souci.
Encore une fois j'ai l'impression que OpenGL a surtout un problème de communication (au point que même les geeks de linuxfr le renient) en face de la machine de communication de Microsoft. Alors certes cet article est partisan, mais mettons un peu les choses en perspective et comparons-le au marketting fait pour Direct3D. Je pense que tout le monde est d'accord pour dire qu'il y a encore quelques ordres de grandeur de différence :)
[^] # Re: C'est bien son truc... Sauf que c'est faux.
Posté par Jerome Herman . Évalué à 2.
Trois petites choses :
Quand la TNT est est sortie, on ne parlait pas vraiment d'OpenGL hardware sur Windows pour Nvidia. Le pilote de base OpenGL sous windows 95 était pur soft.
Et kes drivers qui existait à l'époque s'installait à coup de copie de DLL et d'édition de base de registre.
Les hints sont essentiels dans la plupart des applis professionnelles. Car le rendu diffère vraiment d'un cas à l'autre.
Les denière générations de Cartes 3D sur lesquelles j'ai bossé chez NVidia (à savoir les 8000) font un peu ce qu'elles veulent et ignorent les hints. Certains rendus sont fait en GL_Nicest, les autres sont fait en ce qu'on peut. Et tant pis si il y a des Z aliasing ou des déformations à la con parceque le pilote fait des arrondis un peu cavalier. Certes il s'agit de cartes de desktop, donc ce n'est pas grave techniquement. Mais d'un autre coté ca oblige à tester son rendu carte par carte pour savoir sil il est propre ou pas.
Encore une fois c'est faux. Avoir plusieurs applications OpenGL avec l'acceleration, on y arrive sous X.Org (avec compositing et tout le bordem) et aucune des instances ne tourne en soft. Tu imagines sinon ? Tu tournes compiz (== 1 appli OpenGL) et après tu n'as plus d'accélération 3D
L'architecture Xorg fait que toutes les applis utilisent la même instance avec le composting. L'avantage est que plusieurs applis peuvent faire de l'OpenGL en même temps, l'inconvennient est que toutes les applis sont impactées si il y a un problème. Par exemple si tu charges une vidéo en mode texture dans une appli, tout le monde morfle.
Autre inconvennient tu ne peux pas charger des pilotes spécifiques à ton appli. C'est le même tarif pour tout le monde. Si tu veux faire de l'accéleré Hardware pour un pré-rendu et ensuite du Mesa pour un rendu correct techniquement, tu es bon pour recharger ton Xorg entre les deux.
Si tu parles de drivers miniport, ce n'est pas fait pour quake2. En fait miniport est une couche simplifiée entre OpenGL et le driver windows qui permet de faire un driver OpenGL plus facilement, et laisser miniport implémenter les trucs un peu tordus de manière générique en logiciel. Si tu regardes les cartes de l'époque, elles ne pouvaient pas accélerer tout OpenGL, donc elles auraient de toute façon du implémenter ces fameux fallback en logiciel. Pour résumer, les trucs que miniport faisait en logiciel, tu ne les avais pas dans direct3D.
OpenGL possède de base des mécanismes pour faire en software ce qu'il ne sait pas faire en Hardware. Les mini ports vont plus loin, ils permettent de faire en rendu hardware certaines fonctions OpenGL sous certaines conditions, mais de retomber en rendu soft si la même fonction est appelée dans d'autres conditions. Historiquement les certaines fonctions en question étaient celles utilisées par Quake 2 et les certaines conditions celles de Quake 2. Déjà toutes les fonctions qui n'utilisaient pas GL_RGB mais un autre espace de couleur (au hasard YUV pour plaquer des vidéo) repassaient en soft immédiatement. Alors que les cartes de l'époque (TNT2, ATI Xpert, Millenium G100, Millenium G200 etc.) savaient convertir le YUV en RGB en Hard.
Idem si on charge les textures avec autre chose que du GL_SMOOTH.
Ah voilà un exemple intéressant, celui du transform and lightning. Les applications qui étaient écrites en OpenGL 1.0 (ou plus) ont pu exploiter le transform and lighting sans avoir besoin de recompilation/modification d'aucun genre.
Oui OpenGL supportait le T&L depuis longtemps. Mais pas les pilotes de carte graphique (ni les cartes graphiques d'ailleurs). OpenGL gère tout le pipeline de rendu, donc forcément le T&L aussi. Mais il faudra attendre que la Geforce sorte et qu'elle décide de faire un pilote OpenGL 1.3 pour que l'on ait un semblant de T&L OpenGL sous windows. Sous Linux/Unix/autre il faudra attendre 2002, soit la FireGL d'ATI pour avoir un semblant de support T&L sur Radeon 9000. Alors que les shaders sont déjà en train de remplacer le système T&L.
Concrètement, tu voudrais quels changements dans OpenGL
Comme tout le monde ou presque :
- Une vraie rupture de compatibilité, ou à défaut un hint qui permette de dire si l'on veut utiliser les fonctions OpenGL en mode 3.0 ou en mode deprecated. celà permettrait de faire un grand ménage dans tout un tas de fonctions qui ne sont plus utilisées par personne aujourd'hui. C'était la principale promesse d'OpenGL 3.0.
Un exemple tout con : plaquer une texture S3TC/DXTC sur un cube demande une page complète de code, pour charger la texture, la valider, la binder, la décompresser, la transformer en texels 2D, l'appliquer, corriger la perspective, la lisser et enfin l'afficher. Et là je parle même pas de charger plusieurs résolutions de textures pour faire du filtering aniso. En DirectX 8+ ca ne prend que quelques lignes.
- Les shaders OpenGL sont surpuissant. On peu les rentrer à n'importe quel niveau du traitement de rendu pour les repasser dans la moulinette, seulement c'est horriblement complexe. En DirectX il y a pleins de méthode pour réintégrer facilement des shaders au étapes de tesselations ou d'illumanitions pour les vertex, et aux étapes de mapping et d'illumination pour les pixels. Certes c'est plus limité, mais d'un autre coté c'est aussi nettement plus simple à mettre en place. Les ponts Direct3D <-> Shaders tout pret sont plus nombreux en DirectX.
- Les hints OpenGL sont gentils, mais il y en a un peu trop, un peu trop souvent. En Direct3D on décide une fois pour toute ce que l'on veut appliquer comme méthode ou pas. Et normalement c'est bon. En OpenGL il est théoriquement possible de faire de l'aniso pointu sur une texture tout en faisant un plaquage à l'arrache sur une autre texture du même objet. Il serait bon que l'on puisse définir une table des sélections par défaut et que l'on ait pas à repasser 122 000 arguments à chaque fonction de rendu ou de chargement de modèle.
Encore une fois j'ai l'impression que OpenGL a surtout un problème de communication (au point que même les geeks de linuxfr le renient) en face de la machine de communication de Microsoft.
Le DirectX qui a explosé et qui a placé Microsoft en tête des API de jeux vidéos c'est le 5.0. A l'époque tous les gamers avaient des cartes 3DFX, Le dieu du Jeu Vidéo (Carmack) bossait exclusivement en OpenGL et la bibliothèque de rendu finale (msvcrt.dll) était bugguée jusqu'à la moelle. En plus en 1999/2000 toutes les cartes gamers possédaient un OpenGL 1.2 complet et un OpenGL 1.3 bien avancé.
Malgré tout ces défauts DirectX a gagné haut la main, face à Glide et face à OpenGL. C'est pas juste un problème de com, c'est un problème de COM (quel humour). Utiliser OpenGL de façon propre, efficace et sans casser windows était un casse tête sans nom. DirectX plus limité était aussi plus simple et raccourcissait grandement les temps de dev. Par la suite OpenGL a loupé coche sur coche (filtering avancé, compression de texture, antialiasing, shaders tout celà existe sous OpenGL mais est assez complexe a mettre en place) alors que DirectX s'étoffait.
Aujourd'hui OpenGL est toujours aussi complexe à mettre en place, alors que DirectX a su évolué et combler ses lacunes tout en restant assez simple. Bien entendu aucun jeu vidéo professionnel du devant de la scène (les jeux microtruc c'est moins sur) n'utilise les fonctions DirectX brut de décoffrage. Mais DirectX permet d'avoir très vite un truc qui marche complètement. Quand on sait que le temps de dev d'un jeu est de deux à trois ans et qu'il y a un changement majeur de méthodes de programmation tous les 18 mois, c'est pratique.
[^] # Re: C'est bien son truc... Sauf que c'est faux.
Posté par auve . Évalué à 2.
Cela existe depuis OpenGL 3.1. Mais c'est pas comme si OpenGL 3.0+ (prévu pour Mesa 8.0) allait arriver demain dans les pilotes libres...
[^] # Re: C'est bien son truc... Sauf que c'est faux.
Posté par glisse . Évalué à 10.
OpenGL est tout a fait capable de supporter plusieurs applications en meme temps et il ne souffrira pas plus que Direct3D dans les meme conditions.
Tu peux tres bien utiliser un driver particulier pour chacune de tes applications (meme avec le compositing active) et ceux sans relancer le serveur X, il existe plusieurs variable d'environnement pour y arriver (je le fais courament pour tester une modif sans casser ma config qui marche et sans relancer X).
Cela etant dis, oui les drivers open source sont a la traine mais il n'y pas le meme nombre de personnes qui travaillent sur les drivers open source et les drivers proprietaires (si ma memoire est bonne AMD ou NVidia on ~400 ingenieurs sur leur driver, un driver open source c'est une dizaine de personnes et pas a temps plein).
Merci pour ce joli Troll qui a surgit du beau brouillard de ce matin.
[^] # Re: C'est bien son truc... Sauf que c'est faux.
Posté par Jerome Herman . Évalué à 2.
Je me suis mal exprimé, la fauter en revient plus aux cartes graphiques qu'à OpenGL lui même. Une fois de plus j'ai quitté le monde 3D sous la Geforce 8000, la Radeon 9600. Je ne sais pas si le monde a changé depuis, mais à l'époque ouvrir deux contextes de rendus 3D accélérés sous ces cartes était très complexe pour ne pas dire impossible. Je ne sais pas ce qu'il en est aujourd'hui. Bien sur OpenGL peut gérer des centaines de rendu simultanément si la carte et ses pilotes le permettent.
Tu peux tres bien utiliser un driver particulier pour chacune de tes applications (meme avec le compositing active) et ceux sans relancer le serveur X, il existe plusieurs variable d'environnement pour y arriver (je le fais courament pour tester une modif sans casser ma config qui marche et sans relancer X).
Alors là je veux bien que tu m'expliques comment. En ce moment même je suis en train de me dire que Linux n'est plus fait pour moi (après 10 ans sous l'OS sans discontinuer) justement pour des trucs comme çà.
J'ai cherché comment faire des switchs de lin OpenGL à chaud (application OpenGL en train de tourner) ou à froid sans jamais arriver à un autre résultat que le crash de Xorg ou le freeze de la machine (N.B : plusieurs machines, plusieurs cartes graphiques). Ce que tu dis m'interresse donc grandement.
[^] # Re: C'est bien son truc... Sauf que c'est faux.
Posté par glisse . Évalué à 7.
#!/bin/bash
export LIBGL_DRIVERS_PATH=<path to Mesa>/lib
export LD_PRELOAD=<path to Mesa>/lib/libGL.so.1
$@
Tu completes les repertoires, et du cree autant de script que de version differents que tu veux tester puis tu fait :
apres tu fais ./mygl.sh glxgears
Tu peux rajouter export LIBGL_ALWAYS_SOFTWARE=1 si tu veux forcer le rendu software de mesa.
Note, valable que pour les drivers open source, marche que pour un seul driver/gpu (tu peux pas changer de gpu si tu as plusieurs gpu dans ta machine). Il y a d'autre options voir: http://www.mesa3d.org
[^] # Re: C'est bien son truc... Sauf que c'est faux.
Posté par Christophe Discours (site web personnel) . Évalué à 0.
Je ne sais pas ce qu'il en est aujourd'hui
moi je crois que tu es à la rue...
[^] # Re: C'est bien son truc... Sauf que c'est faux.
Posté par Jerome Herman . Évalué à 2.
Le fait que je sois à la rue aujourd'hui, ce que j'admet volontier et répète souvent moi même n'a aucun impact sur ce qui c'est passé à l'époque alors que je n'était pas vraiment à la rue.
Hors ce qui s'est passé à l'époque (ie entre 1997 et 2005) est ce qui a fait qu'OpenGL est passé à la trappe au profit de DirectX dans le cadre strict du jeu video.
A noter que d'après certains commentaires OpenGL semble aussi passer à la trappe dans le cadre des applications pro...
[^] # Re: C'est bien son truc... Sauf que c'est faux.
Posté par thedude . Évalué à 4.
A une certaine epoque, si tu voulais de la 3d correcte, c'etait des stations dediees, style SGI, qui tournaient sous des unix proprio, et donc t'avais qu'open gl a te mettre sous la dent.
Bien oblige de faire avec, c'est ce que les clients veulent, et ca tombe bien, ya rien d'autre.
Mais cette epoque est revolue et un desktop x86 n'a plus a rougir face a une station SGI.
L'ecart de puissance entre les stations SGI ou sun ou autre unix proprio et les desktops x86/carte graphique decente s'est tellement reduit qu'il n'y pas plus d'avantage technique flagrant en faveur de la station dediee.
Et quand tu vois le prix que ces machines coutent, le fait qu'elles sont dediees a une tache bien precises (ce qui rend la gestion du stock plus dure), ca heterogeneise le parc, ben les clients commencent a se dire qu'ils pourraient remplacer tout ca par un bete core2duo avec un carte nvidia qui depote bien, perdre un peu en performance, mais plus s'emmerder avec une palanquee de station esoterique.
Et on sait tous ce qu'ils vont mettre comme OS sur ces x86 ;-)
Resultat les fournisseurs (genre, heu, disons dassault systeme, juste pour l'exemple, hein) suivent la demande des clients, sortent une version windows, se rendent compte que ca marche bien, droppent le support unix proprio parce que plus personne en veut.
Et pour la version linux, ben heuuuu... Honnetement, j'y reflechirais a deux fois avant de sortir un produit assez pousse graphiquement et devoir le maitnenir 5 a 10 ans sur une plateforme qui bouge autant au niveau graphique.
Et j'aborde meme pas la problematique des drivers libres/proprio. Tout mon respect a nouveau, sincerement, mais je doute que quiconque de sain se base dessus. Quand aux pilotes proprio, ben heu, on connait tous les problemes (perfs bof face a windows, bugs et probleme epineux de l'update du kernel).
Alors si en plus il faut rajouter du dev sur le portage linux juste pour pouvoir ouvrir un pot de pus pareil...
Et voila comment OpenGL se retrouve un pied dans la tombe.
[^] # Re: C'est bien son truc... Sauf que c'est faux.
Posté par VoixOff . Évalué à 0.
À é é é é à.
é ç.
é é à à.
é é é (a) é é.
û é é à é ç é é é ï à ç ê é é (s) é é (s).
é è ç (n').
ê é é à é à. ê é. à è. à è. (s/d/t/) î è à à é.
J'ai retrouvé tes accents :-)
Désolé.
[^] # Re: C'est bien son truc... Sauf que c'est faux.
Posté par thedude . Évalué à 3.
j'avais conduit toute une nuit a travers les bois et j'ai passe un heure a les attacher a un arbre...
va falloir que je les nourisse et tout maintenant...
[^] # Re: C'est bien son truc... Sauf que c'est faux.
Posté par dinomasque . Évalué à 3.
BeOS le faisait il y a 20 ans !
[^] # Re: C'est bien son truc... Sauf que c'est faux.
Posté par Jerome Herman . Évalué à 2.
Quand je compare le prix d'une station SGI ou Wildcats au prix d'une licence Catia, je me dis que si Dassault System (puisque c'est l'exemple que tu cites) décide de faire un portage de OpenGL à DirectX et de Unix à Windows ca doit pas être seulement pour faire plaisir à un SI qui aimerait bien avoir que du x86 dans son infra....
[^] # Re: C'est bien son truc... Sauf que c'est faux.
Posté par thedude . Évalué à 2.
Et ensuite une fois pompe amorcee, tu drop le support unix. Pas de support linux dans les tuyaux (DS n'en a visiblement rien a branler, probablement parce que les clients ne sont pas assez nombreux/lourd pour amener DS a le faire), donc tu finit windows only, et la t'es a qq doigt de laisser tomber open gl.
[^] # Re: C'est bien son truc... Sauf que c'est faux.
Posté par Stephane Marchesin (site web personnel) . Évalué à 10.
Quand la TNT est est sortie, on ne parlait pas vraiment d'OpenGL hardware sur Windows pour Nvidia. Le pilote de base OpenGL sous windows 95 était pur soft.
Et kes drivers qui existait à l'époque s'installait à coup de copie de DLL et d'édition de base de registre.
Les hints sont essentiels dans la plupart des applis professionnelles. Car le rendu diffère vraiment d'un cas à l'autre.
Les denière générations de Cartes 3D sur lesquelles j'ai bossé chez NVidia (à savoir les 8000) font un peu ce qu'elles veulent et ignorent les hints. Certains rendus sont fait en GL_Nicest, les autres sont fait en ce qu'on peut. Et tant pis si il y a des Z aliasing ou des déformations à la con parceque le pilote fait des arrondis un peu cavalier. Certes il s'agit de cartes de desktop, donc ce n'est pas grave techniquement. Mais d'un autre coté ca oblige à tester son rendu carte par carte pour savoir sil il est propre ou pas.
Non, encore une fois c'est faux. Toutes les cartes nvidia depuis la première geforce n'ont pas de quoi gérer les hints dont tu parles, les hint en question n'existent plus et ne servent à rien. Source : je suis le fondateur de nouveau donc je connais le hard nvidia un peu. Et si tu ne me crois pas les specs des cartes nvidia qu'on a RE sont bien au chaud dans un fichier xml : http://nouveau.cvs.sourceforge.net/viewvc/nouveau/renouveau/(...)
Tu verras que seules les TNT ont les fameux hints.
L'architecture Xorg fait que toutes les applis utilisent la même instance avec le composting. L'avantage est que plusieurs applis peuvent faire de l'OpenGL en même temps, l'inconvennient est que toutes les applis sont impactées si il y a un problème. Par exemple si tu charges une vidéo en mode texture dans une appli, tout le monde morfle.
Non. Des instances séparées de libGL sont utilisées pour chaque appli OpenGL que tu lances. Source : je suis dev X.Org et mesa.
Autre inconvennient tu ne peux pas charger des pilotes spécifiques à ton appli. C'est le même tarif pour tout le monde. Si tu veux faire de l'accéleré Hardware pour un pré-rendu et ensuite du Mesa pour un rendu correct techniquement, tu es bon pour recharger ton Xorg entre les deux.
Non c'est faux. Tu peux très bien utiliser LD_PRELOAD si tu veux un autre implémentation de GL (par exemple du mesa soft dans une certaine appli au lieu d'un driver DRI).
Source : t'as qu'à essayer LD_PRELOAD=/path/to/mesa/libGL.so ./monappli et tu auras du rendu soft. Tout ça sans "recharger ton X.Org"
OpenGL possède de base des mécanismes pour faire en software ce qu'il ne sait pas faire en Hardware.
Non, OpenGL est une spec, et une spec n'a pas de mécanismes pour faire des trucs en software. Source : va voir sur opengl.org et tu verras que c'est une spec.
Les mini ports vont plus loin, ils permettent de faire en rendu hardware certaines fonctions OpenGL sous certaines conditions, mais de retomber en rendu soft si la même fonction est appelée dans d'autres conditions. Historiquement les certaines fonctions en question étaient celles utilisées par Quake 2 et les certaines conditions celles de Quake 2. Déjà toutes les fonctions qui n'utilisaient pas GL_RGB mais un autre espace de couleur (au hasard YUV pour plaquer des vidéo) repassaient en soft immédiatement. Alors que les cartes de l'époque (TNT2, ATI Xpert, Millenium G100, Millenium G200 etc.) savaient convertir le YUV en RGB en Hard.
Non, Quake 1/2 n'a jamais utilisé aucun truc en espace de couleur YUV. Source : lis le code source de quake 1/2. C'est tout du RGB.
Idem si on charge les textures avec autre chose que du GL_SMOOTH.
Non, GL_SMOOTH ne s'applique pas aux textures. Source : la doc OpenGL qui explique que GL_SMOOTH s'applique a l'interpolation des couleurs sur les facettes et non pas l'interpolation des textures.
- Une vraie rupture de compatibilité, ou à défaut un hint qui permette de dire si l'on veut utiliser les fonctions OpenGL en mode 3.0 ou en mode deprecated. celà permettrait de faire un grand ménage dans tout un tas de fonctions qui ne sont plus utilisées par personne aujourd'hui. C'était la principale promesse d'OpenGL 3.0.
Un exemple tout con : plaquer une texture S3TC/DXTC sur un cube demande une page complète de code, pour charger la texture, la valider, la binder, la décompresser, la transformer en texels 2D, l'appliquer, corriger la perspective, la lisser et enfin l'afficher.
Non, tu n'as pas à valider la texture, tu n'as pas à explicitement la décompresser (fait par la carte), ni à la transformer en texels 2D (ça veut rien dire), ni à corriger la perspective (c'est fait tout seul). Source : les docs OpenGL.
Et là je parle même pas de charger plusieurs résolutions de textures pour faire du filtering aniso. En DirectX 8+ ca ne prend que quelques lignes.
Oh si parlons-en. En OpenGL l'anisotropique s'active en 1 ligne : glTexParameterf( GL_TEXTURE_2D, GL_TEXTURE_MAX_ANISOTROPY_EXT, 8.0);
Source : http://www.opengl.org/registry/specs/EXT/texture_filter_anis(...)
Enfin bref, encore une fois, j'ai montré point par point que tu dis n'importe quoi et que tu dénigres OpenGL sans fondement. Tu as lu 3 keywords OpenGL et tu crois connaître l'API. Encore une fois, c'est ça le gros problème d'OpenGL, le fait que les gens mal renseignés parlent en mal du bouzin mais écoutent le marketting à microsoft. Et le sens critique dans tout ça il est où ? On dirait une bande de moutons...
Bêêêêêêêêêeee
PS: alors, le fait que Direct3D ait des shaders séparés comme OpenGL, pourri ou pas pourri du coup ? Si c'est pourri dans OpenGL, c'est pourri dans Direct3D non ?
[^] # Re: C'est bien son truc... Sauf que c'est faux.
Posté par thedude . Évalué à 3.
Non, Quake 1/2 n'a jamais utilisé aucun truc en espace de couleur YUV. Source : lis le code source de quake 1/2. C'est tout du RGB.
C'est precisement ce qu'il dit, de facon detournee.
La phrase initial etait "les drivers avait implemente uniquement ce que quake utilisait, donc, par exemple, une fonction qui utilisait autre chose que RGB, comme par exemple du YUV, repassait en soft, meme si la carte etait techniquement capable de le faire en hard".
[^] # Re: C'est bien son truc... Sauf que c'est faux.
Posté par Jerome Herman . Évalué à 2.
Tu me dis trois réponses plus bas que OpenGL est une spec pas une implementation.(Ce qui est parfaitement exact par ailleurs). Or l'interpretation ou non des HINTS peut être fait en hard directement en mettant le bon regsitre à la bonne valeur. En hard indirectement en activant ou en coupant certaines fonctions via d'autres registres ou encore en soft dans le pilote avec des bidouilles qui impliquent plus ou moins var pas du tout des interventions dans le hard.
Maintenant en ce qui concerne les TNT. Je me fous de savoir qu'il y ait un registre GL_HINT dans la carte et que les geforce ne possèdent pas de registre similaire. Quand la TNT est sortie on était au tout début de l'OpenGL , et le pilote de base windows était pur soft. J'ignore complètement si la TNT gérait correctement les HINTS ou pas.
Par contre je peu te dire que la Quadro sortie quelques années après, qui était une super Geforce, elle les gérait de façon tout à fait correcte. Même si il n'y a pas de registres dédiés dans le hard. Ca devait se régler à coup de paramétrage du T&L ou autres gruikeries soft+hard mais là j'ai pas le code des pilotes de l'époque.
Par contre je peux te dire que les HINTS ca comptait pas mal, et à ma connaissance ca compte toujours pas mal dans le monde professionnel. Dans le dernier bouquin papier que j'ai acheté, le Red Book 2004 OpenGL 1.4 page 243 sur le GL_FOG_HINT il est écrit que le GL_Nicest fait un calcul par pixel et que le GL_FASTEST fait un rendu par vertex. Ca change pas mal le rendu pour les pros.
Non. Des instances séparées de libGL sont utilisées pour chaque appli OpenGL que tu lances. Source : je suis dev X.Org et mesa.
Peut être me suis-je mal exprimé sur celle là, parceque j'ai une autre réponse qui va dans le même sens plus haut. La question est : combien de surfaces de rendu OpenGL distinctes (i.e chacune avec son paramétrage et éventuellement sa ) je peux gérer en même temps sur une carte grand public. Et de façon générale combien de surfaces de rendus accélérées 3D je peux gérer simultanément, chacune avec ses propres composantes. Bien que la carte grand public n'est jamais été mon fort, des gros balèzes de Beyond3D répondaient assez souvent "une seule" à cette question.
Non c'est faux. Tu peux très bien utiliser LD_PRELOAD si tu veux un autre implémentation de GL (par exemple du mesa soft dans une certaine appli au lieu d'un driver DRI).
Source : t'as qu'à essayer LD_PRELOAD=/path/to/mesa/libGL.so ./monappli et tu auras du rendu soft. Tout ça sans "recharger ton X.Org"
J'ai essayé des trucs comme çà avec des drivers proprios et libres sur des cartes ATI et ca c'est jamais vraiment bien passé. Ca venait peut être d'ATI ou de mes configs. Là je ne peux rien affirmer il faut que je trouve le temps et que je reteste complètement.
Non, OpenGL est une spec, et une spec n'a pas de mécanismes pour faire des trucs en software. Source : va voir sur opengl.org et tu verras que c'est une spec.
Il y a des pages entières de la spec qui concernent le "software callback", comment il peut être géré par les implémenteurs et comment avoir une path software fallback est une bonne idée au cas ou on viendrait à manquer de ressources, comment gérer les buffers et les OUT OF BOUNDS quand on est amené à faire un software fallback. Comment doubler certaines infos en cas de possibilité de software fallback etc.
J'imagine que ca ne compte pas....
Non, Quake 1/2 n'a jamais utilisé aucun truc en espace de couleur YUV. Source : lis le code source de quake 1/2. C'est tout du RGB.
C'est exactement ce que je dis. Quake2 n'utilisait que du RGB, c'était même pas la peine d'essayer d'utiliser un autre espace de couleur si on voulait de l'acceleration sur les cartes de salon. On repassait en soft direct.
Non, GL_SMOOTH ne s'applique pas aux textures. Source : la doc OpenGL qui explique que GL_SMOOTH s'applique a l'interpolation des couleurs sur les facettes et non pas l'interpolation des textures.
GL_SMOOTH quand il est utilisé dans le cadre de glShadeModel déclenche un rendu de type Gouraud shading pour peu que l'on ait les bon vertex aux bons endroits. C'est très pratique même sur les textures quand ca se mélange à des infos d'éclairage. Par exemple http://nehe.gamedev.net/data/lessons/lesson.asp?lesson=07 qui est très basique et old school, mais qui met bien en exergue entre GL_SMOOTH et GL_FLAT même sur un objet texturé.
Et bien à l'époque Quake2 Avec les pilotes OpenGL de merde qu'on se trimballait à la maison, GL_FLAT + chargement d'une texture => retour en mode soft.
Non, tu n'as pas à valider la texture
Ah bon ? La fonction glGetTexLevelParameteriv est morte ? On fait quoi on part du principe que la texture est forcément compressée comme il faut, qu'elle va tenir en mémoire et que le proxy va accepter son format sans broncher ?
tu n'as pas à explicitement la décompresser (fait par la carte)
Tu sais quoi tu n'as pas non plus explicitement à venir chez l'utilisateur pour tracer tes triangles, c'est aussi fait par la carte. Mais il faut expliquer à la carte en question que c'est une texture compressée, il faut la mettre dans un buffer avec les bons paramètres et si il y a proxy il faut être gentil avec lui aussi. C'est un peu ce que j'apelle "décompresser" la texture.
ni à la transformer en texels 2D (ça veut rien dire)
Je t'accorde l'horrible abus de langage. Mais bon à un moment ou un autre il va bien falloir recouvrir un ensemble de polygones avec une succession de textures, éventuellement shadés. Car c'est bien le shading qui va casser les piedstant au niveau vertex pour le polygone sous-jacent, qu'au niveau pixel pour la texture elle même.
Oh si parlons-en. En OpenGL l'anisotropique s'active en 1 ligne : glTexParameterf( GL_TEXTURE_2D, GL_TEXTURE_MAX_ANISOTROPY_EXT, 8.0)
Oui, une fois que tu as sorti tes mipmaps, que tu as choisis ceux que tu voulais et que tu les a appliqués comme il faut. Ce qui prend une page.
Enfin bref, encore une fois, j'ai montré point par point que tu dis n'importe quoi et que tu dénigres OpenGL sans fondement.
J'ai peur qu'il ne te faille recommencer depuis le début.
[^] # Re: C'est bien son truc... Sauf que c'est faux.
Posté par Beretta_Vexee . Évalué à 3.
On modélise bien des avions avec Direct3D alors ... Plus sérieusement la plus part des gros soft professionnel inconditionnel d'openGL sont tous peut a peut passés de la station de travail SUN ou SGI à du tous Windows. Et comme tu l'as fait remarqué OpenGL sous windows c'est chercher les emmerdes, résultats la plus part de ces softs de CAO et autres sont désormais sous Direct3D et de ce fait Windows only ( finie les versions unix proprio et linux ).
[^] # Re: C'est bien son truc... Sauf que c'est faux.
Posté par alice . Évalué à 6.
Non ce n'est pas OpenGL (Direct3D aussi gère aussi l'ensemble du pipeline) qui est en cause mais des drivers pourris sur certaines machines. Et des machines comme ça, ça ne doit plus courir les rues, vu que ma Radeon X600 et ses drivers pas terribles n'a pas ce problème.
# Du bon gros troll
Posté par Littleboy . Évalué à 10.
DirectX a toujours un train de retard
Un lien vers un jeu qui utilisent des fonctionnalites presentes sur les cartes et pas dans DirectX? :D
n'est pas portable
des grands noms du jeux vidéo l'utilise comme blizzard ou ID Software
Les deux informations factuelles de l'article
demande d'avoir toujours le dernier windows pour marcher
Alors que sous Linux les anciens noyaux du temps de XP (aout 2001 - Linux 2.4.9 et Kde 2.2...) supportent les nouveaux pilotes OpenGL3.0? Ah ben non, il faut mettre a jour vers la derniere version de ta distrib (et parfois utiliser des pilotes proprio).
alors que OpenGL implémente en permanence les dernières nouveautés
Entre 2.0, 2.1 et 3.0: 2 ans d'intervalle a chaque fois. Et c'est pas comme si on avait attendu perpet' pour avoir enfin une version 3.0
On doit pas avoir la meme interpretation de "en permanence".
fonctionne sur Windows, MacOS, Linux, PSP, Playstation, Wii et Iphone
Wii il raconte n'importe quoi (et il se fait reprendre dans les commentaires), c'est pas de l'OpenGL.
PS3 la lib est assez peu utilisee et d'apres les retours elle est plutot pas terrible donc il vaut mieux utiliser direct GCM.
IPhone c'est OpenGL ES donc de tout facon il faut ajouter/reecrire une partie du code d'affichage, donc bon niveau facilite de portabilite, c'est pas non plus super.
PSP je suppose qu'il parle de PSPGL, un OpenGL-like donc perdu, c'est pas portable et il faut adapter le code si jamais le code utilise des choses non supportees (PSPGL is very incomplete sur la page du projet, ca met en confiance).
http://blog.wolfire.com/2010/01/Why-you-should-use-OpenGL-an(...)
Article original a lire au moins pour les commentaires, ou quelques personnes avec un portfolio un peu plus rempli (dev de moteurs 3D, etc.) demontent les parties trollesques de l'article (mais reste d'accord avec le fait que pour faire un jeu portable, OpenGL/SDL c'est pas mal, mais que de toute facon, avoir une couche d'abstraction c'est la base et que du coup tu t'en fous d'utiliser DirectX ou OpenGL, il vaut mieux laisser ce genre de combat debile aux trolls).
En tout cas, arriver a attirer a la fois les cretins anti-Novell et ce trolleur de Icaza dans les commentaires de son blog, il faut le faire. Il ira loin ce petit. Operation PR reussie!
[^] # Re: Du bon gros troll
Posté par Sébastien B. . Évalué à 2.
Windows XP est encore utilisé par quoi, allez, 30-50% des joueurs ? Par contre, Linux 2.4 chez les joueurs, hum.
[^] # Re: Du bon gros troll
Posté par thedude . Évalué à 3.
[^] # Re: Du bon gros troll
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Existe-t-il au moins une couche d'abstraction de référence? Et pourquoi empiler des couches? Après tout OpenGL est déjà une couche d'abstraction portable...
Je vois bien l'intérêt des éditeurs commerciaux qui ciblent les consoles de jeux et les quelques téléphones portables qui ont des puces 3D, mais pour les jeux libres, c'est du temps perdu, non?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Du bon gros troll
Posté par auve . Évalué à 1.
Parce qu'OpenGL et Direct3D ont vocation à être des couches d'abstraction très fines des possibilités du matériel, pas des moteurs de haut niveau gérant les diverses fonctionnalités nécessaires dans un jeu (systèmes d'effets, éclairage, transformations spatiales, interfaces graphiques in-game...). Par ailleurs, il me semble que le credo d'OpenGL (et maintenant d'OpenCL) est de proposer une couche d'abstraction certes portable mais qui exige une optimisation spécifique à chaque constructeur si on souhaite en tirer le maximum.
[^] # Re: Du bon gros troll
Posté par Littleboy . Évalué à 3.
Soit tu utilises un moteur 3D tout fait (soit du LL, soit sous licence) et beaucoup ont deja ce genre de chose et peuvent utiliser OpenGL sous Linux & MacOSX, OpenGL ES sous iPhone et DirectX/OpenGL sous Windows, soit tu fait toi meme ton moteur 3D et si c'est pour autre chose que faire mumuse, tu as tout interet a avoir ce genre de couche d'abstraction, ne serait-ce que parce que toutes les cartes ne supportent pas les memes extensions et donc il te faut prevoir plusieurs display paths (sans compter OpenGL ES).
mais pour les jeux libres, c'est du temps perdu, non?
En meme temps, les jeux libres de qualite potable, ca se compte sur les doigts d'une main. Et comme ils utilisent rarement plus que les fonctions de base sans pousser les cartes dans leurs derniers retranchements (le genre de truc qui a tendance a mettre a jour plein de bugs dans les drivers et des problemes de perfs en pagaille), oui, ca n'a aucun interet.
Mais l'article n'est clairement pas destine aux quelques devs de jeux libres.
[^] # Re: Du bon gros troll
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Je développe un jeu et j'aimerai qu'il tourne sur mobile, mais je trouve que ces machines sont vraiment trop diverses et/ou trop fermés.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.