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 très 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 connais 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. Donc, ce que je vais dire n’est pas une question de partialité. 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 la SNES et Sega Genesis être géniaux, avec beaucoup de jeux d’action et autres. Et ils ont vu DOS . Les développeurs ont codé les jeux DOS comme des jeux de console: directement sur du métal. Contrairement aux consoles cependant, où un développeur qui a créé un jeu SNES connaissait le matériel dont disposerait l'utilisateur, les développeurs DOS devaient écrire pour plusieurs configurations possibles. Et c'est plutôt 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 laissait les développeurs faire n'importe quoi. Posséder le matériel est nécessaire pour assurer la coopération entre les applications. La coopération est exactement ce que les développeurs de jeux détestent, car elle nécessite d’importantes ressources matérielles qu’ils pourraient utiliser pour devenir géniaux.

Afin de promouvoir le développement de jeux sous Windows, Microsoft avait besoin d’une API uniforme, de bas niveau, fonctionnant sous Windows sans être ralentie, et surtout multi-matériels . Une seule API pour tous les graphiques, le son et le matériel d'entrée.

Ainsi, DirectX est né.

Les accélérateurs 3D sont nés quelques mois plus tard. Et Microsoft a eu des ennuis. Voir DirectDraw, le composant graphique de DirectX, ne traitait que des graphiques 2D: allouer de la mémoire graphique et effectuer des mélanges de bits entre différentes sections de mémoire allouées.

Donc, Microsoft a acheté un peu de middleware et l'a transformé en Direct3D Version 3. Il a été universellement critiqué. Et avec raison. 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 corbeille et a dit: "Fous ça!" et a décidé d'écrire vers une autre API: OpenGL.

Vous voyez, une autre partie de la bête aux multiples têtes que Microsoft avait été 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 typiques: les applications de poste de travail. Les outils de CAO, la modélisation, ce genre de chose. Les jeux étaient la chose la plus distante dans leur esprit. Il s’agissait principalement de Windows NT, mais Microsoft a également décidé de l’ajouter à Win95.

Afin d'attirer les développeurs de stations de travail vers Windows, Microsoft a décidé d'essayer de les corrompre en leur donnant accès à ces nouvelles cartes graphiques 3D. Microsoft a mis en œuvre le protocole Installable Client Driver: un fabricant de cartes graphiques pourrait remplacer l'implémentation logicielle OpenGL de Microsoft par une implémentation matérielle. Le code pourrait automatiquement utiliser une implémentation OpenGL matérielle, le cas échéant.

À l'origine, les cartes vidéo grand public ne prenaient pas en charge OpenGL. Cela n'a pas empêché Carmack de simplement porter Quake sur OpenGL (GLQuake) sur son poste de travail SGI. Comme on peut le lire dans le readme de GLQuake:

Théoriquement, glquake fonctionnera sur tout OpenGL conforme prenant 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 un chemin d'émulation de logiciel, les performances seront probablement bien inférieures à une image par seconde.

En mars 1997, le seul matériel opengl standard capable de jouer de manière raisonnable est un réalisme intergraphe, une carte TRES chère. 3dlabs a amélioré leurs performances de manière significative, 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 provoquer le blocage de NT lors de la sortie d'un fonctionnement en plein écran. Je vous déconseille donc d'exécuter glquake sur du matériel 3dlabs.

3dfx a fourni un opengl32.dll qui implémente tout ce dont glquake a besoin, mais ce n'est pas une implémentation opengl complète. Il est très peu probable que d'autres applications opengl fonctionnent avec cette application, considérez-la donc fondamentalement comme un «pilote glquake».

