Целью данного поста является перевод одного из таких экскурсов в историю, написанного Джейсоном МакКессоном (Jason L. McKesson) в ответ на вопрос «Почему разработчики игр предпочитают Windows». Этот текст вряд ли отвечает на поставленный вопрос, но историю развития и противостояния двух самых популярных графических API он описывает очень красочно и довольно подробно, поэтому в переводе я сохранил авторскую разметку. Текст написан в середине 2011 года и охватывает промежуток времени, начинающийся незадолго до появления Direct3D и до момента написания. Автор оригинального текста является опытным разработчиком игр, активным участником StackOverflow и создателем обширного учебника о современном программировании 3D-графики. Итак, предоставим слово Джейсону.
Предисловие
Прежде чем мы начнём, я хотел бы сказать, что знаю больше об OpenGL, чем о Direct3D. В своей жизни я не написал ни строчки кода на D3D, но писал руководства по OpenGL. Но то, о чём я хочу рассказать — вопрос не предубеждения, а истории.
Рождение конфликта
Однажды, где-то в начале 90-х, Microsoft огляделись вокруг. Они увидели, что SNES и Sega Genesis — это очень здорово, на них можно поиграть во множество экшн-игр и всего такого. И они увидели ДОС. Разработчики писали досовские игры как консольные: близко к железу. Тем не менее, в отличие от консолей, где разработчик знал, какое железо будет у пользователя, дос-разработчики были вынуждены писать под множество конфигураций. А это намного сложнее, чем кажется.
Но у Microsoft была бо?льшая проблема: Windows. Видите ли, Windows хотела полностью владеть железом в отличие от ДОС, которая позволяла разработчикам делать всё что угодно. Владение железом необходимо для взаимодействия между приложениями. Но такое взаимодействие — это в точности то, что ненавидят разработчики игр, потому что оно потребляет драгоценные ресурсы, которые они могли бы использовать для всяких крутых вещей.
Для продвижения разработки игр на 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 решили добавить OpenGL и в Windows 95.
Чтобы сманить разработчиков софта для рабочих станций на Windows, Microsoft решили подкупить их доступом к новомодным 3D-ускорителям. Они реализовали протокол для устанавливаемых клиентских драйверов: графическая карта могла заменить программный OpenGL от Microsoft своей аппаратной реализацией. Код автоматически использовал аппаратный OpenGL, если таковой был доступен.
Однако, в те времена потребительские видеокарты не имели поддержки OpenGL. Это не остановило Кармака от портирования Quake на OpenGL на рабочей станции SGI. В readme-файле GLQuake можно прочитать следующее:
Теоретически, glquake запустится на любой реализации OpenGL, которая поддерживает расширение texture objects. Но пока вы не запустите её на очень мощном железе, которое ускоряет всё, что нужно, работать она будет непростительно медленно. Если игре потребуется работать через какие-либо программные эмуляции, её производительность скорее всего не превысит один кадр в секунду.
В настоящее время (март 1997), единственной полностью совместимой с opengl железкой, способной потянуть glquake на приемлемом уровне, является ОЧЕНЬ дорогая видеокарта intergraph realizm. 3dlabs существенно увеличили её производительность, но с имеющимися драйверами она всё ещё недостаточно подходит для игры. Некоторые из драйверов от 3dlabs для плат glint и permedia ещё и крэшат NT при выходе из полноэкранного режима, поэтому я не рекомендую запускать glquake на железе от 3dlabs.
3dfx предоставляет opengl32.dll, которая реализует все нужное для glquake, но это не полная реализация opengl. Другие opengl-приложения скорее всего с ней не заработают, поэтому рассматривайте её в основном как «драйвер для glquake».
Это было рождением miniGL драйверов. В конечном итоге они эволюционировали в полноценные реализации OpenGL, как только железо стало достаточно мощным для аппаратной поддержки этой функциональности. nVidia стала первой, кто предложил полную реализацию OpenGL. Другие поставщики всё ещё медлили, что стало одной из причин перехода разработчиков на Direct3D, поддерживаемый более широким спектром оборудования. В конце концов остались только nVidia и ATI (которая сейчас AMD), и у обеих имелись хорошие реализации OpenGL.
Рассвет OpenGL
Итак, участники определены: Direct3D против OpenGL. Это поистине удивительная история, учитывая то, как плох был D3D v3.
Совет по архитектуре OpenGL (Architectural Review Board, ARB) — это организация, ответственная за поддержание и развитие OpenGL. Они выпускают множество расширений, содержат репозиторий с расширениями, и создают новые версии API. ARB — это комитет, состоящий из большого количества игроков индустрии компьютерной графики и некоторых производителей ОС. Apple и Microsoft в разное время тоже были членами ARB.
3Dfx выходит на сцену со своей Voodoo2. Это первая видеокарта, позволяющая делать мультитекстурирование, которое не было ранее предусмотрено в OpenGL. В то время как 3Dfx была решительно против OpenGL, nVidia, следующий производитель чипа с мультитекстурированием (TNT1), были без ума от OpenGL. Тогда ARB выпустил расширение GL_ARB_multitexture, которое предоставляло доступ к множественным текстурам.
Тем временем появляется Direct3D v5. Теперь D3D действительно стал API, а не какой-то несуразицей. В чём же проблема? В отсутствии мультитекстурирования.
Упс.
Но это не доставляло таких неудобств, какие могло бы доставить, потому что почти никто не использовал множественное текстурирование. Мультитекстурирование почти не вредит производительности, и во многих случаях разница незаметна на фоне многопроходности. И конечно, разработчики игр очень любят чтобы их игры уверенно работали на старом железе, которое не имело поддержку множественных текстур, поэтому многие игры были выпущены без неё.
D3D вздохнул с облегчением.
Время шло, и nVidia выкатили GeForce 256 (не путать с самым первым GeForce GT-250), прекратив борьбу на рынке графических плат на следующие два года. Главным конкурентным преимуществом этой платы была возможность делать преобразования вершин и освещение (transformation & lighting, T&L) аппаратно. Но это ещё не всё: nVidia любила OpenGL настолько, что их T&L-движок фактически и был OpenGL. Почти буквально! Как я понимаю, некоторые из их регистров получали на вход напрямую численные значения переменных типа GLenum.
Выходит Direct3D v6. Наконец то подоспело множественное текстурирование… но без аппаратного T&L. В OpenGL всегда был T&L-конвейер, хотя до GeForce 256 он был реализован программно. Поэтому для nVidia оказалось довольно просто переделать программную реализацию в аппаратное решение. В D3D аппаратное T&L появилось только к седьмой версии.
Заря эпохи шейдеров, OpenGL во мгле
Затем появилась GeForce 3. В то же самое время произошло много интересных вещей.
В Microsoft решили, что они больше не собираются опаздывать. Поэтому вместо того, чтобы смотреть, что сделает nVidia, и копировать их разработки уже пост-фактум, Microsoft приняли изумительное решение: пойти и поговорить. И они полюбили друг друга, и у них появилась совместная маленькая консоль.
Шумный развод произошёл позже, но это совсем другая история.
Для рынка PC это значило, что GeForce 3 вышла одновременно с D3D v8, и нетрудно видеть, как GeForce 3 повлияла на шейдеры D3D v8. Пиксельные шейдеры Shader Model 1.0 были очень сильно заточены под оборудование nVidia. Не было предпринято ни единой попытки сделать хоть что нибудь для абстрагирования от железа nVidia. Shader Model 1.0 стала тем, для чего предназначена GeForce 3.
Когда ATI ворвалась в гонку производительности видеокарт со своей Radeon 8500, появилась одна проблема. Пиксельный конвейер Radeon 8500 оказался более мощным, чем у nVidia. Поэтому Microsoft выпустила Shader Model 1.1, которая в основном была тем, для чего предназначена 8500.
Это звучит как поражение D3D, но успех и провал — понятия относительные. На самом деле эпический провал поджидал OpenGL.
В nVidia очень любили OpenGL, поэтому после выхода GeForce 3 они выпустили целую пачку расширений для OpenGL. Проприетарных расширений, которые работали только на nVidia. Естественно, когда появилась плата 8500, она не могла использовать ни одно из них.
Итак, на D3D 8 вы могли хотя бы запустить шейдеры SM 1.0. Конечно, чтобы использовать всю крутость 8500, приходилось писать новые шейдеры, но код хотя бы работал.
Чтобы получить любые шейдеры на Radeon 8500 в OpenGL, ATI пришлось разработать несколько расширений для OpenGL. Проприетарных расширений, которые работали только на ATI. В итоге, чтобы разработчики могли заявить, что они прикрутили к своему движку шейдеры, им приходилось писать отдельный код для nVidia и отдельный код для ATI.
Вы возможно спросите: «А где же был комитет ARB, который должен поддерживать OpenGL на плаву?». А были они там, где в конечном итоге оказываются многие комитеты: они сидели и тупили.
Обратите внимание, выше я упомянул ARB_multitexture, потому что это расширение глубоко замешано во всей ситуации. Стороннему наблюдателю казалось, что ARB вообще хочет избежать идеи шейдеров. Они решили, что если они вбухают достаточно конфигурируемости в фиксированный конвейер, то он сравняется по своим возможностям с программируемым шейдерным конвейером.
ARB выпускали расширения одно за другим. Каждое расширение со словами «texture_env» в названии было попыткой залатать этот устаревающий дизайн. Посмотрите на список расширений: таких расширений было выпущено восемь штук, и многие из них были переведены в основную функциональность OpenGL.
В то время Microsoft входила в ARB, и покинула его только к выпуску D3D 9, поэтому возможно, Microsoft саботировали OpenGL некоторым образом. Лично я сомневаюсь в этой теории по двум причинам. Во-первых, они должны были бы заручиться поддержкой других членов Комитета, потому как каждый участник имеет всего один голос. Во-вторых, что более важно, Комитету не нужна была помощью Microsoft чтобы всё запороть, свидетельства чему мы увидим далее.
В итоге ARB, скорее всего под давлением ATI и nVidia (обе являются активными участниками), наконец очнулся и ввёл в стандарт ассемблерные шейдеры.
Хотите ещё более дурацкую историю?
Аппаратное T&L. Это то, что в OpenGL было изначально. Чтобы получить максимально возможную производительность аппаратного T&L, нужно хранить данные вершин на GPU. Все-таки, GPU — это основной потребитель вершинных данных.
В D3D v7 Microsoft ввела концепцию вершинных буферов, которые выделяют куски памяти в GPU и размещают там данные вершин.
Хотите знать когда в OpenGL появилась эквивалентная функциональность? Да, nVidia, как самый большой любитель OpenGL, выпустила своё расширение для хранения массивов вершин на GPU ещё во времена выхода GeForce 256. Но когда же ARB представил такую функциональность?
Два года спустя. Это было после того, как она утвердили вершинные и фрагментные (пиксельные в терминах D3D) шейдеры. Столько времени ушло у ARB чтобы разработать кросс-платформенное решение для хранения вершинных данных в памяти GPU. И это то, что необходимо, чтобы аппаратное T&L достигло максимальной производительности.
Один язык, чтобы убить их всех
Итак, OpenGL был сломан в течение какого-то времени. Отсутствовали кросс-платформенные шейдеры и аппаратно-независимое хранение вершин в GPU, в то время как пользователи D3D наслаждались и тем и другим. Могло ли стать ещё хуже?
Можно сказать, что могло. Встречайте: 3D Labs.
Вы спросите: кто же они? Они — мёртвая компания, которую я считаю истинным убийцей OpenGL. Конечно, общая несостоятельность Комитета сделала OpenGL уязвимым, в то время как он должен был рвать D3D в клочья. Но по-моему, 3D Labs — возможно единственная причина текущего положения OpenGL на рынке. Что они для этого сделали?
Они разработали язык шейдеров для OpenGL.
3D Labs были умирающей компанией. Их дорогостоящие GPU были вытеснены с рынка рабочих станций всё возрастающим давлением nVidia. И в отличие от nVidia, 3D Labs не были представлены на потребительском рынке; победа nVidia означала бы смерть для 3D Labs.
Что в итоге и случилось.
В стремлении оказаться на плаву в мире, которому были не нужны их продукты, 3D Labs заявились на конференцию Game Developer Conference с презентацией того, что они назвали «OpenGL 2.0». Это был OpenGL API, переписанный с нуля. И это имело смысл, ибо в те времена в API OpenGL было полно хлама (который, впрочем, остаётся там и по сей день). Посмотрите хотя бы на то, насколько эзотерически сделаны загрузка и биндинг текстур.
Частью их предложения был язык шейдеров. Да, именно он. Тем не менее, в отличие от имеющихся кросс-платформенных расширений, их язык шейдеров был «высокоуровневым» (C — это высокий уровень для языка шейдеров).
В это же время в Microsoft работали над своим собственным языком шейдеров. Который они, включив всё своё коллективное воображение, назвали… Высокоуровневым Языком Шейдеров (HLSL). Но их подход к языку был фундаментально иным.
Наибольшей проблемой языка от 3D Labs было то, что он был встраиваемым. Microsoft полностью самостоятельно определяла свой язык. Они выпустили компилятор, который генерировал ассемблерный код для шейдеров SM 2.0 (или выше), который, в свою очередь, можно было скармливать D3D. Во времена D3D v9, HLSL никогда не касался D3D напрямую. Он был хорошей, но необязательной абстракцией. У разработчика всегда была возможность взять выхлоп компилятора и подправить его для максимальной производительности.
В языке от 3D Labs ничего этого не было. Вы отдаёте драйверу C-подобный язык, и он создаёт шейдер. На этом всё. Никакого ассемблерного шейдера, ничего, что можно скормить чему-то ещё. Только объект OpenGL, представляющий шейдер.
Для пользователей OpenGL это означало, что они становились подвержены капризам разработчиков OpenGL, которые только научились компилировать ассемблероподобные языки. В компиляторах новорождённого языка шейдеров OpenGL (GLSL) свирепствовали баги. Что ещё хуже, если вам удавалось заставить шейдер корректно компилироваться на различных платформах (что уже само по себе было большим достижением), то он всё ещё был подвержен оптимизаторам тех времён, которые были не так уж оптимальны, как могли бы быть.
Это было большим, но не единственным недостатком GLSL. Далеко не единственным.
В D3D, как и в старых ассемблерных языках OpenGL, можно было смешивать и всячески комбинировать вершинные и фрагментные шейдеры. Можно было использовать любой вершинный шейдер с любым совместимым фрагментным шейдером, если они взаимодействовали через одинаковый интерфейс. Более того, допускалась даже некоторая несовместимость: например, вершинный шейдер мог подать на выход значение, которое не использовалось фрагментным шейдером.
В GLSL ничего такого не было. Вершинный и фрагментный шейдер сплавлялись воедино, образовывая нечто, названное компанией 3D Labs «программным объектом». Поэтому, для совместного использования нескольких вершинных и фрагментных шейдеров в различных комбинациях, приходилось создавать несколько программных объектов. Это стало причиной второй по величине проблемы.
3D Labs думали, что они самые умные. Они взяли C/C++ за основу для модели компиляции GLSL. Это когда вы берёте один c-файл и и компилируете его в объектный файл, а затем берёте несколько объектных файлов и компонуете их в программу. Именно так компилируется GLSL: сначала вы компилируйте вершинный или фрагментный шейдер в шейдерный объект, затем помещаете эти объекты в программный объект и компонуете их воедино чтобы наконец сформировать программу.
В теории это позволяло появиться таким крутым вещам, как «библиотечные» шейдеры, которые содержат код, вызываемый основным шейдером. На практике это приводило к тому, что шейдеры компилировались дважды: один раз на стадии компиляции и второй раз на стадии компоновки. В частности, этим славился компилятор от nVidia. Он не генерировал какой-либо промежуточный объектный код; он компилировал вначале, выбрасывал полученный результат и компилировал заново на стадии компоновки.
Таким образом, чтобы приделать вершинный шейдер к двум разным фрагментным шейдерам, приходилось компилировать намного больше, чем в D3D. Особенно с учётом того, что вся компиляция производится оффлайново, а не перед непосредственным исполнением программы.
У GLSL были и другие проблемы. Возможно, было бы неправильным сваливать всю вину на 3D Labs, ибо в конечном итоге ARB утвердили и включили в OpenGL язык шейдеров (но ничего больше из предложений 3DLabs). Однако, изначальная идея всё равно была за 3D Labs.
И теперь самое печальное: 3D Labs были правы (в основном). GLSL не векторный язык, каким в то время был HLSL. Так случилось потому, что железо 3D Labs было скалярным (как современное железо от nVidia), и они были полностью правы в выборе направления, которому позднее последовали многие производители оборудования.
Они были правы и с выбором модели компиляции для «высокоуровневого» языка. Даже D3D в итоге к этому пришёл.
Проблема в том, что 3D Labs были правы в неправильное время. И в попытках попасть в будущее преждевременно, в попытках быть готовыми к будущему, они отставили в сторону настоящее. Это выглядит как T&L-функциональность в OpenGL, которая была в нём всегда. За исключением того, что T&L-конвейер OpenGL был полезным и до появления аппаратного T&L, а GLSL был обузой до того как остальной мир догнал его.
GLSL — это хороший язык сейчас. Но что было в то время? Он был ужасен. И OpenGL пострадал от этого.
На подходе к апофеозу
Я поддерживаю ту точку зрения, что 3D Labs нанесли OpenGL смертельный удар, но последний гвоздь в крышку гроба забил сам ARB.
Возможно вы слышали эту историю. Во времена OpenGL 2.1, у OpenGL были большие проблемы. Он тащил за собой огромный груз совместимости. API больше не был простым в использовании. Одну вещь можно было сделать пятью разными способами и непонятно какой из них быстрее. Можно было «изучить» OpenGL по простым руководствам, но при этом вы не изучали тот OpenGL, который даёт настоящую графическую мощь и производительность.
ARB решили предпринять ещё одну попытку изобрести OpenGL. Это было как «OpenGL 2.0» от 3D Labs, но лучше, потому что за этой попыткой стоял ARB. Они назвали это «Longs Peak».
Что такого плохого в том, чтобы потратить немного времени на улучшение API? Плохо то, что Microsoft оказалась в довольно шатком положении. Это было время перехода на Vista.
В Vista Microsoft решили внести давно напрашивающиеся изменения в графические драйверы. Они заставили драйверы обращаться к ОС за виртуализацией графической памяти и многим другим.
Можно долго спорить о достоинствах такого подхода, и о том, был ли он вообще возможен, но факт остаётся фактом: Microsoft сделала D3D 10 только для ОС Vista и выше. Даже на поддерживающем D3D железе было невозможно запустить D3D приложение без Висты.
Вы возможно помните, что Виста… скажем так, работала не очень хорошо. Итак, у нас была неторопливая ОС, новый API, который работал только на этой ОС, и новое поколение железа, которое нуждалось в этом API и ОС чтобы делать нечто большее, чем просто превосходить предыдущее поколение в производительности.
Тем не менее, разработчики могли использовать функциональность уровня D3D 10 через OpenGL. То есть могли бы, если бы ARB не был занят работой над Long Peaks.
ARB потратили добрые полтора-два года, работая над улучшением API. Ко времени выхода OpenGL 3.0 переход на Висту закончился, Windows 7 была на подходе, и разработчиков игр больше не заботила функциональность уровня D3D 10. В конце концов, оборудование для D3D 10 прекрасно работало с приложениями на D3D 9. С увеличением темпов портирования с ПК на консоли (или с переходом ПК-разработчиков на консольный рынок), разработчикам всё меньше была нужна функциональность D3D 10.
Если бы разработчики получили доступ к этой функциональности даже на Windows XP, развитие OpenGL могло бы получить живительный заряд бодрости. Но ARB упустили эту возможность. А хотите знать что самое ужасное?
ARB не смогли изобрести API с нуля несмотря на трату двух драгоценных лет на попытки сделать это. Поэтому они вернули статус-кво, добавив лишь механизм для объявления функциональности устаревшей.
В итоге ARB не только упустили ключевые возможности, но и не выполнили ту работу, которая привела их к этому упущению. Это был epic fail по всем направлениям.
Такова история о противостоянии OpenGL и Direct3D. История упущенных возможностей, величайшей глупости, умышленного безрассудства и банальных нелепостей.
Комментарии (107)
Delics
09.09.2016 20:27+1> последний гвоздь в крышку гроба
Когда это OpenGL успело умереть?
MarazmDed
09.09.2016 21:27Я не припомню момента, когда OpenGL жил в играх. История игр — это история DirectX. А так, да, оба живы. С трудом представляю себе какую-нибудь САПР, на директе. Мне кажется, сравнение не совсем корректное. OpenGL — это чисто графическая библиотека, а DirectX — это комбайн технологий для ИГР.
Zenitchik
09.09.2016 21:54+1Homeworld. Ради него мне пришлось поставить OpenGL.
MarazmDed
09.09.2016 22:29Это исключение. Можно назвать еще несколько игр. Можно вспомнить, что некоторые игры поддерживают обе библиотеки. Но тем не менее, это исключение.
lolipop
09.09.2016 22:50поставить OpenGL
что?
iOrange
09.09.2016 23:32+3Раньше существовали отдельно OpenGL драйвера для видеокарт.
Помню что Serious Sam, еще первый, не запускался если не стояли драйвера OpenGL.
navion
09.09.2016 23:34MS не включила его в W2k.
pda0
10.09.2016 00:25Простите, но это не правда. О чём, собственно, и написано по ссылке. M$ подумывали вообще исключить OpenGL (со временем), потому что тогда участвовали в проекте Farenheit, который должен был создать более продвинутое API на замену OpenGL и Direct3D.
В связи с этим они перенесли в Win2k политику Win98: Все драйверы, идущие вместе с операционной системой, если поддерживают 3D ускорение, то только для Direct3D, аппаратную поддержку OpenGL производитель должен делать сам (если захочет). Поскольку в Win9x так и было, а в NT4 вообще не было родного аппаратного 3D ускорения (только с драйверами и только OpenGL), то для пользователей не изменилось ровным счётом ничего.
Потом подобные страшилки были во времена Vista, когда все кричали «а-а-а-а! M$ выкидывает OpenGL!!!1111» А оказалось, что лишь обновили свою програмную реализацию с 1.1 до 1.4. Хотя вряд ли кто-то сможет ответить — на фига… Ни то, ни то в тот момент было абсолютно никому не интересно. Да ещё и в програмном варианте.
Nomad1
10.09.2016 09:32Кстати, в 8+ уже программная поддержка на уровне 2.0, текстуры до 1024x1024 и даже есть поддержка S3TC. При чем, я подозреваю, что там не сугубо программно все, а враппер над DirectX — уж слишком хорошо работает. Если бы не прибитый гвоздями размер текстур, уже бы работали некоторые 3D пакеты и разумного уровня игры из коробки.
Это все создает видимость, что OpenGL в системе есть и работает, некоторый софт пытается запуститься и падает в середине, а не сразу при запуске. И почти ни одна программа не может толком сообщить, что именно оказалось поломано.
somniator
09.09.2016 22:15Autodesk Inventor на DirectX
Moog_Prodigy
10.09.2016 11:203DSMax позволяет выбирать или DirectX или OpenGL. Или вообще «программная эмуляция», если совсем нестандартное железо. Ну, по меньшей мере, до 7ой версии включительно.
Alex_ME
10.09.2016 00:24+1Новый Doom. Насчет других не знаю. Warzone 2100 (специфическая вещь), да и тот же Minecraft.
dendron
10.09.2016 02:32+2Практически все игры на движках от id Software, а их не мало, работали через OpenGL.
VBKesha
10.09.2016 09:48+2Quake 3 и игры на его движке, по моему уже о многом говорит.
Unreal был мультидвижковый.
Half-Life лично у меня в OpenGL шёл в разы лучше.MarazmDed
11.09.2016 16:18А лично у меня на Directе все шло, а на OpenGLе вылазили артефакты в играх. Но это — мимо. Речь шла о разработчиках. А разработчики, используя Direct, получают не только графическую библиотеку, в отличии от.
susnake
10.09.2016 10:46+2Я специально залез на вики, когда читал статью и нашел вот такой лист игр. Причем там не только «старые», но и новые игры. И к тому есть игры, которые запускаются под Windows. Как пример:
Wolfenstein: The Old Blood
Wolfenstein: The New Order
Spore
Amnesia: A Machine for Pigs
Amnesia: The Dark Descent
Так что и крупные проекты на нем разрабатывают.MarazmDed
10.09.2016 13:16Прекрасно. А теперь делаем точно такой же список игр под DirectX. Подозреваю, что получим нечто в десятки раз более объемное ;) О чем и была речь. Более того, DirectX <> Direct3D. В нем куча подсистем, аналогов которого у
OpenGL в принципе нет. DirectSound, DirectPlay — это как минимум.susnake
10.09.2016 13:24Ну дык и
и под линух игорь нет
И говорить только из-за этого, что линух для геймдева мертв как-то некорректно.MarazmDed
10.09.2016 14:19Исходно я не говорил, что OpenGL мертв. Я лишь указал на то, что OpenGL — не совсем игровой фреймворк. DirectX — предоставляет гейм-девелоперам больше возможностей.
staticlab
10.09.2016 17:01+1DirectPlay давно deprecated, DirectSound не имеет аппаратной акселерации.
MarazmDed
11.09.2016 16:16И? Это противоречит тезису, что DirectX — это подмножество библиотек, а не только графическая библиотека?
Mairon
11.09.2016 23:51Ну строго говоря Khronos (ARB) тоже разрабатывает OpenAL (SL/ES), OpenCL вдобавок к OpenGL, поэтому тоже есть необходимые библиотеки, аналогичный Direct3D, DirectCompute и DirectSound.
MarazmDed
12.09.2016 09:05Ну ок, молодцы. Значит я был не прав и сравнивать DirectX с OpenGL — корректно.
SurPaul
10.09.2016 17:01А как же Android?
vorphalack
11.09.2016 08:43а что андроид? что там, что, подозреваю, на яблоках, на чернике и вообще всем кроме винфона(или там тоже?) бал правит Open GL _ES_. но опять же, даже топовые смартфоны, кмк, как раз болтаются в плане производительности на том уровне, когда «большой» опенгл еще был «жив».
MarazmDed
11.09.2016 16:20Ну андроид — это совсем свежая история. Описанные события — про царство винды
zx80
10.09.2016 17:01Здрасьте, приехали!!! Несметное колличество игр на OpenGL!!! — это все игры id Software — думы, квейки, вольфенштейны new order, rage — и игры сторонних разработчиков, которые купили движки id Tech 3, 4, 5 (Brink, Prey, Star Wars Jedi Knight II, Medal of Honor: Allied Assault, Dishonored 2, The Evil Within и др.). А теперь будут игры на id Tech 6
сразу видно вы игрок ещё тот!
Sleepwalker_ua
10.09.2016 18:29KSP гораздо лучше ведет себя на OpenGL — практически без ущерба для графония (он там кстати и так не самый крутой, но все же!!) отжираемые ресурсы падают в 1,5-2,5 раза!
Ну сами посудите, на максимуме настроек на дирХ он жрет ~350Мб видеопамяти и (в ангаре с кораблем на 60 деталей), а на опенГЛ — всего 225 при тех же условиях и в том же ангаре. Я уж не говорю, что на опенГЛ существенно снижается потребность в оперативе для ресурсов и игра позволяет строить крафты на 160-200 деталей без лагов и регулярных вылетов, тогда как на дирХе — только 70-100 деталей максимум и начинается слайдшоу…
Drakoninarius
12.09.2016 12:21И все же основная нагрузка в KSP идет не на видеокарту или оперативу(если быть честным, оперативу там жрут не детальки, а моды, т.к. игра загружает их целиком в оперативку и держит там всё время, даже когда они не используются), а на процессор т.к. вся сложная физика в игре просчитывается именно на нём. То, что вы описываете, актуально для совсем уж древних сборок с малым количеством оперативы и видеопамяти.
Sleepwalker_ua
12.09.2016 20:22я так считаю, что мое железо прямо древним назвать нельзя — 8гб оперативной памяти, ксеон 5440 в разгоне (3.22ГГц), гтс450. Да, это не топовая железяка за пару тысяч у.е., но так и игра имеет весьма скромный графоний, который до уровня кукурузисов не дотягивает и близко, тем более — с учетом относительно невысокого разрешения (1400х1050р). Во всяком случае, более тяжелые игрульки этот системник пока еще вполне тянет.
Затык именно в том, что у меня версия 1.0.4 х86 и всего с тремя модами — ну, на данный момент, коненчо (хеви рокетс, реалсолар и аттачсистментс) и она оперативы более 3Гб не умеет адресовать. Это влечет за собой крэши регулярные. Использование библиотек опенГЛ, как ни странно, снижает запросы по оперативке, очевидно — благодаря оптимизации текстур, которые так или иначе обрабатывает процессор.Drakoninarius
13.09.2016 16:15значит пора обновить игру;)
В тот же Real Solar System было почти невозможно играть имея ограничение в 3 гига оперативки, даже с опенГЛ вылеты были регулярны. С выходом 1.1 проблема решилась.Sleepwalker_ua
13.09.2016 17:10никак руки не дойдут ;-) давно уже не играл даже, если честно…
на 1.1 действительно меньше лагов и вылетов по памяти?
truggvy
12.09.2016 14:46«Я не припомню момента, когда OpenGL жил в играх.» — вы забываете про мобильники. В iOS и Android, до выхода Metal и Vulkan, безраздельно правил OpenGL ES. Да и сейчас ситуация не сильно изменилась.
MarazmDed
12.09.2016 17:52Статья описывает те времена, когда из игровых платформ самой популярной была винда. На ней подавляющее большинство игр были директовыми. Да, Опенгл поддерживала куча игр, да были даже чисто опенглные игры, что не противоречит тому, что самая часто используемая библиотека — директ. Сейчас ситуация меняется коренным образом. Тут и мобильные платформы, тут и стим и другие. И я не за директ и не за опенгл. Я — за разнообразие. Больше библиотек — лучше программистам.
RedVelvet
09.09.2016 20:28+1Нужно быть очень хорошим кодером чтобы разобраться во всем этом зоопарке API и одновременно разрабатывать проект.
MarazmDed
10.09.2016 13:17+1Нужно быть хорошим ПРОГРАММИСТОМ. Хороший программист примерно за 14 дней разберется в любом API.
RedVelvet
10.09.2016 17:54+1Ок, давайте перенесем вас на 15 лет назад дадим железки тех времён и посмотрим что вы будете делать. Поддержка первых видеокарт, поддержка софверного рендера, поддержка экзотических API и т.д. И что бы все это работало.
MarazmDed
11.09.2016 16:06На 15 лет назад — легко. Изучу DirectX — этого хватает с лихвой, чтобы все заработало.
immaculate
11.09.2016 10:07+1Не верю, что за 14 дней можно изучить все «особенности» любого API. Скажем, в документации к API будет сказано, что для вывода точки красного цвета, надо вызывать функцию API «putPixel(x, y, z, color.RED)». Программист на 15-й день так и пишет в коде. Точка выводится зеленым цветом. Двое суток отладки, чтения форумов, блогов и исходников (если они вообще есть). Выясняется, что если инициализация была выполнена в отладочном режиме, то color.RED заменяется на color.GREEN.
Ну, надуманный пример, но каждый, кто работал с библиотеками, знает, что все они полны подводных камней. Помню, в 90-х года еще было принято среди некоторых личностей, в том числе, очень известных разработчиков, все писать самостоятельно с нуля, включая, там, какой-нибудь парсер модного тогда XML. Потому что порой стоимость поиска и обхода ошибок в чужих библиотеках и API была намного выше.MarazmDed
11.09.2016 16:15-1Не верю, что за 14 дней можно изучить все «особенности» любого API.
Все — нельзя. Разобраться и начать работать — можно.
Скажем, в документации к API будет сказано, что для вывода точки красного цвета, надо вызывать функцию API «putPixel(x, y, z, color.RED)». Программист на 15-й день так и пишет в коде. Точка выводится зеленым цветом. Двое суток отладки, чтения форумов, блогов и исходников (если они вообще есть). Выясняется, что если инициализация была выполнена в отладочном режиме, то color.RED заменяется на color.GREEN.
Пример как раз про КОДЕРА, а не про ПРОГРАММИСТА. Двое суток отладки на такую херню — явный перебор. Но дело не в этом. Дело в том, что тонкости и подводные камни не мешают писать код. И досконально некоторые библиотеки можно изучать и год и два. Однако ПРОГРАММИСТ за 14 дней способен разобраться и в чужом коде и в новой для него библиотеке и т. д. И сможет эффективно работать.
Помню, в 90-х года еще было принято среди некоторых личностей, в том числе, очень известных разработчиков, все писать самостоятельно с нуля, включая, там, какой-нибудь парсер модного тогда XML. Потому что порой стоимость поиска и обхода ошибок в чужих библиотеках и API была намного выше.
Сейчас такой подход тоже популярен. Только дело не в стоимости поиска чужих ошибок, а, зачастую, в криворукости. Хотя да, в ряде случаев проще самому написать парсер xml. Особенно, если не используется ни валидация, ни трансформация, ни еще какие-то новомодные штуки. Дело еще и в том, что ради какой-нибудь минорной функции тащить в проект целый фреймворк — это тоже не комильфо. Ну и плюс не все фреймворки одинаково полезны.
Nomad1
09.09.2016 20:45+2Жалко, что автор не упомянул, как MS беспардонно выдавливает OpenGL последние годы со своих систем — ограниченные или вообще отсутствующие драйвера по-умолчанию, существенно заниженная производительность и т.д. Буквально, кросс-платформенный продукт может быть напиан с OpenGL + OpenAL для всех платформ, но на Windows 10 и Windows Phone разумно написать альтернативный рендерер или использовать Angle.
Alex_ME
09.09.2016 21:12И это очень печально для меня, как пользователя Windows
arthi7471
10.09.2016 17:01-2Не отчаивайтесь. На линухе от ещё квест с драверами. Правда если асилите невидия может выдать удивительные результаты.
RussianNeuroMancer
11.09.2016 19:09+2А какой квест, позвольте поинтересоваться? Невидия ставится кликом в области уведомлений и двумя кликами в появившемся окне (по крайней мере в Kubuntu так) а два других вендора работают из коробки, потому что у Intel и AMD открытые спеки на железо и свободные драйвера.
dartraiden
09.09.2016 22:20При разработке новых игр уже имеет смысл смотреть на Vulkan, а не на OpenGL, поскольку Vulkan на современных видеокартах быстрее. Да и большую свободу разработчикам даёт.
iOrange
09.09.2016 23:33+2Смотря каких игр. Если уровня ААА — то да, возможно стоит смотреть на Vulkan.
Иначе просто нет смысла — современного OpenGL хватает за глаза.
HerrDirektor
10.09.2016 13:58В четвертом думе вулкан быстрее, чем OGL. Причем, не только на тестах, это заметно невооруженным взглядом. Хотя железка древняя (AMDшный рефренс R9 270).
А больше я его нигде и не видел, вулкан этот. Хотя я не игрок, поэтому наверное сей факт неудивителен :)RussianNeuroMancer
11.09.2016 19:14В idTech 6 VK-рендер на одном уровне с OGL4.5-ррендером (вероятнее всего потому что разработчики использовали AZDO в OGL4.5-рендере) и они оба обгоняют OGL4.3-рендер. Фокус в том, что на Radeon Software idTech 6 позволяет заюзать либо Vulkan, либо OpenGL 4.3.
То есть все могли бы жить-поживать и добра наживать с OpenGL 4.5 и AZDO, но необходимость в замене OpenGL да и ребрендинге таки назрела — потому и имеем Vulkan.
barnes
12.09.2016 04:59+1Прирост заметный именно на амд картах. На нвидии он совсем не большой. Причина я думаю в том, что гл драйвар у ати-амд всегда был хуже нвидевского. Это не считая кучи глюков с которыми мне пришлось лет за 10 кодинга столкнуться…
HerrDirektor
12.09.2016 05:44Так камрад выше разъяснил, почему так — на радеонах используется OGL4.3, на нвидии — OGL4.5, поэтому в последнем случае разница между VK и OGL минимальна.
Ну а глюки радеонов — это да. Даже как пользователь, отмечу, что более глючные драйверы были пожалуй только у каких-нибудь там Savage или Permedia.barnes
12.09.2016 10:30Это немного не совсем так.
AZDO реализуется спокойно на 4,3 железе.
buffer storage — 4.3
multidraw inderect — 4.1
bindless textures — 4.0
texture arrays — вообще на гл3 доступны
Я не копал вулкан, тк не интересно, но гляде примеры это очень похоже на гл45 с низкоуровневым доступом.RussianNeuroMancer
12.09.2016 17:13Это вы верно подметили, тогда может дело в том что у AMD реализация чаще по спецификации, чем у nVidia? (Больше проверок в коде драйвера.)
barnes
12.09.2016 17:30AMD реально маниакально придерживается спецификаций. Но когда приходилось развертывать циклы, тк на амд шейдер без проблем компилировался, но рисовал чОрный экран, это вообще как? А развернешь все работает… Это при том, что шейдер совсем простой… А когда на 5ххх серии выборочно не пахал оклюжен квери и кондишенл рендер? Мы тогда этого Абрашу Селлера просто баг репортами задолбали.
RussianNeuroMancer
12.09.2016 17:41Для любого вендора можно составить список эпичных провалов, суть не в этом, а в том что вряд ли тормознутость OGL4.3-рендера DOOM на Radeon Software связана с ними — рендеринг же корректный. Скорее с проверками, как мне кажется. Абрашу закидывать багрепортами нужно и полезно, чтобы он активнее подпинывал китайцев :)
barnes
12.09.2016 17:46Возможно)) Но самый лютый треш, это были опенгл драйвера интела ))
HerrDirektor
12.09.2016 19:16[задумывается] С точки зрения пользователя самым трешем были драйверы под Savage 4.
Хочешь поиграть в HL? — пуск батника с установкой одного пакета драйверов->рестарт->играем.
Хочешь в Q2? Мммм… нужно ставить другую версию, т.к. в текущей на Q2 выпадают текстуры. А на версии, где Q2 идет без глюков, HL превращается в белесое слайд-шоу.
А уж бох-ты-мой, ежели вдруг приспичило запустить что-то под DX — то там сразу 3 версии, под разные игрухи своя, иначе тормозит.
Первая TNT казалась божеством стабильности после S4 :) Хотя по скорости кое-где уступала.barnes
13.09.2016 00:10Первая ТНТ?) О да) Была у друга, я позже взял рейдж128 атишную. Билинейка была жуткая просто… А трилинейка ок. И 16бит цвет жуткий был. 32 уже ок. Как щас помню 42фпс на 1024 в ку2 (тирлинейкаи 24бита колор))) Ати еще конкретно подсиживали тем, что до 128й у них не было альфа блендинга… Что д3д, что гл
yurser
10.09.2016 17:01+1А что насчет DX12 против Vulkan? Что лучше?
creker
11.09.2016 03:07Они практически идентичны. Но тут опять возникает вопрос, что даст больший профит. DX12 — это windows и xbox. Вулкан — это только windows. Довольно мало смысла, если выбросить из головы идеологические принципы. В перспективе, DX12 однозначно получит намного лучшую поддержку драйверами. Пока что конечно и там, и там наблюдаются проблемы молодости.
vorphalack
11.09.2016 08:50если верить вики, то вулкан еще и линух, и андроид новых версий. но да, грустно. хотя хрен его знает кто в новой нинтенде будет.
RussianNeuroMancer
11.09.2016 19:25+1Direct3D 12 даёт разработчику доступ к Windows 10, Windows 10 Mobile и Xbox One,
Vulkan даёт разработчику доступ к Windows 7, 8.1, 10, GNU/Linux, Android и через MoltenVK — к MacOS и iOS.
То есть даже при разработке эксклюзивно для десктопной Windows разработчик получит доступ к большей аудитории выбрав Vulkan.yurser
11.09.2016 20:38Про доступность понятно. Интересен именно технический аспект.
RussianNeuroMancer
11.09.2016 21:29Насколько я понимаю технический аспект — если код пишите лично вы, значит вам придётся в движке писать некоторую немалую часть того, что раньше на себя брал видеодрайвер, вне зависимости от того, какой API выберите. Если вы настолько хорошо разбираетесь в работе видеокарт, чтобы решать эту задачу самостоятельно, то вы уже знаете что выбрать. Ну а если не разбираетесь — тогда OpenGL или готовый движок с поддержкой нужных платформ.
MarazmDed
14.09.2016 18:13если код пишите лично вы, значит вам придётся в движке писать некоторую немалую часть того, что раньше на себя брал видеодрайвер, вне зависимости от того, какой API выберите.
На мой взгляд в вашей фразе следующие проблемы:
1) В ДВИЖКЕ — это крест. Работу с API нужно выносить в отдельный слой. Тогда движок получится универсальным и кроссплатформенным. Особенно актуально, если посещают мысли об охвате нескольких платформ.
2) Делать то, что брал на себя видеодрайвер не нужно по определению. Задача драйвера — работа с оборудованием. Это слой абстракции. То, ради чего драйверы и были придуманы.
3) API берет на себя низкоуровневые функции. Ради этого он и нужен. Так что, будь то OpenGL, DirectX или любая другая библиотека — разбираться в архитектуре и особенностях работы с видеокартой не придется.RussianNeuroMancer
14.09.2016 19:021) Согласен, просто назвал общим словом, не вдаваясь в детали.
2) Местами таки нужно — например, поддержку нескольких GPU придётся писать самим, драйвер тут не поможет.
3) В случае Vulkan и D3D12 какие-то функции берёт, а какие-то брать перестал, вот о чём речь. И сравнение с OpenGL и Direct3D до 11 включительно на мой взгляд некорректно — например сравните SLOC helloworld-ов на Vulkan и OpenGL.MarazmDed
14.09.2016 21:582) Местами таки нужно — например, поддержку нескольких GPU придётся писать самим, драйвер тут не поможет.
Что подразумевается под поддержкой нескольких GPU? CrossFire и иже с ними?
И сравнение с OpenGL и Direct3D до 11 включительно на мой взгляд некорректно
Я изначально об этом говорилRussianNeuroMancer
14.09.2016 22:122) Да, SLI или CrossFire, но помнится что возможен и более творческий подход в асимметричных конфигурациях, где слабому GPU отводиться какая-то отдельная роль, например заниматься только сглаживанием. На практике мы однако наблюдаем, что разработчики игр пока боятся браться даже за симметричные конфигурации, хотя казалось бы — вот она, возможность сделать идеальный multi-GPU без всех этих хаков со стороны драйвера и рендера. Но не делают, и тут обиднее всего за обладателей видеокарт с двумя чипами на одной плате, хотя их и мало.
3) То есть вы согласны с тем что в случае OpenGL и D3D11 драйвер берёт на себя многие задачи, а в случае с Vulkan и D3D12 разработчику придётся решать эти задачи своими ручками, которые для задействования потенциала новых API, притом должны быть весьма очумелыми?MarazmDed
14.09.2016 22:15То есть вы согласны с тем что в случае OpenGL и D3D11 драйвер берёт на себя многие задачи, а в случае с Vulkan и D3D12 разработчику придётся решать эти задачи своими ручками, которые для задействования потенциала новых API, притом должны быть весьма очумелыми?
В случае с Vulcan и D3D12 я не в теме, потому спорить не компетентен. Но изначально фраза заставила словить жесткий спотыкач мозгов.
creker
10.09.2016 05:06Не может быть, потому что с OpenGL столько проблем, что игроки воют с каждым релизом игр на нем, тем более что он не покрывает ниодну из консолей. Намного лучший вариант это основной рендер на DX и на том, что у playstation. Если надо порты, то кое как переносить на OpenGL. Таким образом сделаны все топовые движки. Основной рендер это DX. Исключение лишь IDTech, который все равно толком нигде не используется и не сильно интересен сам по себе.
MarazmDed
10.09.2016 13:19+1Подозреваю, что во всех ТОПОВЫХ движках есть слой абстракции. Так что переключение под другой рендер — вопрос далеко не самый сложный. Это, кстати, и объясняет, почему в настройках кучи игр есть выбор между православным DirectX и вражеским OpenGL.
creker
11.09.2016 03:02+1Кучи игр? Это каких же. Возьмем вот frostbite. На данный момент лучшее, что есть на рынке в плане оснащения. Но к сожалению in-house. Он вообще не имеет версии под opengl. На нем выходят все игры EA.
А на счет слоя абстракции. Да, он есть. Но не думаете же вы, что это так просто, как подменить макросами одни функции на другие? Они похожи, но все равно имеют свои различия. И DX очевидно уделяется намного больше внимания. Он покрывает Windows и Xbox, поэтому это не удивительно. Для playstation есть своя библиотека. В итоге OpenGL не осталось места, и он попросту не нужен в современном геймдеве. Есть какие-то надежды только у вулкана. Да, люди любят приводить в пример IDTech и еще редкие редкие примеры, но они не меняют картины. Объективно, нет никаких причин использовать OpenGL. Он все равно не даст необходимой кроссплатформенности, а на единственной Windows принесет лишь проблемы с драйверами.MarazmDed
13.09.2016 13:14Но не думаете же вы, что это так просто, как подменить макросами одни функции на другие? Они похожи, но все равно имеют свои различия.
Цель слоя абстракции подняться на уровень чуток повыше. Т.е. будет два разных слоя для работы с графическими фреймворками, а вот движок и игровая механика — останутся независимыми от API. Нет, это не просто подменить макросами. Это именно написание двух и более (сколько требуется) промежуточных слоев, которые с одной стороны покрывают потребности движка, с другой стороны работают с API. Результаты такой работы я видел. Игры под PS, XBOX и винду. Порт занимает относительно немного затрат времени.
В итоге OpenGL не осталось места, и он попросту не нужен в современном геймдеве.
О чем я и говорил. Для каждой задачи — свой инструмент. Для написания своей сапрообразной проги я, например, использовал OpenGL — и мне пофиг на наличие акселератора и аппаратного ускорения — цели другие. OpenGL для несложной работы с графикой показался проще, чем Direct3D.
Mairon
11.09.2016 12:37У Xbox тоже свой API графический, а не D3D. DX12 базируется на API Xbox One, но не идентичен ему.
RussianNeuroMancer
11.09.2016 19:39Сколько проблем с DOOM? Неужели больше, чем с последним Бэтменом? Если рассуждать так же, как рассуждаете вы — можно брать глюки, которые есть у каждой выходящей игры и заявлять, что все беды от Direct3D.
Утверждение об отсутствии покрытия консолей ложно — есть Steam Machine. Вы конечно же сейчас станете возражать в духе «нищитова» но данное ложное утверждение от этого не перестанет быть ложным.
А теперь, давайте вместе подумаем, зачем в Unreal Engine, Unity Engine и CryEngine добавили поддержку OpenGL, если он такой плохой? И как в idTech 6 из OpenGL 4.5 выжали столько же кадров в секунду, сколько из Vulkan?
Alexsandr_SE
09.09.2016 21:06+1Помню в 95 винде игра работала приемлемо. Но стоило поставить обновление с ИЕ и OpenGL в комплекте, как сокрость DX игры падала катастрофически. Если с чистой виндой хватало 486DX2, то с обновлением понадобился уже пентиум. Откуда такое взялось для меня загадка.
3draven
09.09.2016 22:57+1С дуба рухнуть, сравнивать работающий почти на голых микроконтроллерах, открытый стандарт, занимающий 90% рынка если взять и смартфоны, и прочее с закрытым набором либ, прибитым гвоздями к одной ОС. Какое противостояние то? В игрушках.
13_beta2
09.09.2016 23:33+3Сколько рынка эти игрушки занимают в деньгах против всего остального? Для интереса.
iOrange
09.09.2016 23:35+2Мобильные игрушки тоже немало денег приносят, уж поверьте мне.
Ну и не забываем про консоли — на тех же плойках хоть и порезанный, но все же OpenGL.13_beta2
10.09.2016 00:52Так я не утверждаю обратного. Реально интересно сравнить долю pc+xbox относительно остального. Если есть такие оценки, конечно.
dendron
10.09.2016 02:40+1Никто всерьез не программирует на PS на OpenGL, насколько я знаю. Там как раз никакие абстракции не нужны.
creker
10.09.2016 05:03+1Его никто не использует и есть он там чисто для галочки как враппер вокруг нормальной проприетарной библиотеки. Пора уже заканчивать пытаться воскресить OpenGL этим аргументом. В играх, которые имеют значение, т.е. не мобильные, DX доминирует и никуда деваться не собирается.
creker
10.09.2016 05:02Ага, в основном секторе применения этих библиотек. И так уж получилось, что DX там занимает практически весь рынок
Nagg
10.09.2016 11:45+3Какой нынче ад для хардкорных (не путать с редактор-обезьянами) геймедевелоперов, каждый тянет свой API: MS — DX, Apple — Metal, остальные — вулкан (ну и старенький OpenGLES для мобилок). Это же надо писать игровые движки с костылями под каждую платформу :( Вот вроде Вулкан так хорош, но почему эпл его не продвигает? На сайте вулкана нет информации о поддержки оного яблочных платформ — какой же он тогда кроссплатформенный?
Mairon
11.09.2016 13:03+1Разговаривал с некоторыми геймдевами, они, наоборот, рады, мол, лучше 10 хороших API под разные платформы, чем 1 плохое под все платформы.
Nagg
11.09.2016 13:32Что хорошео в том, что надо делать абстракцию между разными апи = получать некоторый оверхед из-за разности подходов.
Mairon
11.09.2016 14:25+1Я не оспариваю, что Apple вообще фигней страдает. По поводу Metal был сначала энтузиазм, но он поутих, потому что Vulkan оказался пусть и сложнее, но не хуже по итоговому выхлопу, и в играх Vulkan используется прямо сейчас, в отличие от Metal, который кроме как в бенчмарках, технодемках и некоторых мобильных играх не первого эшелона нигде не используется.
Ну и к OpenGL благожелательность повысилась, так как последние версии API стали удобноваримыми, конформанс-тесты стали строже, и драйверы ведут себя всё более предсказуемо. Поэтому Apple со своим GLES 3.0 и GL 4.0 выглядит совсем странно. Так что Apple тут начинает создавать разработчикам уже больше проблем, чем OpenGL. Даже известный фанат Metal Пранчкевичус из Unity перестал оспаривать нелепость решения Apple не развивать свою реализацию GL+ES и не пускать Vulkan.
Alexey2005
10.09.2016 12:44-1Похоже, что аналогичная история сейчас разворачивается вокруг веб-технологий: W3C — это полный аналог ARB, тоже всё делают не вовремя и костыльно.
Многие разработчики уже с нетерпением ждут, когда же в мире останется всего один браузерный движок, чтобы его владелец наконец получил возможность послать W3C куда подальше и сделать всё по уму, а главное — быстро.
TsukinoMai
10.09.2016 12:58+6Многие разработчики уже с нетерпением ждут, когда же в мире останется всего один браузерный движок
А остальные всё ещё помнят что из этого вышло в прошлый раз.
Error1024
10.09.2016 18:37+1К сожалению посредством Chrome/blink это уже происходит.
Сначала Opera начала поддерживать хромовые префиксы — умерла.
Теперь FF тоже начинает поддерживать их и прикидываться хромом… Если посмотреть на графики, то видно что к сожалению его ожидает таже судьба что и мою любимую оперу.
А в руках гугла веб уже превращаться в тормозящую анимацию с material design, попутно выжирающую всю оперативную память.
sumanai
10.09.2016 14:26+1> Многие разработчики уже с нетерпением ждут, когда же в мире останется всего один браузерный движок
Покажите мне их. они хотя бы с вебом связаны?
Nekit1234007
10.09.2016 17:02https://habrahabr.ru/post/123194/
Nekit1234007
10.09.2016 18:09+1(Когда этот коментарий был написан, у статьи было 0 коментариев. Страдание ro акков…)
en1gma
10.09.2016 19:41и, вроде как, vulcan очередная пробежка по граблям: попытка стандартизировать проприетарный mantle от amd
vorphalack
11.09.2016 08:55даже если так, то на моем старичке 660Ti 4й дум вполне бодрячком вулканизировался на средних настройках.
nett00n
12.09.2016 18:34Не знаю почему, но манера подачи материала напомнила мне почти такую же эпичную историю про фатальный недостаток.
GamePad64
Хороший перевод! Хоть я и не писал графические приложения, было очень интересно читать.
Вопрос к знатокам: У ARB был шанс реабилитироваться с выходом OpenGL ES 2.0 и OpenGL 4.0. Получилось или не очень?