Pourquoi les développeurs de jeux préfèrent-ils Windows?
Est-ce que DirectX est plus facile ou meilleur qu'OpenGL, même si OpenGL est multi-plateforme? Pourquoi ne voyons-nous pas de vrais jeux puissants pour Linux comme il en existe pour Windows?
Beaucoup de réponses ici sont vraiment, vraiment bonnes. Mais le problème OpenGL et Direct3D (D3D) devrait probablement être résolu. Et cela nécessite ... une leçon d'histoire.
Et avant de commencer, j'en sais beaucoup plus sur OpenGL que sur Direct3D . Je n'ai jamais écrit une ligne de code D3D de ma vie, et j'ai écrit des tutoriels sur OpenGL. Ce que je vais dire n'est donc pas une question de parti pris. C'est simplement une question d'histoire.
Naissance du conflit
Un jour, au début des années 90, Microsoft a regardé autour de lui. Ils ont vu que les SNES et Sega Genesis étaient géniaux, exécutant beaucoup de jeux d'action et autres. Et ils ont vu DOS . Les développeurs ont codé les jeux DOS comme les jeux sur console: directement dans le métal. Contrairement aux consoles, cependant, lorsqu'un développeur qui a créé un jeu SNES savait quel matériel l'utilisateur aurait, les développeurs DOS devaient écrire pour plusieurs configurations possibles. Et c'est un peu plus difficile qu'il n'y paraît.
Et Microsoft avait un plus gros problème: Windows. Vous voyez, Windows voulait posséder le matériel, contrairement à DOS qui permettait aux développeurs de faire n'importe quoi. Posséder le matériel est nécessaire pour avoir une coopération entre les applications. La coopération est exactement ce que les développeurs de jeux - déteste car cela prend des ressources matérielles précieuses qu'ils pourraient utiliser pour être géniaux.
Afin de promouvoir le développement de jeux sur Windows, Microsoft avait besoin d'une API uniforme de bas niveau, fonctionnant sur Windows sans en être ralentie, et surtout cross-hardware. Une seule API pour tous les graphiques, le son et le matériel d'entrée.
Ainsi, DirectX est né.
Des accélérateurs 3D sont nés quelques mois plus tard. Et Microsoft a rencontré des problèmes. Voir, DirectDraw, le composant graphique de DirectX, ne traitait que des graphiques 2D: allouer de la mémoire graphique et effectuer des bits bits entre différentes sections de mémoire allouées.
Microsoft a donc acheté un peu de middleware et l'a transformé en Direct3D version 3. C'était universellement injurié. Et pour cause; regarder le code D3D v3, c'est comme regarder l'Arche de l'Alliance.
Le vieux John Carmack d'Id Software a jeté un coup d'œil à cette poubelle et a dit: "Vis ça!" et a décidé d'écrire vers une autre API: OpenGL.
Vous voyez, une autre partie de la bête à plusieurs têtes qu'est Microsoft était occupée à travailler avec SGI sur une implémentation OpenGL pour Windows. L'idée ici était de courtiser les développeurs d'applications GL: applications de poste de travail. CAD outils, modélisation, ce genre de choses. Les jeux étaient la chose la plus éloignée de leur C'était principalement une chose Windows NT, mais Microsoft a décidé de l'ajouter à Win95 aussi.
Afin d'attirer les développeurs de postes de travail vers Windows, Microsoft a décidé d'essayer de les soudoyer avec l'accès à ces nouvelles cartes graphiques 3D. Microsoft a implémenté le protocole Installable Client Driver: un fabricant de cartes graphiques pourrait remplacer l'implémentation OpenGL du logiciel Microsoft par une implémentation matérielle. Le code pourrait automatiquement utiliser simplement une implémentation matérielle OpenGL si elle était disponible.
Au début, les cartes vidéo grand public n'étaient pas compatibles avec OpenGL. Cela n'a pas empêché Carmack de simplement porter Quake sur OpenGL (GLQuake) sur sa station de travail SGI. Comme nous pouvons le lire dans le readme de GLQuake:
Théoriquement, glquake fonctionnera sur tout OpenGL compatible qui prend en charge les extensions d'objets de texture, mais à moins que ce ne soit un matériel très puissant qui accélère tout ce qui est nécessaire, le jeu ne sera pas acceptable. S'il doit passer par des chemins d'émulation logicielle, les performances seront probablement bien inférieures à une trame par seconde.
En ce moment (mars 1997), le seul matériel opengl standard capable de jouer raisonnablement à glquake est un réalisme inter-graphique, qui est une carte TRÈS chère. 3dlabs a considérablement amélioré ses performances, mais avec les pilotes disponibles, il n'est toujours pas assez bon pour jouer. Certains des pilotes 3dlabs actuels pour les cartes glint et permedia peuvent également planter NT lors de la sortie d'une exécution en plein écran, donc je ne recommande pas d'exécuter glquake sur le matériel 3dlabs.
3dfx a fourni un opengl32.dll qui implémente tout ce dont a besoin glquake, mais ce n'est pas une implémentation opengl complète. Il est très peu probable que d'autres applications opengl fonctionnent avec, alors considérez-le comme un "pilote glquake".
Ce fut la naissance des pilotes miniGL. Ceux-ci ont finalement évolué vers des implémentations OpenGL complètes, car le matériel est devenu suffisamment puissant pour implémenter la plupart des fonctionnalités OpenGL dans le matériel. nVidia a été le premier à proposer une implémentation complète d'OpenGL. De nombreux autres fournisseurs ont eu du mal, ce qui explique pourquoi les développeurs ont préféré Direct3D: ils étaient compatibles sur une plus large gamme de matériel. Finalement, seuls nVidia et ATI (maintenant AMD) sont restés, et les deux avaient une bonne implémentation d'OpenGL.
OpenGL Ascendant
Ainsi, la scène est prête: Direct3D vs OpenGL. C'est vraiment une histoire incroyable, compte tenu de la gravité de D3D v3.
L'OpenGL Architectural Review Board (ARB) est l'organisation responsable de la maintenance d'OpenGL. Ils émettent un certain nombre d'extensions, maintiennent le référentiel d'extensions et créent de nouvelles versions de l'API. L'ARB est un comité composé de nombreux acteurs de l'industrie graphique, ainsi que de certains fabricants de systèmes d'exploitation. Apple et Microsoft ont à plusieurs reprises été membres de l'ARB.
3Dfx sort avec le Voodoo2. C'est le premier matériel capable de faire du multitexturing, ce que OpenGL ne pouvait pas faire auparavant. Alors que 3Dfx était fortement opposé à OpenGL, NVIDIA, fabricant de la prochaine puce graphique multitexturing (la TNT1), a adoré. L'ARB a donc publié une extension: GL_ARB_multitexture, qui permettrait l'accès au multitexturing.
Pendant ce temps, Direct3D v5 sort. Maintenant, D3D est devenu un véritable [~ # ~] api [~ # ~], plutôt que quelque chose qu'un chat pourrait vomir. Le problème? Pas de multitexturation.
Oops.
Maintenant, celui-là ne ferait pas autant de mal qu'il aurait dû, car les gens n'utilisaient pas beaucoup le multitexturing. Pas directement. Le multitexturing nuit beaucoup aux performances, et dans de nombreux cas, cela n'en valait pas la peine par rapport au multi-passage. Et bien sûr, les développeurs de jeux adorent s'assurer que leurs jeux fonctionnent sur du matériel plus ancien, qui n'avait pas de multi-extension, tant de jeux sont livrés sans.
Le D3D a ainsi obtenu un sursis.
Le temps passe et NVIDIA déploie la GeForce 256 (pas la GeForce GT-250; la toute première GeForce), mettant ainsi fin à la concurrence des cartes graphiques pour les deux prochaines années. Le principal argument de vente est la possibilité de faire de la transformation de vertex et de l'éclairage (T&L) dans le matériel. Non seulement cela, NVIDIA aimait tellement OpenGL que son moteur T&L était effectivement l'était OpenGL. Presque littéralement; si je comprends bien, certains de leurs registres ont en fait pris les énumérateurs OpenGL directement comme valeurs.
Direct3D v6 sort. Multitexture enfin mais ... pas de T&L matériel. OpenGL avait toujours avait un pipeline T&L, même si avant le 256 il était implémenté dans le logiciel. Il était donc très facile pour NVIDIA de simplement convertir leur implémentation logicielle en une solution matérielle. Ce ne sera pas avant D3D v7 jusqu'à ce que D3D ait enfin pris en charge le matériel T&L.
Dawn of Shaders, Twilight of OpenGL
Ensuite, GeForce 3 est sorti. Et beaucoup de choses se sont produites en même temps.
Microsoft avait décidé qu'ils n'allaient plus être en retard. Ainsi, au lieu de regarder ce que NVIDIA faisait et de le copier après coup, ils ont pris la position étonnante d'aller vers eux et de leur parler. Et puis ils sont tombés amoureux et avaient une petite console ensemble.
Un divorce désordonné s'ensuivit plus tard. Mais c'est pour une autre fois.
Ce que cela signifiait pour le PC, c'est que GeForce 3 est sorti simultanément avec D3D v8. Et il n'est pas difficile de voir comment GeForce 3 a influencé les shaders de D3D 8. Les pixel shaders de Shader Model 1.0 étaient extrêmement spécifiques au matériel NVIDIA. Il n'y a eu aucune tentative de soustraire le matériel de NVIDIA; SM 1.0 était exactement ce que faisait la GeForce 3.
Quand ATI a commencé à se lancer dans la course aux cartes graphiques hautes performances avec la Radeon 8500, il y a eu un problème. Le pipeline de traitement des pixels du 8500 était plus puissant que les trucs de NVIDIA. Microsoft a donc publié le Shader Model 1.1, qui était essentiellement "quoi que fasse le 8500".
Cela peut ressembler à un échec de la part de D3D. Mais l'échec et le succès sont des questions de degrés. Et épique l'échec se produisait dans OpenGL-land.
NVIDIA aimait OpenGL, donc quand GeForce 3 a frappé, ils ont sorti une multitude d'extensions OpenGL. Propriétaire Extensions OpenGL: NVIDIA uniquement. Naturellement, lorsque le 8500 est apparu, il ne pouvait en utiliser aucun.
Voyez, au moins dans D3D 8 land, vous pouvez exécuter vos shaders SM 1.0 sur du matériel ATI. Bien sûr, vous avez dû écrire de nouveaux shaders pour profiter de la fraîcheur du 8500, mais au moins votre code a fonctionné.
Afin d'avoir des shaders de any kind sur Radeon 8500 dans OpenGL, ATI a dû écrire un certain nombre d'extensions OpenGL. Propriétaire Extensions OpenGL: ATI uniquement. Vous aviez donc besoin d'un chemin de codage NVIDIA et d'un chemin de codage ATI, juste pour avoir shaders du tout.
Maintenant, vous pourriez vous demander: "Où était l'OpenGL ARB, dont le travail consistait à maintenir OpenGL à jour?" Là où de nombreux comités finissent souvent: être stupides.
Vous voyez, j'ai mentionné ARB_multitexture ci-dessus, car il prend en compte profondément tout cela. L'ARB semblait (du point de vue d'un étranger) vouloir éviter complètement l'idée des shaders. Ils ont pensé que s'ils giflaient suffisamment de configurabilité sur le pipeline à fonction fixe, ils pourraient égaler la capacité d'un pipeline de shader.
L'ARB a donc publié extension après extension. Chaque extension avec les mots "texture_env" était une nouvelle tentative de patcher cette conception vieillissante. Vérifiez le registre: entre les extensions ARB et EXT, il y avait huit de ces extensions faites. Beaucoup ont été promus aux versions de base OpenGL.
Microsoft faisait partie de l'ARB à cette époque; ils sont partis au moment où D3D 9 a frappé. Il est donc tout à fait possible qu'ils travaillaient sur Sabotage OpenGL d'une manière ou d'une autre. Personnellement, je doute de cette théorie pour deux raisons. Premièrement, ils auraient dû obtenir l'aide d'autres membres de l'ARB pour ce faire, car chaque membre ne dispose que d'un vote. Et surtout, l'ARB n'avait pas besoin de l'aide de Microsoft pour foutre le cap. Nous en verrons d'autres preuves.
Finalement, l'ARB, probablement menacé à la fois par ATI et NVIDIA (les deux membres actifs) a finalement retiré la tête assez longtemps pour fournir de véritables shaders de style assembleur.
Vous voulez quelque chose d'encore plus stupide?
T&L matériel. Quelque chose qu'OpenGL avait d'abord. Eh bien, c'est intéressant. Pour obtenir les performances maximales possibles du T&L matériel, vous devez stocker vos données de sommet sur le GPU. Après tout, c'est le GPU qui veut réellement utiliser vos données de sommet.
Dans D3D v7, Microsoft a introduit le concept de tampons Vertex. Ils sont alloués des andains de mémoire GPU pour stocker les données de sommet.
Vous voulez savoir quand OpenGL a obtenu son équivalent? Oh, NVIDIA, étant un amoureux de toutes les choses OpenGL (tant qu'il s'agit d'extensions NVIDIA propriétaires), a publié l'extension de la gamme de vertex array lorsque la GeForce 256 a frappé pour la première fois. Mais quand l'ARB a-t-il décidé de fournir des fonctionnalités similaires?
Deux ans plus tard. C'était après ils ont approuvé les vertex et fragments shaders (pixel en langage D3D). C'est le temps qu'il a fallu à l'ARB pour développer une solution multiplateforme pour le stockage des données de vertex dans la mémoire GPU. Encore une fois, quelque chose dont le matériel T&L a besoin pour atteindre des performances maximales.
Une seule langue pour tous les ruiner
Ainsi, l'environnement de développement OpenGL a été fracturé pendant un certain temps. Pas de shaders cross-hardware, pas de stockage de vertex GPU cross-hardware, tandis que les utilisateurs de D3D ont apprécié les deux. Cela pourrait-il empirer?
Vous ... vous pourriez dire ça. Entrez D Labs.
Qui sont-ils, vous pourriez demander? C'est une ancienne entreprise que je considère comme les vrais tueurs d'OpenGL. Bien sûr, l'ineptie générale de l'ARB a rendu OpenGL vulnérable alors qu'il aurait dû être propriétaire de D3D. Mais 3D Labs est peut-être la principale raison pour moi de l'état actuel du marché d'OpenGL. Qu'auraient-ils pu faire pour provoquer cela?
Ils ont conçu le langage d'ombrage OpenGL.
Vous voyez, 3D Labs était une entreprise mourante. Leurs GPU coûteux étaient marginalisés par la pression croissante de NVIDIA sur le marché des stations de travail. Et contrairement à NVIDIA, 3D Labs n'était pas présent sur le marché grand public; si NVIDIA gagnait, ils mourraient.
Ce qu'ils ont fait.
Ainsi, dans le but de rester pertinent dans un monde qui ne voulait pas de leurs produits, 3D Labs s'est présenté à une conférence des développeurs de jeux brandissant des présentations pour ce qu'ils ont appelé "OpenGL 2.0". Ce serait une réécriture complète et à partir de zéro de l'API OpenGL. Et cela a du sens; il y avait un beaucoup de cruft dans l'API d'OpenGL à l'époque (note: ce cruft existe toujours). Regardez simplement comment le chargement de texture et la liaison fonctionnent; c'est semi-arcane.
Une partie de leur proposition était un langage ombragé. Naturellement. Cependant, contrairement aux extensions ARB multiplateformes actuelles, leur langage d'ombrage était "de haut niveau" (C est de haut niveau pour un langage d'ombrage. Oui, vraiment).
Maintenant, Microsoft travaillait sur son propre langage d'ombrage de haut niveau. Ce qu'ils, dans toute l'imagination collective de Microsoft, appelaient ... le High Level Shading Language (HLSL). Mais c'était une approche fondamentalement différente des langues.
Le plus gros problème avec le langage de shader de 3D Labs était qu'il était intégré. Voir, HLSL était un langage défini par Microsoft. Ils ont publié un compilateur pour cela, et il a généré le code d'assemblage Shader Model 2.0 (ou modèles de shader ultérieurs), que vous introduisiez dans D3D. Dans les jours D3D v9, HLSL n'a jamais été directement touché par D3D. C'était une belle abstraction, mais c'était purement facultatif. Et un développeur a toujours eu l'occasion d'aller derrière le compilateur et d'ajuster la sortie pour des performances maximales.
Le langage 3D Labs avait aucun de cela. Vous avez donné au pilote le langage C, et cela a produit un shader. Fin de l'histoire. Pas un shader d'assemblage, pas quelque chose que vous nourrissez d'autre chose. L'objet OpenGL réel représentant un shader.
Cela signifiait que les utilisateurs d'OpenGL étaient ouverts aux caprices des développeurs qui commençaient à peine à compiler des langages de type Assembly. Les bogues du compilateur s'exécutaient rampant dans le nouveau langage d'ombrage OpenGL (GLSL). Pire encore, si vous avez réussi à compiler correctement un shader sur plusieurs plates-formes (aucun exploit), vous avez toujours été soumis aux optimiseurs du jour. Qui n'étaient pas aussi optimales qu'elles pourraient l'être.
Bien que ce soit le plus gros défaut de GLSL, ce n'était pas le seul défaut. Par loin.
Dans D3D, et dans les anciens langages d'assemblage d'OpenGL, vous pouvez mélanger et faire correspondre des vertex et des shaders de fragment (pixel). Tant qu'ils communiquent avec la même interface, vous pouvez utiliser n'importe quel vertex shader avec n'importe quel fragment shader compatible. Et il y avait même des niveaux d'incompatibilité qu'ils pouvaient accepter; un vertex shader pourrait écrire une sortie que le fragment shader n'a pas lu. Et ainsi de suite.
GLSL n'avait rien de tout cela. Les vertex et les shaders de fragments ont été fusionnés ensemble dans ce que 3D Labs a appelé un "objet programme". Donc, si vous vouliez partager des programmes de sommets et de fragments, vous deviez créer plusieurs objets de programme. Et cela a causé le deuxième plus gros problème.
Vous voyez, 3D Labs pensait qu'ils étaient intelligents. Ils ont basé le modèle de compilation de GLSL sur C/C++. Vous prenez un .c ou .cpp et le compilez dans un fichier objet. Ensuite, vous prenez un ou plusieurs fichiers objets et les liez dans un programme. Voilà comment GLSL compile: vous compilez votre shader (sommet ou fragment) en un objet shader. Ensuite, vous placez ces objets shader dans un objet programme et les liez ensemble pour former votre programme réel.
Bien que cela ait permis des idées intéressantes comme avoir des "shaders" de bibliothèque contenant du code supplémentaire que les shaders principaux pouvaient appeler, ce que cela signifiait en pratique était que les shaders étaient compilés - deux fois. Une fois dans la phase de compilation et une fois dans la phase de liaison. Le compilateur de NVIDIA en particulier était connu pour avoir essentiellement exécuté la compilation deux fois. Il n'a pas généré une sorte d'intermédiaire de code objet; il l'a juste compilé une fois et a jeté la réponse, puis l'a à nouveau compilé au moment du lien.
Donc, même si vous souhaitez lier votre vertex shader à deux fragments de shaders différents, vous devez faire beaucoup plus de compilation que dans D3D. D'autant plus que la compilation d'un langage de type C a été entièrement effectuée hors ligne, pas au début de l'exécution du programme.
Il y avait d'autres problèmes avec GLSL. Il semble peut-être mal de rejeter la faute sur 3D Labs, car l'ARB a finalement approuvé et incorporé le langage (mais rien d'autre de leur initiative "OpenGL 2.0"). Mais c'était leur idée.
Et voici la partie vraiment triste: 3D Labs était à droite (surtout). GLSL n'est pas un langage d'ombrage vectoriel comme HLSL à l'époque. Cela était dû au fait que le matériel de 3D Labs était un matériel scalaire (similaire au matériel NVIDIA moderne), mais ils étaient finalement dans la bonne direction dans laquelle de nombreux fabricants de matériel étaient allés avec leur matériel.
Ils avaient raison de choisir un modèle de compilation en ligne pour un langage "de haut niveau". D3D est même passé à cela finalement.
Le problème était que les laboratoires 3D avaient raison au mauvais moment - temps. Et en essayant d'invoquer l'avenir trop tôt, en essayant d'être à l'épreuve du temps, ils ont mis de côté le présent. Cela ressemble à la façon dont OpenGL a toujours eu la possibilité pour la fonctionnalité T&L. Sauf que le pipeline T&L d'OpenGL était toujours utile avant le T&L matériel, tandis que GLSL était un passif avant que le monde ne le rattrape.
GLSL est une bonne langue maintenant. Mais pour le moment? C'était horrible. Et OpenGL en a souffert.
Tombant vers l'apothéose
Bien que je soutienne que 3D Labs a frappé le coup fatal, c'est l'ARB lui-même qui enfoncerait le dernier clou dans le cercueil.
C'est une histoire dont vous avez peut-être entendu parler. Au moment d'OpenGL 2.1, OpenGL rencontrait un problème. Il y avait un beaucoup de cruauté héritée. L'API n'était plus facile à utiliser. Il y avait 5 façons de faire les choses et aucune idée de la plus rapide. Vous pouvez "apprendre" OpenGL avec des tutoriels simples, mais vous n'avez pas vraiment appris l'API OpenGL qui vous a donné de réelles performances et une puissance graphique.
L'ARB a donc décidé de tenter une nouvelle réinvention d'OpenGL. C'était similaire à "OpenGL 2.0" de 3D Labs, mais mieux parce que l'ARB était derrière. Ils l'ont appelé "Longs Peak".
Qu'y a-t-il de si mal à prendre un peu de temps pour améliorer l'API? C'était mauvais parce que Microsoft s'était laissé vulnérable. Voir, ceci était au moment du basculement de Vista.
Avec Vista, Microsoft a décidé d'introduire certains changements indispensables dans les pilotes d'affichage. Ils ont forcé les pilotes à se soumettre au système d'exploitation pour la virtualisation de la mémoire graphique et diverses autres choses.
Alors que l'on peut débattre du bien-fondé de cela ou s'il était réellement possible, le fait demeure le suivant: Microsoft a considéré D3D 10 comme étant Vista (et supérieur) uniquement. Même si vous disposiez d'un matériel qui était capable de D3D 10, vous ne pouviez pas exécuter les applications D3D 10 sans exécuter également Vista.
Vous vous souvenez peut-être aussi que Vista ... euh, disons simplement que cela n'a pas bien fonctionné. Vous aviez donc un système d'exploitation sous-performant, une nouvelle API qui ne fonctionnait que sur ce système d'exploitation et une nouvelle génération de matériel qui nécessaire cette API et ce système d'exploitation pour faire plus que d'être plus rapide que la génération précédente.
Cependant, les développeurs pourraient accéder aux fonctionnalités de la classe D3D 10 via OpenGL. Eh bien, ils le pourraient si l'ARB n'avait pas été occupé à travailler sur Longs Peak.
Fondamentalement, l'ARB a passé une bonne année et demie à deux ans de travail pour améliorer l'API. Au moment où OpenGL 3.0 est sorti, l'adoption de Vista était en place, Win7 était sur le point de mettre Vista derrière eux, et la plupart des développeurs de jeux se moquaient des fonctionnalités de la classe D3D-10 de toute façon. Après tout, le matériel D3D 10 exécutait très bien les applications D3D 9. Et avec la montée en puissance des ports PC-à-console (ou les développeurs de PC qui se lancent dans le développement de la console. Faites votre choix), les développeurs n'avaient plus besoin des fonctionnalités de la classe D3D 10.
Maintenant, si les développeurs avaient eu accès à ces fonctionnalités plus tôt via OpenGL sur les machines WinXP, le développement OpenGL aurait peut-être reçu un coup de pouce bien mérité. Mais l'ARB a raté l'occasion. Et voulez-vous connaître le pire?
Malgré deux précieuses années à tenter de reconstruire l'API à partir de zéro ... ils encore ont échoué et sont revenus au statu quo (à l'exception d'un mécanisme de dépréciation).
Ainsi, non seulement l'ARB a raté une fenêtre d'opportunité cruciale, mais ils n'ont même pas terminé la tâche qui leur a fait manquer cette chance. À peu près épique échouer tout autour.
Et c'est l'histoire d'OpenGL contre Direct3D. Une histoire d'occasions manquées, de stupidité grossière, de cécité volontaire et de folie simple.
J'ai trouvé étrange que tout le monde se concentre sur la base d'utilisateurs, quand la question est "développeurs de jeux", pas "éditeurs de jeux".
Pour moi, en tant que développeur, Linux est un bordel sanglant. Il y a tellement de versions, de gestionnaires de bureau, de kits d'interface utilisateur, etc ... Si je ne veux pas distribuer mon travail en open source, où l'utilisateur peut (essayer de) recompiler pour qu'il corresponde à sa combinaison unique de packages, bibliothèques et paramètres, c'est un cauchemar!
D'un autre côté, Microsoft fournit (la plupart du temps) une compatibilité ascendante et une stabilité de plateforme incroyables. Il est possible de cibler toute une gamme de machines avec un programme d'installation à source fermée, par exemple des ordinateurs exécutant Windows XP, Vista et 7, versions 32 et 64 bits, sans DX approprié ou VC redistributables installés, etc...
Une dernière chose, S'IL VOUS PLAÎT TOUT LE MONDE SUR L'INTERNET ARRÊTE DE COMPARER OPENGL ET DIRECTX! Soit comparer Direct3D vs OpenGL ou ne faites pas cela . DirectX fournit une prise en charge d'entrée, une prise en charge du son, la lecture de films, etc., contrairement à OpenGL.
C'est parce qu'il y a plus d'utilisateurs Windows sur la planète que Linux et Mac. La vérité est que les gens font des choses pour ce qui a le plus gros marché.
Il en va de même pour les téléphones portables: Android et iPhone ont des jeux géniaux mais Windows Mobile et Symbian ne le font pas ...
Parce que Windows a plus de 90% de part de marché, et Linux (puisque vous avez spécifiquement posé des questions sur Linux) a la réputation d'avoir beaucoup d'utilisateurs qui n'aiment pas payer pour les logiciels. Que cela soit vrai ou non, ou non, cela n'a pas d'importance; la perception est là et elle influence les décisions des gens.
Parce que Windows est soutenu par une énorme organisation, qui a décidé il y a plus d'une décennie ils veulent que le développement de jeux se fasse sur leur plate-forme .
Ce n'était pas vrai pour le Mac, et ce n'est pas vrai maintenant. Pas même pour iOS. Apple ne fournit pas d'outils pour le développement de jeux iOS. Mais c'est un marché énorme (il y a plus d'iPhone là-bas que de PC en 1995) avec relativement peu de concurrence, donc les gens le font quand même.
Quant à Linux, il n'y a même pas une sorte d'institution centrale, qui pourrait définir une sorte de priorités. La direction dans laquelle Linux va, est plus moins déterminée par un groupe de programmeurs très bons, mais un peu surnaturels.
Pour créer un jeu PC aujourd'hui, vous avez besoin de beaucoup d'artistes 2D/3D, de concepteurs de jeux, de scripteurs, d'acteurs, de testeurs, etc. En ce qui concerne la programmation réelle, vous pouvez simplement utiliser un moteur de jeu réel (CryEngine, Unreal Engine, Quake Engine, Source Engine). Ainsi, vous pourriez être en mesure de faire le tout sans aucun programmeur réel.
Pour cette raison, et en raison de la nature des entreprises, les programmeurs n'ont pas leur mot à dire sur la plateforme choisie. Et généralement, les gestionnaires recherchent un support, ce que Microsoft prétend offrir, et pour gérer des choses qui sont en quelque sorte saisissables pour leurs réflexions, ce qui n'est pas le cas de l'open source.
Pour cette raison, la plupart des logiciels de développement destinés aux utilisateurs finaux se font sous Windows.
Je travaille pour une entreprise qui crée des jeux flash et n'est donc pas liée à une plateforme particulière. Cependant, nous développons tous sur Windows, car la plupart des outils que nous utilisons ne sont pas disponibles pour Linux.
Comme certains l'ont déjà dit, la partie la plus importante est la base d'utilisateurs. 95% des utilisateurs de PC utilisent Windows. Les joueurs PC utilisent presque exclusivement Windows. Même ceux qui utilisent Mac ou Linux exécutent le plus souvent des jeux Windows via une certaine virtualisation ou émulation (à de très, très rares exceptions près).
Mais la démographie n'est pas tout. Je ne sous-estimerais pas la part que fait Microsoft pour rendre la plateforme plus attrayante pour les développeurs de jeux. Fondamentalement, vous obtenez un ensemble d'outils complet gratuit , le plus important ( XNA Game Studio . Cela permet non seulement le développement pour Windows, mais aussi pour Xbox360 . Et avec la dernière édition, même pour les téléphones WP7. De toute évidence, puisque c'est un outil Microsoft, il utilise DirectX, pas OpenGL.
Ewwww, je ne sais pas. J'utilise Linux presque exclusivement. Je double-amorce sur Windows pour faire des builds Windows, et j'utilise le Mac pour les builds Mac, mais c'est tout.
L'astuce est un cadre multiplateforme que nous avons développé au fil des ans. Nos jeux sont construits en plus de cela et se comportent de manière identique sous Linux/OpenGL, Mac/OpenGL et Windows/Direct3D (et bientôt dans iOS/OpenGL).
Certes, ma société ne fait pas de titres AAA, donc cela peut ne pas s'appliquer à ceux-ci, mais nous faisons des meilleurs jeux occasionnels (voir site Web - CSI: NY, Murder She Wrote et les deux prochains 2011 sont des exemples de titres utilisant des licences importantes, The Lost Cases of Sherlock Holmes 1 and 2 ont également connu un grand succès)
Je n'abandonnerais pas gedit + gcc + gdb + valgrind pour autre chose.
Des outils, des outils, des outils.
C'est à cela que cela revient. Développez sur Windows et vous avez accès à certains des meilleurs outils de développement de la planète. Rien ne se rapproche même à distance du débogueur de Visual Studio, les runtime de débogage DirectX sont impressionnants, PIX est génial, et des équivalents comparables n'existent tout simplement pas sur d'autres plateformes/API. Bien sûr, il y a de bonnes choses là-bas; Je ne dis pas que les outils sur d'autres plateformes sont mauvais, mais ceux que MS fournit sont tellement en avance sur le pack (exception honorable: Valgrind) que ce n'est même pas drôle.
L'essentiel est que ces outils vous aident. Ils vous aident à faire avancer les choses, ils vous aident à être productif, ils vous aident à vous concentrer sur les erreurs dans votre propre code plutôt que de lutter avec une API qui ne se comporte jamais comme indiqué.
J'ai donc passé en revue toutes ces réponses, et en tant que développeur de jeux qui a du code sur les jeux de console qui ont été sur les étagères Walmart, j'ai une réponse très différente.
Distribution.
Voyez, si vous voulez être sur une console Nintendo, vous devez obtenir la permission de Nintendo, acheter dans les usines de Nintendo, payer les frais généraux de Nintendo, négocier avec Walmart, gérer l'entreposage, vous avez besoin d'argent à l'avance pour fabriquer, imprimer des boîtes, expédier , pour faire toutes les assurances, et cetera.
Si vous voulez sur la XBox, bien sûr qu'il y a du XBLA, mais vous avez toujours besoin de la bénédiction de Microsoft, vous devez attendre votre tour en ligne, c'est des dizaines de milliers de dollars juste pour sortir un patch, etc.
Sur iOS, vous avez toujours besoin d'Apple, et ils peuvent (et font) vous tirer capricieusement.
Sur Steam, vous avez toujours besoin de l'autorisation ou du feu vert de Valve, et de beaucoup d'argent.
.
Sous Windows? Vous créez un site Web et un bouton de téléchargement.
.
Je ne dis pas que les autres plates-formes n'ont pas de valeur. Mais il y a donc * beaucoup * de trucs horribles qui se passent lorsque vous essayez de développer un jeu, cela pour moi, la promesse de pouvoir simplement gifler un binaire sur un site et se concentrer sur le travail - au moins pour commencer - réduit vraiment beaucoup de barrières de défaillance potentielles.
"On pourra faire le port XBLA plus tard, quand les choses seront stables".
Et dans une moindre mesure, cela est également bien pour Linux, et si sept clients sont bons, vous pouvez commencer par là.
Mais Windows a trois avantages massifs: un développement véritablement ouvert, un déploiement véritablement ouvert et une base de clients très importante et très active qui s'intéresse aux choses originales.
Il est difficile d'imaginer où je préfère commencer.
La réponse est évidente. L'écriture d'un jeu a pour objectif de gagner de l'argent. Plus les utilisateurs finaux utilisent Windows, il y a donc un marché plus grand et vous vous attendez à gagner plus d'argent avec un jeu Windows qu'avec un jeu Linux. C'est si simple.
Si jamais vous vous posez la question "Pourquoi quelqu'un fait-il ...", rappelez-vous simplement que l'argent fait tourner le monde.
- Inertie. Si vous avez utilisé Windows dans le passé, passer à autre chose est un problème. Si vous utilisez Windows, DirectX est plus facile et plus susceptible de bien fonctionner qu'OpenGL.
- Part de marché. La part de marché de Windows sur le bureau est plus grande que celle d'OS X qui est à son tour plus grande que celle de Linux. L'argent parle.
- Marque. DirectX est mieux connu que des choses comme SDL (qui est le genre de chose dont vous auriez besoin pour répliquer certaines fonctionnalités de DirectX qui vont au-delà d'OpenGL).
- Moins de confusion. Est-ce que Linux de l'utilisateur ne prend en charge que OpenGL 1.4 ou OpenGL 2+? Pouvez-vous utiliser un tutoriel OpenGL 2.0 comme Une introduction à OpenGL moderne. Chapitre 1: Le pipeline graphique sur votre version Linux?
De nos jours, Linux est plus une curiosité en matière de développement de jeux et la plupart des développeurs feraient mieux de faire fiscalement une version de port OS X avant une version de Linux (voir des choses comme Steam). Même alors, le marché des consoles vaut plus que ces deux plateformes combinées pour les jeux ...
Si vous vouliez mono plate-forme DirectX est très bien. Si vous voulez être multiplateforme, il y a de fortes chances que vous deviez utiliser OpenGL sur au moins certaines des autres plates-formes.
Je pense que vous devriez en savoir plus sur l'histoire de DirectX et Cet article .
Je pense que MS a choisi DX plutôt que openGL car ils aiment empêcher les gens d'utiliser leur propre système d'exploitation.
Beaucoup a à voir avec la politique et le contrôle. À la fin des années 90, SGI et MS ont en fait accepté de conjuguer leurs efforts:
http://en.wikipedia.org/wiki/Fahrenheit_graphics_API
SGI a investi massivement dans le projet, pas MS. SGI avait besoin de MS plus que MS n'avait besoin de SGI. Le reste appartient à l'histoire.
D3D et OpenGL sont deux API très différentes, c'est au développeur de choisir celle qui convient à vos besoins.
Tout simplement parce que Linux a horriblement échoué en tant que système de bureau. Comme quelqu'un l'a souligné plus tôt, Linux est un gâchis pour les développeurs (différentes bibliothèques, boîtes à outils d'interface utilisateur, etc.)
Un autre problème est le freetardisme et le manque de support pour les logiciels propriétaires. Nvidia fournit toujours de bons pilotes (propriétaires) pour Linux, mais Ubuntu et d'autres distributions ne les expédient pas. Il n'y a également aucune interface de pilote binaire disponible pour Linux comme pour Windows. (Il existe un fichier texte appelé binaryApiNonsense.txt ou quelque chose dans les sources du noyau). Cela dit, seul le matériel Nvidia est correctement pris en charge sous Linux. Vous pouvez jouer à la plupart des jeux de logiciels d'identification en utilisant le matériel Nvidia sous Linux.
Outils de développement de la prochaine chose. MSFT fournit un excellent support C++ et le débogueur Visual Studio est meilleur que gdb en ce qui concerne C++. Enfin et surtout, il manque d'autres outils tels que Photoshop. De plus, .net vous permet de créer rapidement des outils graphiques. De nombreux studios de jeux codent leurs outils pour un usage interne à l'aide du framework .net.
J'ai presque oublié: le système graphique est horrible, à l'époque où ils venaient de porter X11, car c'était la chose la plus simple qui fonctionnait. Ils n'ont pas réussi à concevoir et à mettre en œuvre correctement un système graphique moderne qu'OSx et Win possèdent.