Ce fut la naissance des pilotes miniGL. Celles-ci ont finalement évolué vers des implémentations OpenGL complètes, à mesure que le matériel devenait suffisamment puissant pour implémenter la plupart des fonctionnalités OpenGL dans le matériel. nVidia a été le premier à proposer une implémentation OpenGL complète. De nombreux autres fournisseurs ont eu des difficultés, raison pour laquelle les développeurs ont préféré Direct3D: ils étaient compatibles avec une gamme plus étendue de matériel. Finalement, seuls nVidia et ATI (maintenant AMD) sont restés et les deux ont eu une bonne implémentation OpenGL.

OpenGL Ascendant

Ainsi, la scène est définie: 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 de 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 fabricants de systèmes d'exploitation. Apple et Microsoft ont été à plusieurs reprises membres de l'ARB.

3Dfx sort avec le Voodoo2. C'est le premier matériel capable de faire du multitexturing, ce qu'OpenGL ne pouvait pas faire auparavant. Alors que 3Dfx était fermement opposé à OpenGL, NVIDIA, fabricant de la prochaine puce graphique multitexturation (la TNT1), a adoré. L'ARB a donc publié une extension: GL_ARB_multitexture, qui permettrait d'accéder au multitexturing.

Pendant ce temps, Direct3D v5 est sorti. Maintenant, D3D est devenu une API réelle , plutôt que ce qu'un chat pourrait vomir. Le problème? Pas de multitexturing.

Oops.

Maintenant, celui-ci ne ferait pas autant mal qu'il aurait dû, car les utilisateurs n'utilisaient pas beaucoup le multitexturing. Pas directement. Le multitexturing nuit beaucoup aux performances et, dans de nombreux cas, cela ne valait pas la peine comparé au multi-dépassement. Et bien sûr, les développeurs de jeux aiment faire en sorte que leurs jeux fonctionnent sur du matériel plus ancien, qui ne faisait pas appel au multitexturation, et de nombreux jeux livrés sans ce matériel.

D3D se voit donc accorder un sursis.

Le temps passe et NVIDIA utilise la GeForce 256 (pas la GeForce GT-250; la toute première GeForce), qui met pratiquement fin à la concurrence dans les cartes graphiques pour les deux prochaines années. Le principal argument de vente est la possibilité d'effectuer la transformation de sommet et l'éclairage (T & L) dans le matériel. De plus, NVIDIA a tellement aimé OpenGL que leur moteur T & L était effectivement OpenGL. Presque littéralement; si je comprends bien, certains de leurs registres prenaient en réalité directement les énumérateurs OpenGL comme valeurs.

Direct3D v6 est sorti. Multitexture enfin mais ... pas de matériel T & L. OpenGL avait toujours eu un pipeline T & L, même avant le 256, il était implémenté dans le logiciel. Il était donc très facile pour NVIDIA de convertir leur implémentation logicielle en solution matérielle. Ce ne serait pas avant D3D v7 avant que D3D ait enfin pris en charge le matériel T & L.

Aube des Shaders, crépuscule d'OpenGL

Ensuite, GeForce 3 est sorti. Et beaucoup de choses se sont passées en même temps.

Microsoft avait décidé qu'ils ne seraient plus en retard. Ainsi, au lieu de regarder ce que faisait NVIDIA et de le copier après coup, ils ont pris l’étonnante position de s’adresser à eux et de leur parler. Et puis ils sont tombés amoureux et ont eu une petite console ensemble.

Un divorce compliqué s'ensuivit plus tard. Mais c'est pour une autre fois.

Cela signifiait pour le PC que GeForce 3 était 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 de NVIDIA. Aucune tentative n'a été faite pour extraire le matériel de NVIDIA; SM 1.0 était exactement ce que la GeForce 3 faisait.

Lorsque ATI a commencé à se lancer dans la course aux cartes graphiques de performance avec la Radeon 8500, un problème est survenu. Le pipeline de traitement des pixels du 8500 était plus puissant que celui de NVIDIA. Ainsi, Microsoft a publié Shader Model 1.1, qui était essentiellement "Quoi que fasse le 8500".

Cela peut sembler être un échec de la part de D3D. Mais l'échec et le succès sont une affaire de degrés. Et un échec épique se produisait dans OpenGL-land.

