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

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

397 голосов | спросил 4 revs, 3 users 40%
M.Sameer
1 Jam1000000amThu, 01 Jan 1970 03:00:00 +030070 1970, 03:00:00

14 ответов


1156

Многие из ответов здесь действительно, очень хорошие. Но 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 Version 3. Это был общепринятый оскорбленный. И не без оснований; глядя на D3D v3, код похож на Ковчег Завета.

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

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

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

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

  

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

     

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

     

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

Это было рождение драйверов 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. Multitexture наконец, но ... нет оборудования T & L. OpenGL имел always конвейер 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 были extreme , характерные для оборудования NVIDIA. Не было предпринято никаких попыток абстрагироваться от аппаратного обеспечения NVIDIA; SM 1.0 был именно тем, что делали GeForce 3.

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

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

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

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

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

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

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

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

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

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

Хотите что-то даже глупое?

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

В D3D v7 Microsoft представила концепцию Vertex Buffers. Они выделяют валиды памяти GPU для хранения данных вершин.

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

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

для аппаратного обеспечения T & L .

Один язык для уничтожения всех

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

Ты ... можешь сказать это. Введите 3D-лаборатории .

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

GLSL - это хороший язык now . Но на время? Это было ужасно. И 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 ... um, давайте просто скажем, что это не сработало. Таким образом, у вас была неэффективная ОС,новый API, который работал только на этой ОС, и новое поколение аппаратного обеспечения,

Однако разработчики могли получить доступ к функциям D3D 10-класса через OpenGL. Ну, они могли бы, если бы ARB не был занят работой над Longs Peak.

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

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

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

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

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

ответил markijbema 23 Jam1000000amMon, 23 Jan 2012 11:06:21 +040012 2012, 11:06:21
133

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

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

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

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

ответил markijbema 23 Jam1000000amMon, 23 Jan 2012 11:06:21 +040012 2012, 11:06:21
88

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

ответил markijbema 23 Jam1000000amMon, 23 Jan 2012 11:06:21 +040012 2012, 11:06:21
50

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

ответил markijbema 23 Jam1000000amMon, 23 Jan 2012 11:06:21 +040012 2012, 11:06:21
11

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

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

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

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

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

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

ответил markijbema 23 Jam1000000amMon, 23 Jan 2012 11:06:21 +040012 2012, 11:06:21
10

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

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

ответил markijbema 23 Jam1000000amMon, 23 Jan 2012 11:06:21 +040012 2012, 11:06:21
6

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

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

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

Я бы не отказался от gedit + gcc + gdb + valgrind для чего-нибудь еще.

ответил markijbema 23 Jam1000000amMon, 23 Jan 2012 11:06:21 +040012 2012, 11:06:21
4
  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, например
ответил markijbema 23 Jam1000000amMon, 23 Jan 2012 11:06:21 +040012 2012, 11:06:21
4

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

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

ответил markijbema 23 Jam1000000amMon, 23 Jan 2012 11:06:21 +040012 2012, 11:06:21
4

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

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

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

ответил markijbema 23 Jam1000000amMon, 23 Jan 2012 11:06:21 +040012 2012, 11:06:21
4

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

Распределение.

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

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

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

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

.

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

.

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

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

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

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

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

ответил markijbema 23 Jam1000000amMon, 23 Jan 2012 11:06:21 +040012 2012, 11:06:21
3

Думаю, вам стоит больше узнать об истории DirectX и Эта статья .

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

ответил markijbema 23 Jam1000000amMon, 23 Jan 2012 11:06:21 +040012 2012, 11:06:21
1

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

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

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

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

ответил markijbema 23 Jam1000000amMon, 23 Jan 2012 11:06:21 +040012 2012, 11:06:21
0

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

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

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

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

ответил markijbema 23 Jam1000000amMon, 23 Jan 2012 11:06:21 +040012 2012, 11:06:21

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132