Почему разработчики игр предпочитают Windows?

Является ли DirectX легче или лучше OpenGL, даже если OpenGL кроссплатформенный? Почему мы не видим настоящих мощных игр для Linux, как для Windows?

Многие из ответов здесь действительно хороши. Но проблема OpenGL и Direct3D (D3D), вероятно, должна быть решена. И это требует ... урока истории.

И прежде чем мы начнем, я знаю гораздо больше об OpenGL, чем о Direct3D . Я никогда не писал ни строчки кода D3D в своей жизни, и я написал учебники по OpenGL. Так что то, что я собираюсь сказать, не является вопросом предвзятости. Это просто вопрос истории.

Рождение Конфликта

Однажды, в начале 90-х, Microsoft огляделась вокруг. Они увидели, что SNES и Sega Genesis великолепны, запускают множество экшенов и тому подобное. И они увидели DOS . Разработчики закодировали DOS-игры, такие как консольные игры: прямо на металл. Однако, в отличие от консолей, когда разработчик, создавший игру SNES, знал, какое оборудование будет у пользователя, разработчикам DOS приходилось писать для нескольких возможных конфигураций. И это сложнее, чем кажется.

И у Microsoft была большая проблема: Windows. Видите ли, Windows хотела владеть оборудованием, в отличие от DOS, который в значительной степени позволял разработчикам делать что угодно. Владение оборудованием необходимо для того, чтобы взаимодействовать между приложениями. Сотрудничество - именно то, что ненавидят разработчики игр, потому что оно требует драгоценных аппаратных ресурсов, которые они могли бы использовать, чтобы быть крутыми.

Чтобы способствовать разработке игр для Windows, Microsoft требовался унифицированный API, который был бы низкоуровневым, работал на Windows без каких-либо задержек, и, в первую очередь, кросс-аппаратного обеспечения . Единый API для всех графических, звуковых и аппаратных средств ввода.

Таким образом, DirectX родился.

3D-ускорители родились несколько месяцев спустя. И Microsoft столкнулась с проблемой. Смотрите, DirectDraw, графический компонент DirectX, имел дело только с 2D-графикой: распределение графической памяти и создание бит-битов между различными выделенными участками памяти.

Поэтому Microsoft купила немного промежуточного программного обеспечения и превратила его в Direct3D версии 3. Он был оскорблен повсеместно . И по уважительной причине; смотреть на код D3D v3 - все равно что смотреть в Ковчег Завета.

Старый Джон Кармак из Id Software один раз взглянул на этот мусор и сказал: «Винт это!» и решил написать в сторону другого API: OpenGL.

Посмотрите, еще одна часть многоголового зверя, то есть Microsoft, была занята работой с SGI над реализацией OpenGL для Windows. Идея заключалась в том, чтобы привлечь разработчиков типичных приложений GL: приложений для рабочих станций. Инструменты САПР, моделирование и тому подобное. Игры были самой последней вещью, о которой они думали. Это было в первую очередь Windows NT, но Microsoft решила добавить его и в Win95.

Чтобы привлечь разработчиков рабочих станций к Windows, Microsoft решила попытаться подкупить их доступом к этим новомодным 3D-картам. Microsoft внедрила протокол Installable Client Driver: производитель видеокарт мог бы заменить программную реализацию Microsoft OpenGL аппаратной. Код может автоматически использовать аппаратную реализацию OpenGL, если она доступна.

В первые дни видеокарты потребительского уровня не имели поддержки OpenGL. Это не помешало Кармаку просто портировать Quake на OpenGL (GLQuake) на своей рабочей станции SGI. Как мы можем прочитать из readme о GLQuake:

Теоретически, glquake будет работать на любом совместимом OpenGL, который поддерживает расширения текстурных объектов, но если это не очень мощное аппаратное обеспечение, которое ускоряет все необходимое, игра не будет приемлемой. Если ему придется пройти через любые пути программной эмуляции, производительность, скорее всего, будет ниже одного кадра в секунду.