NVIDIA aimait OpenGL, alors quand GeForce 3 est apparue, ils ont sorti de nombreuses extensions OpenGL. Extensions propriétaires OpenGL: NVIDIA uniquement. Naturellement, lorsque le 8500 est arrivé, il ne pouvait en utiliser aucun.

Voir, au moins dans D3D 8 Land, vous pouvez exécuter vos shaders SM 1.0 sur du matériel ATI. Bien sûr, vous deviez écrire de nouveaux shaders pour profiter de la fraîcheur du 8500, mais au moins votre code fonctionnait .

Afin d’avoir des shaders de tout type sur Radeon 8500 dans OpenGL, ATI devait écrire un certain nombre d’extensions OpenGL. Extensions propriétaires OpenGL: ATI uniquement. Il fallait donc un chemin de code NVIDIA et un chemin de code ATI, juste pour avoir des shaders .

Maintenant, vous pourriez demander: "Où était l'OpenGL ARB, qui était chargé de maintenir OpenGL à jour?" Là où beaucoup de comités finissent souvent par être stupides.

Vous voyez, j'ai mentionné ARB_multitexture ci-dessus parce que cela prend en compte tout cela. L'ARB semblait (du point de vue d'un étranger) vouloir éviter complètement l'idée de shaders. Ils ont estimé que s’ils plaçaient suffisamment de possibilités de configuration sur le pipeline à fonction fixe, ils pourraient égaler la capacité d’un pipeline de shader.

Donc, l'ARB a publié extension après extension. Chaque extension avec les mots "texture_env" était une nouvelle tentative de correction de cette conception vieillissante. Vérifiez le registre: entre les extensions ARB et EXT, huit de ces extensions ont été réalisées. Beaucoup ont été promus aux versions de base d'OpenGL.

Microsoft faisait partie de l'ARB à cette époque; ils sont partis à peu près au moment où D3D 9 a frappé. Il est donc tout à fait possible qu'ils travaillent à saboter 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 la CRÉA, car chaque membre n’avait qu’une voix. Et plus important encore, l'ARB n'a pas eu besoin de l'aide de Microsoft pour tout gâcher. Nous verrons d'autres preuves de cela.

Finalement, ARB, probablement sous la menace d'ATI et de NVIDIA (deux membres actifs), a finalement tiré la tête assez longtemps pour fournir de véritables shaders de type assemblage.

Tu veux quelque chose d'encore plus stupide?

Matériel T & L. Quelque chose avait été ouvert par OpenGL . Eh bien, c'est intéressant. Pour tirer le maximum des performances possibles de T & L matériel, vous devez stocker vos données de sommet sur le GPU. Après tout, c’est le GPU qui souhaite utiliser vos données de sommet.

Dans D3D v7, Microsoft a introduit le concept de mémoire tampon Vertex. Ce sont des bandes de mémoire GPU allouées pour stocker les données de sommet.

Vous voulez savoir quand OpenGL a obtenu son équivalent? Oh, NVIDIA, étant un amoureux de tout ce qui concerne OpenGL (tant qu’il s’agit d’extensions propriétaires NVIDIA), a publié l’extension de la plage de sommets au moment de la première utilisation de la GeForce 256. Mais quand l'ARB a-t-il décidé de fournir une fonctionnalité similaire?

Deux ans plus tard . C'était après qu'ils aient approuvé les shaders de vertex et de fragment (pixel en langage D3D). C’est le temps qu’a pris l’ARB à développer une solution multiplate-forme pour stocker les données de vertex dans la mémoire du processeur graphique. Là encore, T & L a besoin de matériel pour atteindre des performances optimales.

Une langue pour tous les ruiner

L’environnement de développement OpenGL a donc été fracturé pendant un certain temps. Pas de shaders cross-hardware, pas de stockage de vertex GPU cross-hardware, alors que les utilisateurs de D3D ont profité des deux. Cela pourrait-il empirer?

Tu ... tu pourrais dire ça. Entrez 3D Labs .

Qui sont-ils, vous pourriez demander? C’est une entreprise disparue que je considère comme le véritable tueur d’OpenGL. Bien sûr, l’inefficacité générale de l’ARB a rendu OpenGL vulnérable alors qu’il aurait dû posséder D3D. Mais 3D Labs est peut-être la principale raison qui me fait penser à l'état actuel du marché d'OpenGL. Qu'est-ce qu'ils auraient pu faire pour causer ça?

Ils ont conçu le langage de masquage OpenGL.

Vous voyez, 3D Labs était une entreprise mourante. Leurs GPU onéreux é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 pertinents dans un monde qui ne voulait pas de leurs produits, 3D Labs s'est présenté à une conférence de développeurs de jeux avec des présentations pour ce qu'ils ont appelé "OpenGL 2.0". Ce serait une réécriture complète de l’API OpenGL à partir de zéro. Et cela a du sens; L'API d'OpenGL était très cruelle à l'époque (note: cette crue existe toujours). Il suffit de regarder comment le chargement et la liaison des textures fonctionnent. c'est semi-arcanique.

Une partie de leur proposition était un langage ombré. Naturellement. Cependant, contrairement aux extensions ARB multi-plateformes actuelles, leur langage d’ombrage était «de haut niveau» (C est un niveau élevé pour un langage d’ombrage. Oui, vraiment).

Maintenant, Microsoft travaillait sur son propre langage d’ombrage de haut niveau. Dans l’ensemble de l’imaginaire collectif de Microsoft, ils ont appelé le langage HLSL (High Level Shading Language). Mais leur approche des langues était fondamentalement différente.

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 et généré un code d'assemblage Shader Model 2.0 (ou des modèles de shader ultérieurs), que vous alimenteriez 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 de passer derrière le compilateur et d’ajuster le résultat pour obtenir des performances maximales.

Le langage 3D Labs n'avait rien de tout cela. Vous avez donné au conducteur le langage semblable à C et cela a produit un shader. Fin de l'histoire. Pas un assembleur, pas quelque chose qui nourrit 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 venaient de se familiariser avec la compilation de langages de type assembleur. Les bogues du compilateur ont été généralisés dans le GLSL (OpenGL Shading Language) récemment baptisé. Pire, si vous réussissiez à faire compiler correctement un shader sur plusieurs plates-formes (ce qui n'est pas une mince affaire), vous restiez soumis aux optimiseurs du jour. Lesquelles n'étaient pas aussi optimales qu'elles pourraient l'être.

Bien que c’était la plus grande faiblesse de GLSL, ce n’était pas la seule. De loin .

Dans D3D et dans les langages d'assemblage plus anciens d'OpenGL, vous pouvez mélanger et assortir des shaders de vertex et 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 compatible. Et il y avait même des niveaux d'incompatibilité qu'ils pouvaient accepter; un vertex shader pourrait écrire un résultat que le fragment shader n'a pas lu. Et ainsi de suite.

GLSL n'avait rien de tout cela. Les shaders de vertex et de fragment ont été fusionnés dans ce que 3D Labs a appelé un "objet programme". Donc, si vous voulez partager des programmes de sommets et de fragments, vous devez 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 fichier .c ou .cpp et le compilez dans un fichier objet. Ensuite, vous prenez un ou plusieurs fichiers objet et les liez dans un programme. C'est ainsi que GLSL se compile: vous compilez votre shader (sommet ou fragment) en un objet shader. Ensuite, vous placez ces objets shader dans un objet programme et vous les liez ensemble pour former votre programme réel.

Bien que cela ait permis des idées intéressantes potentielles comme avoir des shaders "de bibliothèque" contenant du code supplémentaire que les shaders principaux pouvaient appeler, cela signifiait en pratique que les shaders étaient compilés deux fois . Une fois au stade de la compilation et une fois au stade de la liaison. Le compilateur de NVIDIA en particulier était connu pour exécuter essentiellement la compilation deux fois. Cela 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 compilé à nouveau au moment de la liaison.

Ainsi, même si vous souhaitez lier votre vertex shader à deux fragments différents, vous devez effectuer beaucoup plus de compilation que dans D3D. D'autant que la compilation d'un langage de type C a été réalisée hors ligne , et non au début de l'exécution du programme.

Il y avait d'autres problèmes avec GLSL. Peut-être semble-t-il erroné de blâmer 3D Labs, puisque l'ARB a finalement approuvé et incorporé le langage (mais rien de plus de son initiative "OpenGL 2.0"). Mais c'était leur idée.

Et voici la partie vraiment triste: 3D Labs avait raison (principalement). GLSL n’est pas un langage d’ombrage à base de vecteur comme HLSL l’était à l’époque. En effet, le matériel de 3D Labs était un matériel scalaire (similaire au matériel NVIDIA moderne), mais ils étaient finalement dans la même direction que de nombreux fabricants de matériel.

Ils avaient raison de choisir un modèle de compilation en ligne pour un langage de "haut niveau". D3D a même opté pour cela.

Le problème était que 3D Labs avait raison au mauvais moment . Et en essayant d'appeler trop tôt l'avenir, en essayant d'être à l'épreuve du futur, ils ont écarté le présent . Cela ressemble à la manière dont OpenGL a toujours eu la possibilité d’utiliser la fonctionnalité T & L. Sauf que le pipeline T & L d'OpenGL était toujours utile avant le matériel T & L, 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.

Tomber vers l'apothéose

Bien que je maintienne que 3D Labs a porté 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. À l'époque d'OpenGL 2.1, OpenGL rencontrait un problème. Il y avait beaucoup d'héritage cruel. L'API n'était plus facile à utiliser. Il y avait 5 façons de faire les choses, et aucune idée de ce qui était le plus rapide. Vous pouvez "apprendre" OpenGL avec de simples tutoriels, mais vous n'avez pas vraiment appris l'API OpenGL qui vous donnait des performances et une puissance graphique réelles.

Ainsi, l'ARB a décidé de tenter une autre réinvention d'OpenGL. Cela ressemblait à "OpenGL 2.0" de 3D Labs, mais c'était mieux car ARB était derrière. Ils l'appelaient "Longs Peak".

Pourquoi est-il si difficile de prendre un peu de temps pour améliorer l'API? C'était mauvais parce que Microsoft s'était laissé vulnérable. Voir, ce fut au moment du passage Vista.

Avec Vista, Microsoft a décidé d’apporter certaines modifications indispensables aux pilotes d’affichage. Ils ont obligé les pilotes à se soumettre au système d'exploitation pour la virtualisation de la mémoire graphique et diverses autres choses.

Bien que l’on puisse en débattre sur le bien-fondé ou sur la possibilité de le faire, il n'en reste pas moins que Microsoft considère D3D 10 comme étant Vista (et supérieur) uniquement. Même si votre matériel était compatible avec D3D 10, vous ne pouvez pas exécuter d’applications D3D 10 sans exécuter également Vista.

Vous vous souviendrez peut-être aussi que Vista ... hum, disons simplement que cela n'a pas bien fonctionné. Vous disposiez donc d’un système d’exploitation sous-performant, d’une nouvelle API qui ne fonctionnait que sur ce système d’exploitation et d’une nouvelle génération de matériel nécessitant cette API et ce système d’exploitation pour être plus rapide que la génération précédente.

Cependant, les développeurs pouvaient accéder aux fonctionnalités D3D 10-class via OpenGL. Eh bien, ils le pourraient si la CRÉA n’avait pas été occupée par Longs Peak.

Fondamentalement, la CRÉF a consacré un bon travail d’une année et demie à deux ans à améliorer l’API. Au moment où OpenGL 3.0 est sorti, l'adoption de Vista était terminée, Win7 était sur le point de laisser Vista derrière eux, et la plupart des développeurs de jeux ne se souciaient de toute façon pas des fonctionnalités de la classe D3D-10. Après tout, le matériel D3D 10 exécutait parfaitement les applications D3D 9. Et avec la montée en puissance des ports de console à console (ou de développeurs de PC qui se lancent dans le développement de consoles. Faites votre choix), les développeurs n’avaient pas besoin de fonctionnalités D3D 10.

Désormais, si les développeurs avaient déjà accès à ces fonctionnalités via OpenGL sur des machines WinXP, le développement OpenGL aurait peut-être reçu un coup de pouce bien nécessaire. Mais les ARB ont raté leur chance. Et voulez-vous connaître le pire?

Bien qu'ils aient passé deux précieuses années à tenter de reconstruire l'API à partir de zéro ... ils ont quand même échoué et sont simplement revenus au statu quo (à l'exception d'un mécanisme de dépréciation).

Ainsi, non seulement la CRÉA a raté une fenêtre d'opportunité cruciale , mais elle n'a même pas accompli la tâche qui lui a fait perdre de vue cette occasion. Quasiment épique échouer tout autour.

Et c'est l'histoire d'OpenGL contre Direct3D. Une histoire d'opportunités manquées, de stupidité flagrante, d'aveuglement volontaire et de folie simple.

J'ai trouvé étrange que tout le monde se concentre sur la base d'utilisateurs, lorsqu'il s'agit de «développeurs de jeux», pas de «rédacteurs de jeux».

Pour moi, en tant que développeur, Linux est un foutoir. 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, l'utilisateur peut (essayer de) le recompiler de manière à ce qu'il corresponde à sa combinaison unique de paquets, bibliothèques et paramètres, c'est un cauchemar !

D'autre part, Microsoft fournit (la plupart du temps) une incroyable compatibilité ascendante et une stabilité de plate-forme. 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 des versions 7, 32 et 64 bits, sans les redistribuables DX ou VC appropriés, etc.

Une dernière chose, s’IL VOUS PLAÎT TOUT LE MONDE SUR INTERNET ARRÊTEZ COMPARANT OPENGL ET DIRECTX! Comparez Direct3D à OpenGL ou ne le faites pas . DirectX prend en charge les entrées, le 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 fabriquent des produits pour le marché le plus important.
La même chose vaut pour les téléphones mobiles: Android et iPhone ont des jeux impressionnants, mais Windows Mobile et Symbian ne ...

Comme Windows détient plus de 90% du marché et que Linux (puisque vous avez spécifiquement posé des questions sur Linux) a la réputation de compter de nombreux utilisateurs qui n’aiment pas payer pour un logiciel. Que ce soit vrai ou non, c'est sans importance; la perception est là et influence les décisions des gens.

Windows étant soutenu par une énorme organisation, il y a plus de dix ans, ils ont décidé qu'ils souhaitaient 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'iPhones que de PC en 1995) avec relativement peu de concurrence, donc les gens le font quand même.

Pour ce qui est de Linux, il n’ya même pas une sorte d’institution centrale qui puisse définir une quelconque priorité. La direction dans laquelle Linux évolue est davantage déterminée par un groupe de très bons programmeurs, mais légèrement déréglés.

Pour créer un jeu PC aujourd'hui, vous avez besoin de beaucoup d'artistes 2D / 3D, de concepteurs de jeux, de scénaristes, 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). Donc, vous pourrez peut-être faire le tout sans aucun programmeur réel.

