¿Por qué los desarrolladores de juegos prefieren Windows?

¿Es que DirectX es más fácil o mejor que OpenGL, incluso si OpenGL es multiplataforma? ¿Por qué no vemos juegos realmente poderosos para Linux como los que hay para Windows?

Muchas de las respuestas aquí son realmente buenas. Pero el problema de OpenGL y Direct3D (D3D) probablemente debería abordarse. Y eso requiere ... una lección de historia.

Y antes de comenzar, sé mucho más sobre OpenGL que sobre Direct3D . Nunca he escrito una línea de código D3D en mi vida, y he escrito tutoriales en OpenGL. Entonces, lo que voy a decir no es una cuestión de parcialidad. Es simplemente una cuestión de historia.

Nacimiento del conflicto

Un día, a principios de los 90, Microsoft miró a su alrededor. Vieron que SNES y Sega Genesis eran increíbles, ejecutaban muchos juegos de acción y demás. Y vieron DOS . Los desarrolladores codificaron juegos de DOS como juegos de consola: directo al metal. Sin embargo, a diferencia de las consolas, donde un desarrollador que hizo un juego SNES sabía qué hardware tendría el usuario, los desarrolladores de DOS tuvieron que escribir para múltiples configuraciones posibles. Y esto es bastante más difícil de lo que parece.

Y Microsoft tuvo un problema mayor: Windows. Mira, Windows quería ser dueño del hardware, a diferencia de DOS, que prácticamente permitía a los desarrolladores hacer lo que sea. Ser propietario del hardware es necesario para tener cooperación entre las aplicaciones. La cooperación es exactamente lo que odian los desarrolladores de juegos porque consume recursos de hardware preciosos que podrían estar utilizando para ser increíbles.

Para promover el desarrollo de juegos en Windows, Microsoft necesitaba una API uniforme que fuera de bajo nivel, se ejecutara en Windows sin ser ralentizada y, sobre todo , en hardware cruzado . Una única API para todos los gráficos, sonido y hardware de entrada.

Por lo tanto, nació DirectX .

Los aceleradores 3D nacieron unos meses después. Y Microsoft se encontró con un problema. Vea, DirectDraw, el componente gráfico de DirectX, solo se ocupó de gráficos 2D: asignando memoria de gráficos y haciendo bits de bits entre diferentes secciones asignadas de memoria.

Así que Microsoft compró un poco de middleware y lo transformó en Direct3D Versión 3. Fue universalmente vilipendiado. Y con buena razón; mirar el código D3D v3 es como mirar el Arca del Pacto.

El viejo John Carmack de Id Software echó un vistazo a esa basura y dijo: "¡A la mierda!" y decidí escribir para otra API: OpenGL.

Mira, otra parte de la bestia de muchas cabezas que es Microsoft había estado ocupada trabajando con SGI en una implementación de OpenGL para Windows. La idea aquí era cortejar a los desarrolladores de aplicaciones GL típicas: aplicaciones de estaciones de trabajo. Herramientas CAD, modelado, ese tipo de cosas. Los juegos eran lo más alejado en su mente. Esto era principalmente una cosa de Windows NT, pero Microsoft decidió agregarlo a Win95 también.

Como una forma de atraer a los desarrolladores de estaciones de trabajo a Windows, Microsoft decidió intentar sobornarlos con acceso a estas nuevas tarjetas gráficas 3D. Microsoft implementó el protocolo Installable Client Driver: un fabricante de tarjetas gráficas podría anular la implementación del software OpenGL de Microsoft con una basada en hardware. El código podría usar automáticamente una implementación de hardware OpenGL si hubiera una disponible.

En los primeros días, las tarjetas de video a nivel de consumidor no tenían soporte para OpenGL. Eso no impidió que Carmack solo transfiriera Quake a OpenGL (GLQuake) en su estación de trabajo SGI. Como podemos leer del archivo Léame de GLQuake:

Teóricamente, glquake se ejecutará en cualquier OpenGL compatible que admita las extensiones de objetos de textura, pero a menos que sea un hardware muy potente que acelere todo lo necesario, el juego no será aceptable. Si tiene que pasar por alguna ruta de emulación de software, es probable que el rendimiento sea muy inferior a un cuadro por segundo.