В настоящее время (март '97) единственное стандартное оборудование opengl, которое может разумно воспроизводить glquake, - это реализация intergraph, ОЧЕНЬ дорогая карта. 3dlabs значительно улучшила свою производительность, но с доступными драйверами она все еще недостаточно хороша для игры. Некоторые из существующих драйверов 3dlabs для glint и permedia-платформ могут также приводить к сбою NT при выходе из полноэкранного режима, поэтому я не рекомендую запускать glquake на оборудовании 3dlabs.

3dfx предоставил opengl32.dll, который реализует все, что нужно glquake, но это не полная реализация opengl. Другие приложения opengl вряд ли будут работать с ним, поэтому считают его «драйвером glquake».

Это было рождение водителей miniGL. В конечном итоге они превратились в полные реализации OpenGL, поскольку аппаратное обеспечение стало достаточно мощным для реализации большей части функциональности OpenGL в аппаратном обеспечении. nVidia была первой, кто предложил полную реализацию OpenGL. Многие другие поставщики боролись, что является одной из причин, почему разработчики предпочли Direct3D: они были совместимы с более широким спектром оборудования. В конце концов остались только nVidia и ATI (теперь AMD), и оба имели хорошую реализацию OpenGL.

OpenGL Ascendant

Таким образом, сцена установлена: Direct3D против OpenGL. Это действительно удивительная история, учитывая, насколько плохим был D3D v3.

OpenGL Architectural Review Board (ARB) - это организация, ответственная за поддержку OpenGL. Они выпускают несколько расширений, поддерживают репозиторий расширений и создают новые версии API. ARB - это комитет, состоящий из многих игроков графической индустрии, а также некоторых производителей ОС. Apple и Microsoft в разное время были членами ARB.

3Dfx выходит с Voodoo2. Это первое оборудование, которое может выполнять мультитекстурирование, чего раньше OpenGL не мог сделать. В то время как 3Dfx был категорически против OpenGL, NVIDIA, создатели следующего мультитекстурированного графического чипа (TNT1), полюбили его. Поэтому ARB выпустил расширение: GL_ARB_multitexture, которое позволило бы получить доступ к мультитекстурированию.

Между тем, Direct3D v5 выходит. Теперь D3D стал настоящим API , а не чем-то, что может вызвать рвота у кошки. Проблема? Нет мультитекстурирования.

К сожалению.

Теперь это не повредит почти так же, как следовало бы, потому что люди не слишком много использовали мультитекстурирование. Не напрямую. Мультитекстурирование сильно ухудшает производительность, и во многих случаях оно того не стоит по сравнению с многопроходной передачей. И, конечно, разработчики игр любят, чтобы их игры работали на старом оборудовании, у которого не было мультитекстурирования, поэтому многие игры поставлялись без него.

Таким образом, D3D получил отсрочку.

Проходит время, и NVIDIA развертывает GeForce 256 (а не GeForce GT-250; самую первую GeForce), что в значительной степени положит конец конкуренции в видеокартах в течение следующих двух лет. Основным преимуществом является возможность выполнять вершинное преобразование и освещение (T & L) в аппаратном обеспечении. Кроме того, NVIDIA настолько сильно любила OpenGL, что их движком T & L по сути был OpenGL. Почти буквально; насколько я понимаю, некоторые из их регистров фактически использовали счетчики OpenGL непосредственно в качестве значений.

Direct3D v6 выходит. Мультитекстура наконец, но ... без аппаратного T & L. OpenGL всегда имел конвейер T & L, хотя до 256 он был реализован в программном обеспечении. Поэтому NVIDIA было очень легко просто преобразовать свою программную реализацию в аппаратное решение. Так будет до D3D v7, пока у D3D наконец не появится аппаратная поддержка T & L.

Рассвет Шейдеров, Сумерки OpenGL

Затем вышла GeForce 3. И много чего произошло одновременно.

Microsoft решила, что они больше не опаздывают. Таким образом, вместо того, чтобы смотреть на то, что делала NVIDIA, а затем копировать ее после факта, они заняли удивительную позицию, обращаясь к ним и разговаривая с ними. А потом они влюбились и собрали небольшую консоль.

Грязный развод последовал позже. Но это в другой раз.

Для ПК это означало, что GeForce 3 вышла одновременно с D3D v8. И нетрудно понять, как GeForce 3 повлияла на шейдеры D3D 8. Пиксельные шейдеры Shader Model 1.0 были чрезвычайно специфичны для аппаратного обеспечения NVIDIA. Не было никаких попыток абстрагировать аппаратное обеспечение NVIDIA; SM 1.0 был просто тем, что делал GeForce 3.

Когда ATI начала участвовать в гонке видеокарт с Radeon 8500, возникла проблема. Трубопровод обработки пикселей 8500 был более мощным, чем у NVIDIA. Таким образом, Microsoft выпустила Shader Model 1.1, которая в основном была «Что бы ни делал 8500».

Это может звучать как провал со стороны D3D. Но неудача и успех - это вопросы степени. И эпический провал происходил на OpenGL-земле.

NVIDIA очень понравилась OpenGL, поэтому, когда появилась GeForce 3, они выпустили множество расширений OpenGL. Проприетарные расширения OpenGL: только для NVIDIA. Естественно, когда появился 8500, он не смог использовать ни один из них.

Видите ли, по крайней мере, на D3D 8, вы можете запускать свои шейдеры SM 1.0 на оборудовании ATI. Конечно, вы должны были написать новые шейдеры, чтобы воспользоваться преимуществами 8500, но по крайней мере ваш код работал .

Чтобы иметь какие-либо шейдеры на Radeon 8500 в OpenGL, ATI пришлось написать несколько расширений OpenGL. Запатентованные расширения OpenGL: только для ATI. Таким образом, вам нужен был NVIDIA codepath и ATI codepath, просто чтобы иметь шейдеры вообще.

Теперь вы можете спросить: «Где был OpenGL ARB, чья работа состояла в том, чтобы поддерживать OpenGL в актуальном состоянии?» Там, где часто заканчиваются многие комитеты: глупость.

Видите, я упомянул ARB_multitexture выше, потому что это сильно влияет на все это. Казалось, ARB (с точки зрения постороннего) хочет вообще избежать идеи шейдеров. Они полагали, что, если бы они наложили достаточную конфигурируемость на конвейер с фиксированной функцией, они могли бы равняться способности шейдерного конвейера.

Таким образом, АРБ ​​выпустил расширение после расширения. Каждое расширение со словами "texture_env" было еще одной попыткой исправить этот устаревший дизайн. Проверьте реестр: между расширениями ARB и EXT было сделано восемь таких расширений. Многие были повышены до основных версий OpenGL.

Microsoft была частью ARB в это время; они ушли в то время, когда D3D 9 ударил. Так что вполне возможно, что они каким-то образом саботировали OpenGL. Я лично сомневаюсь в этой теории по двум причинам. Во-первых, они должны были бы получить помощь от других членов АРБ, чтобы сделать это, поскольку каждый член получает только один голос. И что самое важное, АРБ ​​не нуждался в помощи Microsoft, чтобы все испортить. Мы увидим дальнейшие доказательства этого.

В конце концов, ARB, вероятно находящийся под угрозой как со стороны ATI, так и NVIDIA (оба активных участника), в конечном итоге вытащили свою голову достаточно долго, чтобы предоставить реальные шейдеры в стиле сборки.

Хотите что-то еще глупее?

Аппаратное обеспечение T & L. Что-то OpenGL было первым . Ну, это интересно. Чтобы получить максимально возможную производительность от аппаратного T & L, вам нужно хранить ваши данные вершин на GPU. В конце концов, именно GPU действительно хочет использовать ваши данные вершин.

В D3D v7 Microsoft представила концепцию буферов вершин. Это выделенные участки памяти GPU для хранения данных вершин.

Хотите знать, когда OpenGL получил свой эквивалент этого? О, NVIDIA, будучи любителем всех вещей OpenGL (если они являются проприетарными расширениями NVIDIA), выпустила расширение диапазона массивов вершин, когда GeForce 256 впервые появилась. Но когда АРБ решил предоставить аналогичную функциональность?

Два года спустя . Это было после того, как они утвердили вершинные и фрагментные шейдеры (пиксель на языке D3D). Вот так много времени понадобилось ARB для разработки кроссплатформенного решения для хранения данных вершин в памяти GPU. Опять же, то, что аппаратному T & L нужно для достижения максимальной производительности.

Один язык погубит их всех

Таким образом, среда разработки OpenGL была на некоторое время разрушена. Нет кросс-аппаратных шейдеров, нет кросс-аппаратного хранилища вершин графического процессора, в то время как пользователям D3D нравилось и то и другое. Может ли быть хуже?

Вы ... вы могли бы сказать это. Войдите в 3D Labs .

Кто они, спросите вы? Это несуществующая компания, которую я считаю истинными убийцами OpenGL. Конечно, общая неспособность ARB сделала OpenGL уязвимой, когда она должна была владеть D3D. Но 3D Labs - это, пожалуй, единственная главная причина моего нынешнего состояния рынка OpenGL. Что они могли сделать, чтобы вызвать это?

Они разработали язык затенения OpenGL.

Видите, 3D Labs была умирающей компанией. Их дорогие графические процессоры оказались в стороне от растущего давления NVIDIA на рынке рабочих станций. И в отличие от NVIDIA, 3D Labs не имела никакого присутствия на массовом рынке; если NVIDIA выиграла, они умерли.

Что они и сделали.

Таким образом, в стремлении сохранить свою актуальность в мире, где не нужны их продукты, 3D Labs приняли участие в конференции разработчиков игр, на которой были представлены презентации под названием «OpenGL 2.0». Это будет полное переписывание OpenGL API с нуля. И это имеет смысл; в то время в API OpenGL было много разногласий (обратите внимание: этот развод все еще существует). Просто посмотрите, как работают загрузка и привязка текстур; это полу-тайное.

Частью их предложения был язык затенения. Естественно. Однако, в отличие от текущих кроссплатформенных расширений ARB, их язык шейдинга был «высокоуровневым» (C - высокоуровневый язык шейдинга. Да, действительно).

Теперь Microsoft работала над собственным языком высокоуровневого шейдинга. Что они, во всем коллективном воображении Microsoft, назвали ... Язык высокого уровня затенения (HLSL). Но у них был принципиально другой подход к языкам.

Самая большая проблема с шейдерным языком 3D Labs заключалась в том, что он был встроенным. Видите ли, HLSL был языком, определенным Microsoft. Они выпустили для него компилятор, и он сгенерировал ассемблерный код Shader Model 2.0 (или более поздних моделей шейдеров), который вы будете передавать в D3D. В дни D3D v9 HLSL никогда не касался D3D напрямую. Это была хорошая абстракция, но это было не обязательно. И у разработчика всегда была возможность пойти за компилятором и настроить вывод для максимальной производительности.

В языке 3D Labs этого не было . Вы дали драйверу C-подобный язык, и он создал шейдер. Конец истории. Не сборочный шейдер, не то, что вы кормите чем-то другим. Фактический объект OpenGL, представляющий шейдер.

Это означало, что пользователи OpenGL были открыты для капризов разработчиков, которые только начинали создавать компиляционные языки. Компилятор ошибок побежал безудержной в недавно окрестил OpenGL Shading Language (GLSL). Что еще хуже, если вам удалось заставить шейдер правильно компилироваться на нескольких платформах (не значит, подвиг), вы все равно были подвержены оптимизаторам дня. Которые были не так оптимальны, как могли бы быть.

Хотя это был самый большой недостаток в GLSL, это был не единственный недостаток. По далеко .

В D3D и в более старых языках ассемблера в OpenGL вы могли смешивать и сочетать вершинные и фрагментные (пиксельные) шейдеры. Пока они взаимодействуют с одним и тем же интерфейсом, вы можете использовать любой вершинный шейдер с любым совместимым фрагментным шейдером. И были даже уровни несовместимости, которые они могли принять; вершинный шейдер может записать вывод, который фрагментный шейдер не прочитал. И так далее.

У GLSL ничего этого не было. Вершинные и фрагментные шейдеры были объединены в то, что в 3D Labs называли «программным объектом». Поэтому, если вы хотите поделиться вершинными и фрагментными программами, вам нужно создать несколько программных объектов. И это вызвало вторую по величине проблему.

Видите, 3D Labs думали, что они умны. Они основали модель компиляции GLSL на C / C ++. Вы берете .c или .cpp и компилируете его в объектный файл. Затем вы берете один или несколько объектных файлов и связываете их в программу. Вот как GLSL компилирует: вы компилируете свой шейдер (вершину или фрагмент) в объект шейдера. Затем вы помещаете эти шейдерные объекты в программный объект и связываете их вместе, чтобы сформировать реальную программу.

Несмотря на то, что это позволяло создавать потенциальные интересные идеи, такие как наличие «библиотечных» шейдеров, содержащих дополнительный код, который могут вызывать основные шейдеры, на практике это означало, что шейдеры компилировались дважды . Один раз на этапе компиляции и один раз на этапе компоновки. Компилятор NVIDIA, в частности, был известен тем, что в основном запускал компиляцию дважды. Он не генерировал какой-то посредник объектного кода; он просто скомпилировал его один раз и выбросил ответ, затем снова скомпилировал его во время соединения.

Поэтому, даже если вы хотите связать свой вершинный шейдер с двумя различными фрагментными шейдерами, вам придется выполнять намного больше компиляции, чем в D3D. Тем более, что компиляция C-подобного языка была сделана в автономном режиме , а не в начале выполнения программы.

Были другие проблемы с GLSL. Возможно, кажется неправильным возлагать вину на 3D Labs, так как ARB в конечном итоге одобрил и включил язык (но не более того, в свою инициативу "OpenGL 2.0"). Но это была их идея.

И вот действительно печальная часть: 3D Labs были правы (в основном). GLSL не является векторным языком затенения, каким был HLSL в то время. Это было связано с тем, что оборудование 3D Labs было скалярным (аналогично современному оборудованию NVIDIA), но в конечном итоге они были правы в том направлении, в котором многие производители оборудования использовали свое оборудование.

Они были правы использовать модель компиляции онлайн для языка «высокого уровня». D3D даже переключился на это в конце концов.

Проблема заключалась в том, что 3D-лаборатории оказались не в то время . И, пытаясь вызвать будущее слишком рано, пытаясь быть уверенным в будущем, они отбрасывают настоящее . Это похоже на то, как в OpenGL всегда была возможность использовать T & L. За исключением того, что конвейер T & L OpenGL был еще полезен до аппаратного T & L, в то время как GLSL был пассивом, прежде чем мир его догнал.

GLSL хороший язык в настоящее время . Но на время? Это было ужасно. И OpenGL пострадал за это.

Падение к апофеозу

Хотя я утверждаю, что 3D Labs нанесли смертельный удар, именно ARB вбил последний гвоздь в гроб.

Это история, о которой вы, возможно, слышали. Ко времени OpenGL 2.1 в OpenGL возникла проблема. У него было много устаревших вещей. API больше не был прост в использовании. Было 5 способов сделать что-то, и никто не знал, что было самым быстрым. Вы могли «изучить» OpenGL с помощью простых учебных пособий, но вы на самом деле не изучали API OpenGL, который дал бы вам реальную производительность и графическую мощь.

Поэтому ARB решила предпринять еще одно изобретение OpenGL. Это было похоже на «OpenGL 2.0» в 3D Labs, но лучше, потому что за ним стояла ARB. Они называли это «Пик Лонгс».

Что плохого в том, чтобы потратить некоторое время на улучшение API? Это было плохо, потому что Microsoft оставила себя уязвимой. Видите, это было во время переключения Vista.

В Vista Microsoft решила внести некоторые необходимые изменения в драйверы дисплея. Они заставляли драйверы подчиняться ОС для виртуализации графической памяти и многого другого.

Хотя можно спорить о достоинствах этого или о том, возможно ли это на самом деле, факт остается фактом: Microsoft считала D3D 10 только Vista (и выше). Даже если у вас было оборудование, поддерживающее D3D 10, вы не могли запускать приложения D3D 10, не имея также Vista.

Возможно, вы также помните эту Vista ... ну, скажем так, она не сработала. Таким образом, у вас была недостаточно эффективная ОС, новый API, который работал только на этой ОС, и новое поколение оборудования, которое нуждалось в том, чтобы этот API и ОС выполняли что-то большее, чем было бы быстрее, чем предыдущее поколение.

Тем не менее, разработчики могут получить доступ к функциям класса D3D 10 через OpenGL. Ну, они могли бы, если бы АРБ не был занят работой над Лонгс-Пиком.

По сути, ARB потратил полтора-два года на то, чтобы улучшить API. К тому моменту, когда OpenGL 3.0 фактически вышел, переход на Vista уже начался, Win7 уже не за горами, чтобы поставить Vista позади себя, и большинство разработчиков игр все равно не заботились о возможностях класса D3D-10. В конце концов, аппаратное обеспечение D3D 10 прекрасно работало с приложениями D3D 9. И с ростом количества портов ПК-консоль (или разработчиков ПК, которые стремятся к разработке консолей. Сделайте свой выбор), разработчикам не понадобились функции класса D3D 10.

Теперь, если разработчики имели доступ к этим функциям ранее через OpenGL на машинах WinXP, тогда разработка OpenGL могла бы получить столь необходимый шанс. Но АРБ упустил свою возможность. И ты хочешь знать худшую часть?

Несмотря на то, что они потратили два драгоценных года, пытаясь восстановить API с нуля ... они все же потерпели неудачу и просто вернулись к статус-кво (за исключением механизма устаревания).

Таким образом, АРБ ​​не только упустили важный момент , но и не выполнили задачу, которая заставила их упустить этот шанс. В значительной степени эпический провал вокруг.

И это история OpenGL против Direct3D. Сказка о упущенных возможностях, грубой глупости, преднамеренной слепоте и простой глупости.

Мне показалось странным, что все фокусируются на базе пользователей, когда речь идет о «разработчиках игр», а не «редакторах игр».

Для меня, как для разработчика, Linux - это кровавый беспорядок. Существует так много версий, менеджеров рабочего стола, комплектов пользовательского интерфейса и т. Д. Если я не хочу распространять свою работу как открытый исходный код, где пользователь может (попытаться) перекомпилировать ее, чтобы она соответствовала его уникальной комбинации пакетов, библиотек и настройки, это кошмар !

С другой стороны, Microsoft обеспечивает (большую часть времени) невероятную обратную совместимость и стабильность платформы. Можно настроить целую гамму машин с помощью одного установщика с закрытым исходным кодом, например, компьютеров под управлением Windows XP, Vista и 7, 32 и 64-разрядных версий без установки соответствующих распространяемых DX или VC и т. Д.

И последнее, ПОЖАЛУЙСТА, ВСЕ В ИНТЕРНЕТЕ ОСТАНОВИТЕ, СРАВНЯЯ ОТКРЫТИЕ И DIRECTX! Либо сравнивайте Direct3D с OpenGL, либо не делайте этого . DirectX обеспечивает поддержку ввода, поддержку звука, воспроизведение фильмов и т. Д., Чего нет в OpenGL.

Это потому, что на планете больше пользователей Windows, чем Linux и Mac. Правда в том, что люди делают вещи для того, у кого самый большой рынок.
То же самое касается мобильных телефонов: на Android и iPhone есть отличные игры, но Windows Mobile и Symbian не ...

Потому что Windows занимает более 90% рынка, а Linux (поскольку вы специально спросили о Linux) имеет репутацию множества пользователей, которые не любят платить за программное обеспечение. Является ли это правдой или нет, это не имеет значения; восприятие есть, и оно влияет на решения людей.

Поскольку Windows поддерживается огромной организацией, более десяти лет назад они решили, что хотят, чтобы разработка игр происходила на их платформе .

Это не было верно для Mac, и это не правда сейчас. Даже для iOS. Apple не предоставляет инструменты для разработки игр для iOS. Но это огромный рынок (там больше айфонов, чем компьютеров в 1995 году) с относительно небольшой конкуренцией, так что люди все равно это делают.

Что касается Linux, то здесь даже нет какой-то центральной организации, которая могла бы устанавливать какие-либо приоритеты. Направление, в котором движется Linux, более менее определяется кучкой очень хороших, но немного потусторонних программистов.

Чтобы создать компьютерную игру сегодня, вам нужно много 2D / 3D-художников, гейм-дизайнеров, сценаристов, актеров, тестеров и чего-то еще. Что касается реального программирования, вы можете просто использовать реальный игровой движок (CryEngine, Unreal Engine, Quake Engine, Source Engine). Таким образом, вы могли бы сделать все это без каких-либо реальных программистов.

Из-за этого и из-за специфики бизнеса программисты практически не говорят, какая платформа выбрана. И, как правило, менеджеры ищут поддержку, которую Microsoft обещает предложить, и имеют дело с вещами, которые каким-то образом доступны для их пользователей, а с открытым исходным кодом - нет.

По этой причине большая часть коммерческой разработки программного обеспечения для конечных пользователей выполняется на Windows.
Я работаю в компании, которая создает флеш-игры и поэтому не привязана к конкретной платформе. Однако все мы разрабатываем для Windows, потому что большинство инструментов, которые мы используем, не доступны для Linux.

Как уже говорили некоторые, наиболее важной частью является пользовательская база. 95% пользователей ПК используют Windows. ПК-геймеры используют почти исключительно Windows. Даже те, кто использует Mac или Linux, чаще всего запускают игры для Windows через некоторую виртуализацию или эмуляцию (с очень, очень немногими исключениями).

Но демография это еще не все. Я не стал бы недооценивать роль, которую Microsoft делает для повышения привлекательности платформы для разработчиков игр. В основном вы получаете полнофункциональный набор инструментов бесплатно , а главное - XNA Game Studio . Это позволяет разрабатывать не только для Windows, но и для Xbox360 . И с последней версией даже для телефонов WP7. Очевидно, поскольку это инструмент Microsoft, он использует DirectX, а не OpenGL.

Ewwww, я не Я использую Linux почти исключительно. Я выполняю двойную загрузку Windows для сборки Windows и использую Mac для сборки Mac, но это все.

Уловка - кроссплатформенная структура, которую мы разработали за эти годы. Наши игры построены на этом и ведут себя одинаково в Linux / OpenGL, Mac / OpenGL и Windows / Direct3D (и вскоре в iOS / OpenGL).

По общему признанию моя компания не делает названия AAA, таким образом, это может не относиться к ним, но мы действительно делаем лучшие казуальные игры (см. Веб-сайт - CSI: Нью-Йорк, Убийство, которое она написала, и два предстоящих 2011 года - примеры названий, использующих важные лицензии, Утраченные дела Шерлока Холмса 1 и 2 также были довольно успешными)

Я бы ни за что не отказался от gedit + gcc + gdb + valgrind.

1. Инерция. Если вы использовали Windows в прошлом, то переключение на что-то другое становится проблемой. Если вы работаете в Windows, DirectX проще и с большей вероятностью будет работать лучше, чем OpenGL.
2. Рыночная доля. Рыночная доля Windows на настольном компьютере больше, чем у OS X, которая, в свою очередь, больше, чем у Linux. Деньги говорят.
3. Марка. DirectX более известен, чем такие вещи, как SDL (это то, что вам нужно для репликации некоторых функций DirectX, выходящих за рамки OpenGL).
4. Меньше путаницы. Будет ли пользовательский Linux поддерживать только до OpenGL 1.4 или OpenGL 2+? Можете ли вы использовать учебник по OpenGL 2.0, например, введение в современный OpenGL. Глава 1. Графический конвейер в вашей версии Linux?

В наши дни Linux больше интересен, когда дело доходит до разработки игр, и большинству разработчиков было бы лучше финансово сделать версию порта OS X перед версией Linux (см. Такие вещи, как Steam). Даже тогда консольный рынок стоит больше, чем эти две платформы, объединенные для игр ...

Если вы хотели моно платформу DirectX - это хорошо. Если вы хотите быть кроссплатформенным, есть большой шанс, что вам придется использовать OpenGL, по крайней мере, на некоторых других платформах.

Ответ очевиден. Цель написания игры - заработать деньги. Больше конечных пользователей используют Windows, поэтому существует больший рынок, и вы ожидаете получить больше денег от игры для Windows, чем от игры для Linux. Это так просто.

Если вы когда-нибудь зададите себе вопрос «Почему кто-то делает ...», просто помните, что деньги заставляют мир вращаться.

Инструменты, инструменты, инструменты.

Вот к чему это сводится. Разрабатывайте в Windows, и вы получите доступ к лучшим инструментам разработки на планете. Ничто даже близко не приближается к отладчику Visual Studio, среды выполнения отладки DirectX великолепны, PIX великолепны, а сопоставимых эквивалентов просто нет на других платформах / API. Конечно, там есть что-то хорошее; Я не говорю, что инструменты на других платформах плохие, но те, что предоставляет MS, так далеко впереди (почетное исключение: Valgrind), что это даже не смешно.

Суть в том, что эти инструменты помогут вам. Они помогают вам делать вещи, они помогают вам быть продуктивными, они помогают вам сосредоточиться на ошибках в вашем собственном коде, а не борются с API, который никогда не ведет себя так, как описано в документации.

Итак, я перебрал все эти ответы, и как разработчик игр, у которого есть код для консольных игр, которые были на полках Walmart, у меня был совершенно другой ответ.

Распространение.

Видите ли, если вы хотите быть на консоли Nintendo, вы должны получить разрешение Nintendo, купить у заводов Nintendo, оплатить накладные расходы Nintendo, договориться с Walmart, разобраться со складом, вам нужны деньги на производство, печать коробок, доставку , чтобы сделать все страхование, и так далее.

Если вы хотите подключиться к XBox, конечно же, есть XBLA, но вам все еще нужно благословение Microsoft, вы должны подождать своей очереди, это десятки тысяч долларов только для выпуска патча и т. Д.

На iOS вам все еще нужно, чтобы у Apple все было в порядке, и они могут (и делают) капризно тянуть вас.

В Steam вам все еще нужно разрешение Valve или зеленый свет, и много денег.

,

На винде? Вы создали веб-сайт и кнопку загрузки.

,

Я не говорю, что другие платформы не ценны. Но когда вы пытаетесь разработать игру, происходит так много ужасных вещей, что для меня это обещание иметь возможность просто бить двоичный файл на сайте и сосредоточиться на работе - по крайней мере, для начала - действительно снижает множество потенциальных сбоев.

«Мы можем сделать порт XBLA позже, когда все будет стабильно».

И в меньшей степени уверен, что это хорошо и для Linux, и если семь клиентов хороши, вы можете начать с этого.

Но у Windows есть три огромных преимущества: действительно открытая разработка, действительно открытое развертывание и очень большая, очень активная клиентская база, которая заинтересована в причудливых вещах.

Трудно представить, где еще я бы предпочел начать.

Я думаю, что вы должны прочитать больше об истории DirectX и этой статье .

Я думаю, что MS выбрала DX вместо openGL, потому что им нравится блокировать людей на использование их собственной ОС.

Многое связано с политикой и контролем. В конце 90-х SGI и MS фактически договорились объединить усилия:

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

SGI вложила значительные средства в проект, MS - нет. SGI нуждался в MS больше, чем MS нуждался в SGI. Остальное уже история.

D3D и OpenGL - это два совершенно разных API, и разработчик должен сам выбрать, какой именно вам подойдет.

Просто потому, что Linux ужасно рухнул как настольная система. Как уже указывалось ранее, Linux - беспорядок для разработчиков (разные библиотеки, наборы инструментов и т. Д.)

Еще одна проблема - это фретардизм и отсутствие поддержки проприетарного программного обеспечения. Nvidia всегда предоставляет отличные (проприетарные) драйверы для Linux, однако Ubuntu и другие дистрибутивы его не поставляют. Для Linux, как и для Windows, отсутствует интерфейс двоичного драйвера. (В исходных текстах ядра есть текстовый файл с именем binaryApiNonsense.txt или что-то в этом роде). Сказав, что в Linux правильно поддерживается только оборудование Nvidia. Вы можете играть в большинство игр с программным обеспечением ID на оборудовании Nvidia под Linux.

Следующее, что инструменты разработки. MSFT обеспечивает отличную поддержку C ++, а отладчик Visual Studio лучше, чем GDB в отношении C ++. И последнее, но не менее важное: отсутствуют другие инструменты, такие как Photoshop. Также .net позволяет быстро создавать инструменты графического интерфейса. Многие игровые студии пишут свои инструменты для внутреннего использования, используя .net framework.

Я почти забыл: графическая система ужасна, в те времена, когда они просто портировали X11, потому что это была самая простая вещь, которая работала. Им не удалось должным образом спроектировать и внедрить современную графическую систему, которая есть в OSx и Win.