Pour cette raison, et en raison de la nature des entreprises, les programmeurs n’ont pas grand-chose à dire sur la plate-forme choisie. Et, de manière générale, les responsables recherchent un support, ce que Microsoft prétend proposer, et traitent des problèmes qui peuvent en quelque sorte être saisissants pour leurs modèles de pensée, contrairement à l'open source.

Pour cette raison, la plupart des logiciels commerciaux destinés aux utilisateurs finaux sont développés sous Windows.
Je travaille pour une entreprise qui crée des jeux flash et qui n'est donc pas liée à une plate-forme particulière. Cependant, nous développons tous sous 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 sur PC utilisent presque exclusivement Windows. Même ceux qui utilisent Mac ou Linux exécutent le plus souvent des jeux Windows via une virtualisation ou une émulation (à de très rares exceptions près).

Mais la démographie n'est pas tout. Je ne sous-estimerais pas le rôle de Microsoft pour rendre la plate-forme plus attrayante pour les développeurs de jeux. En gros, vous avez accès à un ensemble d’outils complet et gratuit , principalement à XNA Game Studio . Cela permet non seulement le développement pour Windows, mais également pour la Xbox 360 . Et avec la dernière édition, même pour les téléphones WP7. Évidemment, comme c'est un outil Microsoft, il utilise DirectX, pas OpenGL.