En este momento (marzo de '97), el único hardware estándar de opengl que puede reproducir razonablemente el terremoto es un realismo intergráfico, que es una tarjeta MUY costosa. 3dlabs ha estado mejorando significativamente su rendimiento, pero con los controladores disponibles todavía no es lo suficientemente bueno para jugar. Algunos de los controladores actuales de 3dlabs para placas de brillo y permedia también pueden bloquearse NT al salir de una ejecución de pantalla completa, por lo que no recomiendo ejecutar glquake en el hardware de 3dlabs.

3dfx ha proporcionado un opengl32.dll que implementa todo lo que necesita Glquake, pero no es una implementación completa de opengl. Es muy poco probable que otras aplicaciones opengl funcionen con él, así que considérelo básicamente como un "controlador de terremoto".

Este fue el nacimiento de los controladores miniGL. Con el tiempo, estos evolucionaron hacia implementaciones completas de OpenGL, ya que el hardware se volvió lo suficientemente potente como para implementar la mayoría de las funciones de OpenGL en el hardware. nVidia fue el primero en ofrecer una implementación completa de OpenGL. Muchos otros proveedores tuvieron problemas, por lo que los desarrolladores prefirieron Direct3D: eran compatibles en una gama más amplia de hardware. Finalmente, solo quedaron nVidia y ATI (ahora AMD), y ambos tuvieron una buena implementación de OpenGL.

Ascendente OpenGL

Así, el escenario está listo: Direct3D vs. OpenGL. Es realmente una historia increíble, considerando lo malo que era D3D v3.

El OpenGL Architectural Review Board (ARB) es la organización responsable de mantener OpenGL. Emiten una serie de extensiones, mantienen el repositorio de extensiones y crean nuevas versiones de la API. El ARB es un comité compuesto por muchos de los actores de la industria gráfica, así como algunos fabricantes de sistemas operativos. Apple y Microsoft han sido miembros del ARB en varias ocasiones.

3Dfx sale con el Voodoo2. Este es el primer hardware que puede hacer texturas múltiples, que es algo que OpenGL no podía hacer antes. Si bien 3Dfx estaba fuertemente en contra de OpenGL, a NVIDIA, fabricantes del próximo chip de gráficos multitextura (TNT1), le encantó. Entonces, el ARB emitió una extensión: GL_ARB_multitexture, que permitiría el acceso a la multitextura.

Mientras tanto, sale Direct3D v5. Ahora, D3D se ha convertido en una API real , en lugar de algo que un gato podría vomitar. ¿El problema? Sin multitextura.

Ups

Ahora, eso no dolería tanto como debería, porque la gente no usaba mucho el multitexturing. No directamente. Las texturas múltiples perjudicaron bastante el rendimiento, y en muchos casos no valió la pena en comparación con las pasadas múltiples. Y, por supuesto, a los desarrolladores de juegos les encanta asegurarse de que sus juegos funcionen en hardware antiguo, que no tenía multitextura, por lo que muchos juegos se envían sin él.

D3D recibió así un indulto.

El tiempo pasa y NVIDIA implementa la GeForce 256 (no GeForce GT-250; la primera GeForce), prácticamente terminando la competencia en tarjetas gráficas durante los próximos dos años. El principal punto de venta es la capacidad de hacer transformaciones e iluminación de vértices (T&L) en hardware. No solo eso, NVIDIA amaba tanto a OpenGL que su motor T&L era efectivamente OpenGL. Casi literalmente; Según tengo entendido, algunos de sus registros tomaron los enumeradores de OpenGL directamente como valores.

Sale Direct3D v6. Múltiples texturas al fin pero ... sin hardware T&L. OpenGL siempre había tenido una línea T&L, aunque antes del 256 se implementaba en software. Así que para NVIDIA fue muy fácil convertir su implementación de software en una solución de hardware. No sería hasta D3D v7 hasta que D3D finalmente tuviera soporte T&L de hardware.

Dawn of Shaders, Crepúsculo de OpenGL

Entonces, salió GeForce 3. Y muchas cosas sucedieron al mismo tiempo.

Microsoft había decidido que no iban a llegar tarde otra vez. Entonces, en lugar de mirar lo que estaba haciendo NVIDIA y luego copiarlo después del hecho, tomaron la asombrosa posición de ir a hablar con ellos. Y luego se enamoraron y tuvieron una pequeña consola juntos.

Un divorcio desordenado se produjo más tarde. Pero eso es para otro momento.

Lo que esto significó para la PC fue que GeForce 3 salió simultáneamente con D3D v8. Y no es difícil ver cómo GeForce 3 influyó en los sombreadores de D3D 8. Los sombreadores de píxeles del Shader Model 1.0 eran extremadamente específicos para el hardware de NVIDIA. No se hizo ningún intento de abstraer el hardware de NVIDIA; SM 1.0 fue justo lo que hizo la GeForce 3.

Cuando ATI comenzó a lanzarse a la carrera de la tarjeta gráfica de rendimiento con la Radeon 8500, había un problema. La canalización de procesamiento de píxeles del 8500 era más poderosa que las cosas de NVIDIA. Entonces, Microsoft emitió Shader Model 1.1, que básicamente era "Lo que sea que haga el 8500".

Eso puede sonar como un fracaso por parte de D3D. Pero el fracaso y el éxito son cuestiones de grados. Y estaba ocurriendo un fracaso épico en OpenGL-land.

NVIDIA amaba OpenGL, por lo que cuando llegó GeForce 3, lanzaron una gran cantidad de extensiones OpenGL. Extensiones propietarias de OpenGL: solo NVIDIA. Naturalmente, cuando apareció el 8500, no podía usar ninguno de ellos.

Vea, al menos en D3D 8 land, puede ejecutar sus sombreadores SM 1.0 en hardware ATI. Claro, tenía que escribir nuevos sombreadores para aprovechar la frescura del 8500, pero al menos su código funcionó .

Para tener sombreadores de cualquier tipo en Radeon 8500 en OpenGL, ATI tuvo que escribir varias extensiones de OpenGL. Extensiones propietarias de OpenGL: solo ATI. Así que necesitabas una ruta de código NVIDIA y una ruta de código ATI, solo para tener sombreadores .

Ahora, usted podría preguntar: "¿Dónde estaba el OpenGL ARB, de quién era el trabajo para mantener actualizado OpenGL?" Donde a menudo terminan muchos comités: fuera de ser estúpido.

Mira, mencioné ARB_multitexture arriba porque tiene mucho en cuenta todo esto. El ARB parecía (desde la perspectiva de un extraño) querer evitar por completo la idea de los sombreadores. Se dieron cuenta de que si aplicaban suficiente capacidad de configuración en la tubería de función fija, podrían igualar la capacidad de una tubería de sombreador.

Entonces, el ARB lanzó extensión tras extensión. Cada extensión con las palabras "texture_env" fue otro intento de parchear este diseño antiguo. Verifique el registro: entre las extensiones ARB y EXT, se hicieron ocho de estas extensiones. Muchos fueron promovidos a versiones principales de OpenGL.

Microsoft era parte del ARB en este momento; se fueron alrededor del momento en que D3D 9 golpeó. Por lo tanto, es muy posible que estuvieran trabajando para sabotear OpenGL de alguna manera. Personalmente dudo de esta teoría por dos razones. Primero, habrían tenido que obtener ayuda de otros miembros de ARB para hacerlo, ya que cada miembro solo obtiene un voto. Y lo más importante, dos, el ARB no necesitaba la ayuda de Microsoft para arruinar las cosas. Veremos más evidencia de eso.

Finalmente, el ARB, probablemente bajo la amenaza de ATI y NVIDIA (ambos miembros activos) finalmente sacó la cabeza lo suficiente como para proporcionar sombreadores de estilo ensamblador reales.

¿Quieres algo aún más estúpido?

Hardware T&L. Algo que OpenGL tuvo primero . Bueno, es interesante Para obtener el máximo rendimiento posible del hardware T&L, debe almacenar sus datos de vértice en la GPU. Después de todo, es la GPU la que realmente quiere usar sus datos de vértice.

En D3D v7, Microsoft introdujo el concepto de búferes Vertex. Estas son franjas asignadas de memoria de GPU para almacenar datos de vértices.

¿Quieres saber cuándo OpenGL obtuvo su equivalente de esto? Oh, NVIDIA, siendo un amante de todo lo relacionado con OpenGL (siempre que sean extensiones propietarias de NVIDIA), lanzó la extensión de rango de matriz de vértices cuando llegó por primera vez la GeForce 256. Pero, ¿cuándo decidió el ARB proporcionar una funcionalidad similar?

Dos años despues . Esto fue después de que aprobaron los sombreadores de vértices y fragmentos (píxeles en lenguaje D3D). Ese es el tiempo que le tomó al ARB desarrollar una solución multiplataforma para almacenar datos de vértices en la memoria de la GPU. Una vez más, algo que el hardware T&L necesita para lograr el máximo rendimiento.

Un idioma para arruinarlos a todos

Entonces, el entorno de desarrollo de OpenGL se fracturó por un tiempo. Sin sombreadores de hardware cruzado, sin almacenamiento de vértices de GPU de hardware cruzado, mientras que los usuarios de D3D disfrutaron de ambos. ¿Podría empeorar?

Tú ... podrías decir eso. Ingrese a 3D Labs .

¿Quiénes son, podrías preguntar? Son una compañía extinta a la que considero los verdaderos asesinos de OpenGL. Claro, la ineptitud general del ARB hizo que OpenGL fuera vulnerable cuando debería haber sido dueño de D3D. Pero 3D Labs es quizás la razón más importante en mi opinión para el estado actual del mercado de OpenGL. ¿Qué podrían haber hecho para causar eso?

Diseñaron el lenguaje de sombreado OpenGL.

Mira, 3D Labs era una empresa moribunda. Sus costosas GPU estaban siendo marginadas por la creciente presión de NVIDIA en el mercado de estaciones de trabajo. Y a diferencia de NVIDIA, 3D Labs no tenía presencia en el mercado principal; Si NVIDIA ganaba, morían.

Lo cual hicieron.

Entonces, en un intento por seguir siendo relevante en un mundo que no quería sus productos, 3D Labs se presentó a una Conferencia de Desarrolladores de Juegos con presentaciones para algo que llamaron "OpenGL 2.0". Esta sería una reescritura completa desde cero de la API de OpenGL. Y eso tiene sentido; En ese momento, había mucho cruft en la API de OpenGL (nota: ese cruft todavía existe). Basta con mirar cómo funciona la carga de textura y la unión; Es semi-arcano.

Parte de su propuesta era un lenguaje de sombreado. Naturalmente. Sin embargo, a diferencia de las extensiones ARB multiplataforma actuales, su lenguaje de sombreado era de "alto nivel" (C es de alto nivel para un lenguaje de sombreado. Sí, de verdad).

Ahora, Microsoft estaba trabajando en su propio lenguaje de sombreado de alto nivel. Lo que ellos, en toda la imaginación colectiva de Microsoft, llamaron ... el lenguaje de sombreado de alto nivel (HLSL). Pero su era un enfoque fundamentalmente diferente de los idiomas.

El mayor problema con el lenguaje de sombreado de 3D Labs fue que estaba incorporado. Vea, HLSL era un lenguaje definido por Microsoft. Lanzaron un compilador para él, y generó el código de ensamblaje Shader Model 2.0 (o modelos posteriores de shader), que ingresaría en D3D. En los días D3D v9, HLSL nunca fue tocado por D3D directamente. Era una bonita abstracción, pero era puramente opcional. Y un desarrollador siempre tuvo la oportunidad de ir detrás del compilador y ajustar la salida para obtener el máximo rendimiento.

El lenguaje de 3D Labs no tenía nada de eso. Le diste al conductor el lenguaje tipo C, y produjo un sombreador. Fin de la historia. No es un sombreador de ensamblaje, no es algo que alimentes con otra cosa. El objeto OpenGL real que representa un sombreador.

Lo que esto significa es que los usuarios de OpenGL estaban abiertos a los caprichos de los desarrolladores que solo estaban aprendiendo a compilar lenguajes similares a los ensamblados. Los errores del compilador corrían desenfrenados en el recientemente bautizado OpenGL Shading Language (GLSL). Lo que es peor, si lograste que un sombreador se compilara en múltiples plataformas correctamente (no es tarea fácil), aún estarías sujeto a los optimizadores del día. Que no eran tan óptimos como podrían ser.

Si bien esa fue la mayor falla en GLSL, no fue la única falla. Por el momento .

En D3D, y en los lenguajes de ensamblaje más antiguos en OpenGL, puede mezclar y combinar sombreadores de vértices y fragmentos (píxeles). Siempre que se comuniquen con la misma interfaz, puede usar cualquier sombreador de vértices con cualquier sombreador de fragmentos compatible. E incluso había niveles de incompatibilidad que podían aceptar; un sombreador de vértices podría escribir una salida que el sombreador de fragmentos no haya leído. Etcétera.

GLSL no tenía nada de eso. Los sombreadores de vértices y fragmentos se fusionaron en lo que 3D Labs llamó un "objeto de programa". Entonces, si quería compartir programas de vértices y fragmentos, tenía que construir varios objetos de programa. Y esto causó el segundo mayor problema.

Mira, 3D Labs pensó que estaban siendo inteligentes. Basaron el modelo de compilación de GLSL en C / C ++. Toma un .c o .cpp y lo compila en un archivo objeto. Luego, toma uno o más archivos de objetos y los vincula a un programa. Así es como se compila GLSL: compila su sombreador (vértice o fragmento) en un objeto sombreador. Luego coloca esos objetos de sombreado en un objeto de programa y los vincula para formar su programa real.

Si bien esto permitió ideas geniales como tener sombreadores de "biblioteca" que contenían código adicional que los sombreadores principales podían llamar, lo que significaba en la práctica era que los sombreadores se compilaron dos veces . Una vez en la etapa de compilación y otra en la etapa de vinculación. El compilador de NVIDIA en particular era conocido por ejecutar básicamente la compilación dos veces. No generó algún tipo de código de objeto intermediario; solo lo compiló una vez y tiró la respuesta, luego la compiló nuevamente en el momento del enlace.

Por lo tanto, incluso si desea vincular su sombreador de vértices a dos sombreadores de fragmentos diferentes, debe compilar mucho más que en D3D. Especialmente porque la compilación de un lenguaje tipo C se realizó sin conexión , no al comienzo de la ejecución del programa.

Hubo otros problemas con GLSL. Quizás parezca incorrecto echarle la culpa a 3D Labs, ya que el ARB finalmente aprobó e incorporó el lenguaje (pero nada más de su iniciativa "OpenGL 2.0"). Pero fue su idea.

Y aquí está la parte realmente triste: 3D Labs tenía razón (principalmente). GLSL no es un lenguaje de sombreado basado en vectores como HLSL era en ese momento. Esto se debió a que el hardware de 3D Labs era hardware escalar (similar al hardware moderno de NVIDIA), pero finalmente estaban en la dirección en la que muchos fabricantes de hardware fueron con su hardware.

Tenían razón al elegir un modelo de compilación en línea para un lenguaje de "alto nivel". D3D incluso cambió a eso eventualmente.

El problema era que 3D Labs tenía razón en el momento equivocado . Y al tratar de convocar el futuro demasiado pronto, al tratar de ser a prueba del futuro, descartan el presente . Suena similar a cómo OpenGL siempre tuvo la posibilidad de funcionalidad T&L. Excepto que la tubería de T&L de OpenGL todavía era útil antes de T&L de hardware, mientras que GLSL era una responsabilidad antes de que el mundo lo alcanzara.

GLSL es un buen lenguaje ahora . Pero por el momento? Fue horrible. Y OpenGL sufrió por ello.

Cayendo hacia la apoteosis

Si bien mantengo que 3D Labs dio el golpe fatal, fue el propio ARB el que clavó el último clavo en el ataúd.

Esta es una historia que quizás hayas escuchado. En el momento de OpenGL 2.1, OpenGL se encontraba con un problema. Tenía mucho legado cruft. La API ya no era fácil de usar. Había 5 formas de hacer las cosas, y no tenía idea de cuál era la más rápida. Podrías "aprender" OpenGL con tutoriales simples, pero realmente no aprendiste la API de OpenGL que te dio un rendimiento real y potencia gráfica.

Entonces el ARB decidió intentar otra reinvención de OpenGL. Esto era similar al "OpenGL 2.0" de 3D Labs, pero mejor porque el ARB estaba detrás de él. Lo llamaron "Longs Peak".

¿Qué tiene de malo tomarse un tiempo para mejorar la API? Esto era malo porque Microsoft se había dejado vulnerable. Mira, esto fue en el momento del cambio de Vista.

Con Vista, Microsoft decidió instituir algunos cambios muy necesarios en los controladores de pantalla. Obligaron a los conductores a someterse al sistema operativo para la virtualización de la memoria de gráficos y varias otras cosas.

Si bien uno puede debatir los méritos de esto o si realmente fue posible, el hecho sigue siendo esto: Microsoft consideró que D3D 10 era solo Vista (y superior). Incluso si tuviera hardware que fuera capaz de D3D 10, no podría ejecutar aplicaciones D3D 10 sin ejecutar también Vista.

También puede recordar que Vista ... um, digamos que no funcionó bien. Entonces, tenía un sistema operativo de bajo rendimiento, una nueva API que solo se ejecutaba en ese sistema operativo y una nueva generación de hardware que necesitaba que la API y el sistema operativo hicieran algo más que ser más rápidos que la generación anterior.

Sin embargo, los desarrolladores pueden acceder a las características de clase D3D 10 a través de OpenGL. Bueno, podrían hacerlo si el ARB no hubiera estado ocupado trabajando en Longs Peak.

Básicamente, el ARB pasó un buen año y medio o dos años de trabajo para mejorar la API. Para cuando salió OpenGL 3.0, la adopción de Vista había terminado, Win7 estaba a la vuelta de la esquina para poner a Vista detrás de ellos, y la mayoría de los desarrolladores de juegos no se preocupaban por las características de clase D3D-10 de todos modos. Después de todo, el hardware D3D 10 ejecutó aplicaciones D3D 9 muy bien. Y con el aumento de los puertos de PC a consola (o los desarrolladores de PC saltan al desarrollo de la consola. Elija), los desarrolladores no necesitaban características de clase D3D 10.

Ahora, si los desarrolladores tenían acceso a esas características anteriormente a través de OpenGL en máquinas WinXP, entonces el desarrollo de OpenGL podría haber recibido una inyección muy necesaria en el brazo. Pero el ARB perdió su oportunidad. ¿Y quieres saber la peor parte?

A pesar de pasar dos preciosos años intentando reconstruir la API desde cero ... todavía fallaron y volvieron al estado actual (excepto por un mecanismo de desaprobación).

Entonces, el ARB no solo perdió una oportunidad crucial , sino que ni siquiera realizó la tarea que los hizo perder esa oportunidad. Bastante épico fallar por todos lados.

Y esa es la historia de OpenGL vs. Direct3D. Una historia de oportunidades perdidas, estupidez, ceguera voluntaria y simple tontería.

Me pareció extraño que todos se centren en la base de usuarios, cuando la pregunta es 'desarrolladores de juegos', no 'editores de juegos'.

Para mí, como desarrollador, Linux es un desastre sangriento. Hay tantas versiones, administradores de escritorio, kits de interfaz de usuario, etc. Si no quiero distribuir mi trabajo como código abierto, donde el usuario puede (intentar) recompilar para que se ajuste a su combinación única de paquetes, bibliotecas y ajustes, es una pesadilla !

Por otro lado, Microsoft proporciona (la mayoría de las veces) una increíble compatibilidad con versiones anteriores y estabilidad de la plataforma. Es posible apuntar a toda una gama de máquinas con un instalador de código cerrado, por ejemplo, computadoras que ejecutan Windows XP, Vista y sabores de 7, 32 y 64 bits, sin DX o VC redistribuibles instalados, etc.

Una última cosa, ¡POR FAVOR TODOS EN INTERNET DEJEN DE COMPARAR OPENGL Y DIRECTX! Compare Direct3D con OpenGL o no haga esto . DirectX proporciona soporte de entrada, soporte de sonido, reproducción de películas, etc., etc. que OpenGL no ofrece.

Es porque hay más usuarios de Windows en el planeta que Linux y Mac. La verdad es que las personas hacen cosas para cualquiera que tenga el mercado más grande.
Lo mismo ocurre con los teléfonos móviles: Android y iPhone tienen juegos increíbles, pero Windows Mobile y Symbian no ...

Debido a que Windows tiene más del 90% de participación de mercado, y Linux (ya que usted preguntó específicamente sobre Linux) tiene la reputación de tener muchos usuarios a los que no les gusta pagar por el software. Si eso es cierto o no, o cuán cierto es irrelevante; la percepción está ahí e influye en las decisiones de las personas.

Debido a que Windows está respaldado por una gran organización, que hace más de una década decidieron que querían que el desarrollo de juegos ocurriera en su plataforma .

Esto no era cierto para Mac, y no es cierto ahora. Ni siquiera para iOS. Apple no proporciona herramientas para el desarrollo de juegos iOS. Pero es un mercado enorme (hay más iPhones por ahí que PC en 1995) con relativamente poca competencia, por lo que la gente lo hace de todos modos.

En cuanto a Linux, ni siquiera hay algún tipo de institución central que pueda establecer ningún tipo de prioridades. La dirección en la que se dirige Linux está menos determinada por un grupo de programadores muy buenos, pero un poco extraños.

Para crear un juego de PC hoy, necesitas muchos artistas 2d / 3d, diseñadores de juegos, guionistas, actores, probadores y demás. En cuanto a la programación real, simplemente puede usar un motor de juego real (CryEngine, Unreal Engine, Quake Engine, Source Engine). Por lo tanto, es posible que pueda hacer todo sin ningún programador real.

Por eso y por la naturaleza de las empresas, los programadores tienen poco que decir en qué plataforma se elige. Y, por lo general, los gerentes buscan apoyo, que es algo que Microsoft dice ofrecer, y para lidiar con cosas que de alguna manera se pueden aprovechar para sus patrones de pensamiento, que no es el código abierto.

Por esa razón, la mayoría del desarrollo de software comercial para el usuario final se realiza en Windows.
Trabajo para una empresa que crea juegos flash y, por lo tanto, no está vinculada a una plataforma en particular. Sin embargo, todos desarrollamos en Windows, porque la mayoría de las herramientas que utilizamos no están disponibles para Linux.

Como algunos ya han dicho, la parte más importante es la base de usuarios. El 95% de los usuarios de PC usan Windows. Los jugadores de PC usan casi exclusivamente Windows. Incluso aquellos que usan Mac o Linux con mayor frecuencia ejecutan juegos de Windows a través de alguna virtualización o emulación (con muy, muy pocas excepciones).

Pero la demografía no lo es todo. No subestimaría la parte que está haciendo Microsoft para hacer que la plataforma sea más atractiva para los desarrolladores de juegos. Básicamente, obtienes un conjunto completo de herramientas gratis , lo más importante XNA Game Studio . Esto permite no solo el desarrollo para Windows, sino también para Xbox360 . Y con la última edición incluso para teléfonos WP7. Obviamente, dado que es una herramienta de Microsoft, usa DirectX, no OpenGL.

Ewwww, no lo hago. Yo uso Linux casi exclusivamente. Arranco dual en Windows para hacer compilaciones de Windows, y uso la Mac para las compilaciones de Mac, pero eso es todo.

El truco es un marco multiplataforma que hemos desarrollado a lo largo de los años. Nuestros juegos están construidos además de eso, y se comportan de manera idéntica en Linux / OpenGL, Mac / OpenGL y Windows / Direct3D (y pronto en iOS / OpenGL).

Es cierto que mi compañía no hace títulos AAA, por lo que puede que no se aplique a estos, pero sí hacemos juegos casuales de primera clase (vea el sitio web : CSI: NY, Murder She Wrote y los dos próximos 2011 son ejemplos de títulos que usan licencias importantes, The Los casos perdidos de Sherlock Holmes 1 y 2 también tuvieron bastante éxito)

No renunciaría a gedit + gcc + gdb + valgrind por nada más.

1. Inercia. Si ha usado Windows en el pasado, cambiar a otra cosa es una molestia. Si estás en Windows DirectX es más fácil y más probable que funcione bien que OpenGL.
2. Cuota de mercado. La cuota de mercado de Windows en el escritorio es mayor que la de OS X, que a su vez es mayor que la de Linux. El dinero habla.
3. Marca. DirectX es mejor conocido que cosas como SDL (que es el tipo de cosa que necesitaría para replicar algunas de las características de DirectX que van más allá de OpenGL).
4. Menos confusión ¿El usuario de Linux solo admitirá hasta OpenGL 1.4 u OpenGL 2+? ¿Se puede utilizar un tutorial de OpenGL 2.0 como una introducción a OpenGL moderno? Capítulo 1: ¿La tubería de gráficos en su versión Linux?

En estos días, Linux es más curioso cuando se trata del desarrollo de juegos y la mayoría de los desarrolladores estarían mejor fiscalmente haciendo una versión de puerto OS X antes que una versión de Linux (ver cosas como Steam). Incluso entonces, el mercado de consolas vale más que estas dos plataformas combinadas para juegos ...

Si desea mono plataforma DirectX está bien. Si quieres ser multiplataforma, hay muchas posibilidades de que tengas que usar OpenGL en al menos algunas de las otras plataformas.

La respuesta es obvia. El objetivo de escribir un juego es ganar dinero. Más usuarios finales ejecutan Windows, por lo tanto, hay un mercado más grande y esperarías ganar más dinero con un juego de Windows que con un juego de Linux. Es así de simple.

Si alguna vez te haces la pregunta "¿Por qué alguien hace ...?", Recuerda que el dinero hace girar al mundo.

Herramientas, herramientas, herramientas.

A eso se reduce todo. Desarrolle en Windows y obtendrá acceso a algunas de las mejores herramientas de desarrollo del planeta. Nada se acerca ni remotamente al depurador de Visual Studio, los tiempos de ejecución de depuración de DirectX son increíbles, PIX es increíble y los equivalentes comparables simplemente no existen en otras plataformas / API. Claro, hay algunas cosas buenas allí; No digo que las herramientas en otras plataformas sean malas, pero las que ofrece MS están tan adelantadas (excepción honorable: Valgrind) que ni siquiera es divertido.

La conclusión es que estas herramientas te ayudan. Te ayudan a hacer cosas, te ayudan a ser productivo, te ayudan a concentrarte en los errores en tu propio código en lugar de luchar con una API que nunca se comporta como se documenta.

Así que he revisado todas estas respuestas, y como desarrollador de juegos que tiene código en juegos de consola que han estado en los estantes de Walmart, tengo una respuesta muy diferente.

Distribución.

Mira, si quieres estar en una consola Nintendo, debes obtener el permiso de Nintendo, comprar en las fábricas de Nintendo, pagar los gastos generales de Nintendo, negociar con Walmart, lidiar con el almacenamiento, necesitas dinero por adelantado para fabricar, imprimir cajas, enviar , para hacer todos los seguros, etc.

Si quieres ingresar a la XBox, seguro que hay XBLA, pero aún necesitas la bendición de Microsoft, tienes que esperar tu turno en la fila, son decenas de miles de dólares solo para lanzar un parche, etc.

En iOS, todavía necesita la autorización de Apple, y pueden (y lo hacen) caprichosamente tirar de usted.

En Steam, aún necesita el permiso de Valve o luz verde, y mucho dinero.

.

En Windows Configura un sitio web y un botón de descarga.

.

No digo que las otras plataformas no sean valiosas. Pero hay tantas * cosas * horribles que suceden cuando estás tratando de desarrollar un juego, que para mí, la promesa de poder simplemente abofetear un binario en un sitio y enfocarte en el trabajo, al menos para comenzar, Realmente reduce muchas posibles barreras de falla.

"Podemos hacer el puerto XBLA más tarde, cuando las cosas estén estables" mentalidad.

Y, en menor medida, seguro que esto también está bien para Linux, y si siete clientes son buenos, puede comenzar allí.

Pero Windows tiene tres ventajas masivas: desarrollo genuinamente abierto, implementación genuinamente abierta y una base de clientes muy grande y muy activa que está interesada en cosas extravagantes.

Es difícil imaginar dónde preferiría comenzar.

Creo que debería leer más sobre la historia de DirectX y este artículo .

Creo que MS eligió DX sobre openGL porque les gusta bloquear a las personas para que usen su propio sistema operativo.

Mucho tiene que ver con la política y el control. A finales de los 90, SGI y MS acordaron combinar esfuerzos:

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

SGI invirtió fuertemente en el proyecto, MS no. SGI necesitaba MS más de lo que MS necesitaba SGI. El resto es historia.

D3D y OpenGL son dos API muy diferentes, depende del desarrollador elegir cuál es el adecuado para sus necesidades.

Simplemente porque Linux falló terriblemente como sistema de escritorio. Como alguien señaló anteriormente, Linux es un desastre para los desarrolladores (diferentes bibliotecas, kits de herramientas de interfaz de usuario, etc.)

Otro problema es el freetardismo y la falta de soporte para software propietario. Nvidia siempre proporciona buenos controladores (propietarios) para Linux, sin embargo, Ubuntu y otras distribuciones no lo envían. Tampoco hay una interfaz de controlador binario disponible para Linux como para Windows. (Hay un archivo de texto llamado binaryApiNonsense.txt o algo en las fuentes del Kernel) Habiendo dicho que solo el hardware de Nvidia es compatible con Linux. Puede jugar la mayoría de los juegos de software de ID utilizando el hardware de Nvidia en Linux.

Lo siguiente herramientas de desarrollo. MSFT proporciona una excelente compatibilidad con C ++ y el depurador de Visual Studio es mejor que gdb con respecto a C ++. Por último, pero no menos importante, faltan otras herramientas como Photoshop. Además .net le permite crear rápidamente herramientas gui. Muchos estudios de juegos codifican sus herramientas para uso interno utilizando el marco .net.

Casi me olvido: el sistema de gráficos es horrible, en los días en que acababan de portar X11 porque era lo más fácil que funcionaba. No pudieron diseñar e implementar adecuadamente un sistema gráfico moderno que tienen OSx y Win.