Ewwww, je pas. J'utilise presque exclusivement Linux. Je double-amorçage sur Windows pour créer des versions de Windows et utiliser les versions de Mac pour les versions de Mac, mais c'est tout.

Le truc, c'est un framework multiplateforme que nous avons développé au fil des ans. Nos jeux sont construits à partir de cela et se comportent de manière identique dans Linux / OpenGL, Mac / OpenGL et Windows / Direct3D (et bientôt dans iOS / OpenGL).

Certes, ma société ne fabrique pas de titres AAA, elle ne s’applique donc peut-être pas à ces jeux, mais nous réalisons des jeux tout à fait décontractés (voir site Web - CSI: NY, Murder She Wrote et les deux prochaines publications en 2011 sont des exemples de titres utilisant des licences importantes, The Les affaires perdues de Sherlock Holmes 1 et 2 ont également été couronnées de succès)

Je n'abandonnerais jamais gedit + gcc + gdb + valgrind.

1. Inertie. Si vous avez déjà utilisé Windows par le passé, passer à autre chose est une tâche ardue. Si vous utilisez Windows DirectX, il est plus facile et plus susceptible de fonctionner que OpenGL.
2. Part de marché. La part de marché de Windows sur le bureau est supérieure à celle d’OS X, qui à son tour est supérieure à celle de Linux. L'argent parle.
3. Marque. DirectX est mieux connu que des choses comme SDL (c'est le genre de choses dont vous auriez besoin pour répliquer certaines fonctionnalités de DirectX qui vont au-delà d'OpenGL).
4. Moins de confusion. Est-ce que l'utilisateur Linux ne supportera que OpenGL 1.4 ou OpenGL 2+? Pouvez-vous utiliser un tutoriel OpenGL 2.0 comme une introduction à OpenGL moderne. Chapitre 1: Le pipeline de graphiques 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 d’utiliser fiscalement une version de port OS X avant une version de Linux (voir des choses comme Steam). Même dans ce cas, le marché des consoles vaut plus que ces deux plates-formes combinées pour les jeux ...

Si vous vouliez utiliser une plateforme mono, DirectX convient. Si vous voulez être multi-plateforme, il y a de fortes chances que vous deviez utiliser OpenGL sur au moins certaines des autres plates-formes.

La réponse est évidente. L’écriture d’un jeu a pour objectif de gagner de l’argent. De plus en plus d'utilisateurs finaux utilisent Windows, par conséquent, le marché est plus important 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 que l'argent fait tourner le monde.

Outils, outils, outils.

C'est ce que cela revient à. Développez sur Windows et accédez à certains des meilleurs outils de développement de la planète. Rien ne vient même à distance proche du débogueur de Visual Studio, les runtime de débogage de DirectX sont géniaux, PIX est génial, et des équivalents comparables n'existent tout simplement pas sur d'autres plates-formes / API. Bien sûr, il y a quelques bonnes choses là-bas; Je ne dis pas que les outils sur d'autres plates-formes sont mauvais, mais ceux fournis par MS sont tellement en avance sur le peloton (exception honorable: Valgrind) qu'ils ne sont même pas drôles.

En bout de ligne, 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 vous battre avec une API qui ne se comporte jamais comme prévu.

J'ai donc passé en revue toutes ces réponses et, en tant que développeur de jeux disposant de code sur des jeux de console déjà installés sur des tablettes Walmart, j'ai une réponse très différente.

Distribution.

Vous 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, traiter avec l'entreposage, vous avez besoin d'argent pour fabriquer, imprimer, imprimer des boîtes , faire toutes les assurances, et cetera.

Si vous voulez sur la XBox, bien sûr, il y a XBLA, mais vous avez toujours besoin de la bénédiction de Microsoft, vous devez attendre votre tour, il faut des dizaines de milliers de dollars pour publier un correctif, etc.

Sur iOS, vous avez toujours besoin de l'accord d'Apple, et ils peuvent (et le font) vous tirer de manière capricieuse.

Sur Steam, vous avez toujours besoin de l'autorisation de Valve ou de feu vert, ainsi que de beaucoup d'argent.

.

Sur Windows? Vous configurez un site Web et un bouton de téléchargement.

.

Je ne dis pas que les autres plates-formes ne sont pas utiles. Mais il y a tellement * de * choses horribles qui se passent lorsque vous essayez de développer un jeu, que pour moi, la promesse de pouvoir gifler un fichier binaire sur un site et de se concentrer sur le travail - au moins pour commencer - réduit vraiment beaucoup d'obstacles d'échec potentiels.

"Nous pouvons faire le portage XBLA plus tard, quand les choses seront stables".

Et dans une moindre mesure, cela convient également pour Linux, et si sept clients sont bons, vous pouvez commencer par là.

Mais Windows présente trois avantages considérables: un développement réellement ouvert, un déploiement réellement ouvert et une base de clients très vaste et très active qui s’intéresse aux produits bizarres.

Il est difficile d’imaginer où je préférerais commencer.

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 parce qu’ils aiment inciter les gens à utiliser leur propre système d’exploitation.

Beaucoup de choses ont à voir avec la politique et le contrôle. À la fin des années 90, SGI et MS ont convenu d'associer leurs efforts:

http://en.wikipedia.org/wiki/Fahrenheit_graphics_API

SGI a beaucoup investi dans le projet, mais pas MS. SGI avait besoin de MS plus que de MS avait besoin de SGI. Le reste est de l'histoire.

D3D et OpenGL sont deux API très différentes, il appartient au développeur de choisir celle qui répond le mieux à vos besoins.

Tout simplement parce que Linux a terriblement échoué en tant que système de bureau. Comme quelqu'un l'a souligné précédemment, Linux est un gâchis pour les développeurs (bibliothèques différentes, kits d'outils utilisateur, etc.)

Un autre problème est le freetardism et le manque de support pour les logiciels propriétaires. Nvidia fournit toujours des pilotes fins (propriétaires) pour Linux, mais Ubuntu et d’autres distributions ne l’envoient pas. Il n'y a pas non plus d'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’identité avec le matériel Nvidia sous Linux.

La prochaine chose des outils de développement. MSFT fournit un excellent support C ++ et le débogueur Visual Studio est meilleur que gdb en ce qui concerne C ++. Last but not least, il manque d'autres outils tels que Photoshop. De plus, .net vous permet de créer rapidement des outils d’interface graphique. De nombreux studios de jeux codent leurs outils pour un usage interne à l'aide du framework .net.

J'avais presque oublié: le système graphique est affreux, à l'époque où ils portaient simplement X11, car c'était la solution la plus simple. Ils n’ont pas réussi à concevoir et à mettre en œuvre correctement un système graphique moderne que possèdent OSx et Win.