Вредоносное ПО (malware) - это назойливые или опасные программы,...
Эх, было бы все так просто с OpenGL. Сейчас так или иначе cуществуют используются 6 малосовместимых стандартов (2.1,3.3,4.х, ES 1.0, ES 2.0, ES 3.0), у которых отличаются языки шейдеров, частично (а иногда почти полностью) разные API. Хуже того, нет референсной реализации и очень мало контроля качества. В итоге на большей части PC рынка (Intel и AMD) OpenGL реализован криво, а на мобильниках, помимо часто кривых драйверов (для Adreno (ex-ATI, че тут хотеть), очень сильно различаются подходы к оптимизации
DiDi
Михаил вы немного не правы. Выбирать DirectX нужно только в одном единственном случае. Если вы хотите ограничить свою аудиторию не только платформой виндоус но и одной версией винды и точным совпадением по производителям и сериям копмлеткующих компа с использованым для разработки. И хотя никто не будет спорить что написанное с использванием директа будет работать и на других комплектующих и даже некоторых версиях винды, всё же при любом несовпадении картинка будет отличаться в худшую сторону так же как и производительность. Во всех остальных случаях если разработчик хочет донести своё творение в том виде как он это делал нужно просто обязательно выбирать OpenGL.
crsib
DiDi, вот странные вещи ты говоришь. Во-первых, D3D9 есть везде начиная с XP, и, сюрприз-сюрприз, на XBox и некоторых Windows Mobile телефонах. D3D11 есть на всех PC c Vista+, WinRT, WP8. Видимо будет в следующем поколении XBox.
OpenGL на PC работает экстремально плохо. Шансов, что все будет работать на AMD мало. Про Intel я вообще промолчу. У пользователя, особенно на хрюшке может не стоять драйверов, что обеспечит ему клевый софтварный рендер и поддержку аж API 1.1. При этом есть отличный шанс на то, что D3D игра будет работать великолепно.
DiDi
crsib , надеюсь у вас есть свои игровые проекты.. мне достаточно того что я насмотрелся сколько кода пишут что бы картинка просто была везде где есть этот D3D9, я не буду спорить что большая часть программистов использующих DirectX не ленивые люди в отличие от предпочитающих OpenGL но это не дает добавляет достоинства самому DirectX. В конце концов лично для меня мерилом явлются затраты разработчиков а в случае с директом они несоизмеримо больше с куда меньшим полезным выхлопом в итоге.
crsib
У меня-то как раз есть. Причем на OpenGL ES. Про трудозатраты вообще не понял шутки. Следить за состоянием конвеера на OpenGL та еще пытка, потому что значительная часть его инкапсулирована почему-то в графические "примитивы". Держать код перносимым это вообще жесть. У ES 1 вообще нет требований к форматам аппаратного сжатия текстур, у ES 2.0 есть убогий ETC. В итоге на тот же андроид приходится собирать пачку билдов с текстурами в разных форматах. Я уже не говорю про то, что у PowerVR и Mali и у Adreno местами прямо противолопожные подходы к оптимизации на уровне OpenGL (при его подходе к абстракции "железа"). Про PC я даже говорить не хочу. Из-за того, что приходится работать OpenGL в моих компьтерах всегда будет ускоритель от nVidia. У меня тупо нет выбора. Я могу почти гарантировать, что написаный в соответсвие со стандартом код на Intel GMA/HD работать тупо не будет, даже если я 10 драйверов поставлю. Ну или будет работать так, что лучше бы честно не заработал. Почти таже история с ATI/AMD, ситуация лишь не многим лучше.
В общем твои коментарии звучат в духе начинающего разработчика, который еще просто не успел пройти все круги ада продакшен разработки на OpenGL
По всей видимости, очень многие пользователи, в частности, все те, кто предпочитает использовать компьютер для установки и прохождения современных ресурсоемких игр, знают, что в настройках графики можно использовать специальные средства ускорения вывода изображения и повышения качества картинки OpenGL или DirectX. Что лучше задействовать для полного использования всех скрытых ресурсов компьютерной системы и добиться максимальной производительности? Вопрос этот является достаточно спорным, и ответить однозначно в пользу какой-то одной платформы обычно не представляется возможным, поскольку все зависит от конкретной цели, которую ставит перед собой пользователь или разработчик, а также от каждой конкретной ситуации, которая частично может быть связана с «железным» оборудованием в виде графического ускорителя, его программной поддержкой в виде драйверов и некоторыми дополнительными аспектами. Попробуем разобраться, что лучше — OpenGL или DirectX, — обратившись и к официальным источникам информации, и опираясь на мнения пользователей и разработчиков программного обеспечения, которое может требовать поддержку таких технологий.
Что такое OpenGL и DirectX?
Начнем с того, что среди рядовых пользователей бытует ошибочное мнение, что эти два описываемых компонента представляют собой графические движки. Отсюда и возникают некорректные вопросы по поводу того, какой движок лучше — OpenGL или DirectX?
Дело в том, что к движкам этим платформы относятся лишь частично, поскольку являются исключительно программным обеспечением, которое позволяет взаимодействовать программному движку программы (игры) с установленным оборудованием (чаще всего с видео- и звуковым картами) через их драйверы, которые выполняют роль посредников. На самом же деле OpenGL и DirectX являются частью интерфейсов прикладного программирования с необходимым наборами библиотек, классов, дефиниций, структур, констант и функций, применяемых для обеспечения работы с внешними программными продуктами, устанавливаемыми в операционную систему.
Для чего используются эти технологии
Естественно, очень часто можно встретить и вопросы по поводу того, какая графика лучше — OpenGL или DirectX? Такая постановка тоже частично является некорректной, поскольку речь может идти не только о задействовании ресурсов видеокарт, но и звуковых или любых других «железных» и виртуальных устройств мультимедиа. Но чаще всего речь действительно идет именно о графических ускорителях. При этом нужно четко понимать, что выбор в пользу того или иного «моста», обеспечивающего взаимодействие видеокарты с установленной игрой или любой другой программой, где это необходимо, может зависеть и от того, насколько обязательной является такая поддержка.
В современных играх со сложными текстурами и досконально пририсованными динамическими сценами такая поддержка крайне необходима. Но проблема в том, что далеко не все графические ускорители могут корректно использовать такую поддержку. В этом случае все зависит уже от драйверов. Будь карта какой угодно ультрамодной, но с устаревшим управляющим ПО (драйверами) она не сможет использовать все те возможности, которые изначально были заявлены производителем. Тем не менее в большинстве игр или в программах для работы с мультимедиа (например, для обработки видео) очень часто и приходится выбирать, какую именно поддержку устанавливать в настройках противопоставляя одну платформу другой (в английском варианте это обычно выглядит как «OpenGL vs DirectX»).
Основные отличия DirectX и OpenGL
Что же касается основных отличий, не вдаваясь в технические аспекты функционирования, сразу же можно отметить, что платформа DirectX, являющая эксклюзивной разработкой корпорации Microsoft, предназначена исключительно для применения в Windows-системах и частично на Xbox, а OpenGL представляет свободно распространяемую кроссплатформенную технологию, применимую в других ОС (даже в мобильных). Лицензия GNU позволяет любому желающему вносить в компоненты этого API собственные изменения и дополнения, касающиеся ее усовершенствования с целью повышения производительности тех же видеокарт, в то время как улучшений DirectX приходится ждать только по мере выхода новых версий платформы. При этом даже с самыми новыми драйверами при использовании на старых версиях моста графические ускорители не выдают заявленных производителем показателей.
Главные преимущества и недостатки
Говоря о том, что лучше — OpenGL или DirectX 11 (12), отдельно стоит отметить, что первая платформа предназначена только для графики, а вторая может использоваться вообще для всего того, что относится к мультимедиа (за графику в данном случае отвечает компонент Direct3D).
Кроме того, многим экспертами отмечается, что в очень высокой степени выбор в пользу того или иного моста может зависеть и от типа графической карты. Но, если подходить к сравнению непредвзято, считается, что в плане охвата платформ лучше выглядит OpenGL, но DirectX выигрывает в плане того, что является готовым программным продуктом вроде класса Plug&Play. Однако не стоит забывать и том, что инструментальный набор DirectX последних версий и так доступен в OpenGL, а вот обратной поддержки нет.
OpenGL или DirectX: что лучше для игр?
Что же касается игр, и тут однозначного ответа дать нельзя. Так, например, довольно часто можно встретить комментарии по поводу того, что графические чипы линейки Radeon 9800 лучшие результаты в тестах показывают на основе DirectX, а карты GeForce серии 5XXX - при использовании OpenGL. Зато у DirectX есть еще одно неоспоримое преимущество.
Поскольку мост OpenGL изначально создавался для других платформ, с ним в Windows возможно появление разного рода багов, а вот DirectX позволяет довольно сносно пользоваться играми даже на относительно устаревших компьютерах без всяких торможений (яркий пример тому - игра Age Of Empires).
Бывает и наоборот. Так, например, некоторые пользователи отмечают, что DOOM 3 на картах серии Radeon X1XXX с использованием OpenGL просто «летает», а Half-Life 2 очень часто «тормозит». Но тут, видимо, все зависит еще и от драйверов.
Но, по большому счету, если игра поддерживает использование обеих технологий, лучше всего посмотреть, каким будет результат работы видеокарты при использовании каждого режима попеременно. Само собой разумеется, что достижения оптимальной производительности и сами платформы, и драйверы графических ускорителей должны быть обновлены до самых последних версий.
Что лучше для BlueStacks: DirectX или OpenGL?
Достаточно часто можно встретить и вопросы по поводу использования одного из самых популярных эмуляторов Android-систем под названием BlueStacks. Какую платформу предпочесть в BlueStacks — OpenGL или DirectX? Увы, и тут однозначного ответа дать нельзя.
Однако негласно считается, что в случае установки через этот эмулятор именно игр, лучше задействовать OpenGL, а вот, если игра будет тормозить, тогда придется переключиться на DirectX. Но, опять же, все это касается только игровой графики. В случае с профессиональной обработкой и рендерингом видео придется достаточно серьезно экспериментировать.
Наконец, если говорить о том, что лучше — OpenGL или DirectX - для разработчика, который только начинает освоение этих технологий и делает первые шаги, большинство специалистов в этой области отмечают, что сначала лучше ознакомиться с принципами функционирования и инструментальным набором DirectX, поскольку эта платформа выглядит для новичка более простой, и для нее постоянно выпускаются неплохие комплекты SDK, предназначенные как раз для упрощения адаптации программных продуктов к «железу», а только потом переходить к изучению OpenGL.
Впрочем, многое может зависеть и от того, какую конечную цель вы перед собой ставите и какой именно функционал каждой платформы будет использоваться в каждом конкретном случае (только графика, только звук или какие-то объединенные решения).
Краткие выводы
Подводя итоги, как уже понятно, однозначного вывода в пользу одного или другого компонента сделать достаточно сложно. Между этими платформами идет постоянное соревнование. Иногда новая версия DirectX по своим параметрам опережает OpenGL, но по мере устаревания, а также внесения в OpenGL каких-то инноваций начинает проигрывать. В целом же при выборе следует отталкиваться исключительно от общеизвестного принципа, что истина познается в сравнении. Пробуйте и то и другое! Только после получения конкретных результатов и для каждого конкретного случая и будет ясно, к какой чаше весов склонится ваш выбор.
Очень часто встречаются различные заблуждения по поводу этих двух API .
Я попытался изложить в этой статье основные факты, которые следует знать как разработчикам, так и конечным пользователям.
Так как тема очень холиварная, я старался придерживаться максимально нейтрального тона.
Взгляд с высоты птичьего полёта
Оба API предоставляют доступ к функциям аппаратного ускорения 3D-графики.Распространённые заблуждения
OpenGL отстаёт от Direct3D, и вообще, судя по таким вялым изменениям в спецификации, наверное уже совсем мёртв.Собственно, причина такого заблуждения - это незнание о расширениях. Вообще говоря, OpenGL может и часто опережает (!) Direct3D в плане инноваций, т.к. производитель может добавить расширение к OpenGL, не дожидаясь никого, в то время как в Direct3D изменения может внести только Microsoft.
OpenGL - это для программ профессиональной графики, а Direct3D - это для игр.
Это заблуждение имеет историческую причину. OpenGL исходно разрабатывался как библиотека 3D графики, которая МОЖЕТ, но НЕ ОБЯЗАНА ускоряться аппаратно. Это также объясняет наличие некоторых функций, например рендеринг стерео-изображений, которые не нужны играм. Direct3D же разрабатывался гораздо позже, сразу с расчётом на ускорение на GPU. В момент появления многих пакетов профессиональной работы с графикой Direct3D просто не было.
Microsoft поставляет вместе с Windows драйверы без поддержки OpenGL. OpenGL будет рендерить без ускорения, или эмулироваться через DirectX. Так что, если нужна поддержка OpenGL под Windows, нужно ставить драйвер с сайта производителя. Причины для такого неприятия OpenGL, скорее всего, опять чисто политические.
Так что же делать, как жить?
Примечание: А вот эта часть носит весьма субъективный характер.Если Вы - разработчик, и решаете, какое API использовать, то задумайтесь над следующим:
За OpenGL - массовая кроссплатформенность, в частности, доступность всех новых функций и на Windows XP, где Direct3D 10/11 нет, и никогда не будет.
Против OpenGL - драйвера в Windows из коробки не имеют поддержки OpenGL, так что ставить их нужно с сайта производителя.
Если Вы - новичок в разработке 3D-приложений, и желаете освоить эту область, то я бы рекомендовал сделать так: сначала разобраться с Direct3D (причина тому проста - Microsoft предоставляет очень качественный SDK), а затем разобраться с OpenGL (это будет очень просто после Direct3D). К сожалению, такой вещи, как SDK, для OpenGL нет. Поэтому осваивать с нуля будет сложнее.
Вот вроде и всё. Успехов в разработке!
Всем привет. В этой статье (сразу говорю, что статья не для новичков) будет проведено сравнение двух интерфейсов, используемых для разработки графики. Они часто находят применение в компьютерных играх. Это OpenGL и DirectX . Статья раскроет их особенности, архитектуру и производительность. Сначала приступим к обзору OpenGL.
Заметная особенность библиотеки OpenGL – простота ее работы. У данной библиотеки есть ядро, которое управляет обработкой неких треугольников (их называют примитивами).
Процедурная модель лежит в основе передачи данных, а в работе вызываются функции. OpenGL имеет состояние, связанное со значениями переменных, которые и указывают какие параметры обработки должны работать в каждый момент времени. Например, определяется, нужно ли сейчас рисовать текстуру или нет. И в соответствии с текущим состоянием совершается обработка переданных примитивов. В итоге получается простой код и достаточно эффективный механизм работы OpenGL. Также не случаются проблемы с объектно-ориентированными технологиями, несмотря на то, что ядро OpenGL является процедурным.
Пришло время рассмотреть принципы работы второго интерфейса - DirectX . В корне он сильно отличается от OpenGL и имеет основу на модели COM. Многим знакомым с этой структурой станет понятно. А если кто не знаком с принципами COM, то нужно отметить пару моментов. Модель COM предполагает не простые вызовы функций, а определенные действия, которые связаны непосредственно с архитектурой библиотеки DirectX.
Рассмотрим плюсы и минусы данной архитектуры. Вызовы DirectX используются внутри кода, который не отличается легким пониманием. И причем, для того, чтобы нарисовать обычный треугольник, используется очень большой объем кода. Для упрощения работы с таким кодом компания Microsoft разработала DirectX Common Files. Это отдельная библиотека, позволяющая, частично скрыть повторяющиеся куски кода.
OpenGL и DirectX сильно отличаются своей архитектурой и принципами работы. Позже в развитие этих двух разработок стали заметны некоторые сближения. Это связано с движением в сторону эффективного использования «железа» и уменьшением времени на преобразование пользовательских команд в аппаратные. Всегда в работе таких вещей как OpenGL и DirectX, одним из главных вопросов является вопрос производительности. Хотя этот вопрос немного запутан. Постоянно проходят споры о том, кто быстрее — OpenGL или DirectX. А в итоге получается, что скорость у этих библиотек одинакова. Так получается из-за того, что большинство функций и в DirectX и в OpenGL работают с помощью аппаратных ускорителей.
При тестировании аппаратного обеспечения степень оптимизации кода этих двух библиотек различная, вот здесь можно четче заметить разницу скоростей работы. Также производительность может находиться в зависимости от качества работы драйверов оборудования. Все эти моменты планируются заранее и у более качественный игровых движков есть версии и для OpenGL и для DirectX. В итоге разработка усложняется и стоимость игр увеличивается, а ошибок может быть больше. Игровой рынок работает именно так.
Теперь рассмотрим какие еще различия существуют между OpenGL и DirectX. Разница замечается прежде всего в удобстве работы интерфейса, гибкости его функций, области его использования. Часто можно услышать мнение, что OpenGL, в отличии от DirectX9 не поддерживает пиксельные шейдеры. Это не так, хотя в описании OpenGL не указано о шейдерах. Скорость обработки и качество картинки не зависит от используемой библиотеки.
Изначально OpenGL планировался как библиотека, которая будет актуальна еще очень долгий срок. Но комитет, разрабатывающий данную библиотеку, ARB работает медленно и новые возможности в OpenGL появляются редко. Но с помощью специальных расширений OpenGL может вырасти из базовых механизмов, реализуя новые возможности для определенное видеокарты. Как только выходит новая видеокарта, поддерживающая конкретную полезную функцию, обычно в драйвер к видеокарте включают расширенный OpenGL с этой функцией. Для этого программистам нужно специальное разрешение и поэтому имеют место расширение, прошедшие одобрение ARB, причем их применение может быть возможным на видеоадаптерах разных производителей. Эти расширение возможно позже будут включены в новые версии OpenGL. Эта модель не очень удобна. Например, в DirectX, определенная версия либо поддерживает какую-либо конкретную функциональность, либо нет. Но чаще разработчики успевают включать все новые функции, реализованные разработчиками видеокарт. В общих чертах, в разрезе поддержки аппаратных функций OpenGL и DirectX аналогичны, разница в их поставке.
DirectX любим программистами, придерживающимися объектно-ориентированного программирования и модели COM. С помощью COM вносятся изменения в данную библиотеку без редактирования базового кода. А в OpenGL такого подхода нет, но это не такой уж сильный минус. Для написания небольшой программы на DirectX используется код, размеров в 200-800 строк, для OpenGL же для аналогичного решения достаточно 50 строк.
OpenGL очень хорошо подходит для визуализации различных результатов исследований в научных областях.
Ну и конечно же большим плюсом OpenGL можно отметить открытость стандарта. Любая организация в праве приобрести лицензию у SGI и начать разрабатывать свою версию OpenGL. DirectX же закрыт, и его разработкой может заниматься только Microsoft. Поэтому путь DirectX определяется более узким кругом специалистов.
Подводя итоги, можно отметить некоторые достоинства. DirectX подходит для профессиональных игр и их разработки, а также для Windows. В последнее время OpenGL практически не применяется в играх, для разработки их движков. Эта библиотека может найти свое место на мощных компьютерах, используемых для научных исследований, в образовательных мероприятиях и других областях, имеющие необходимость в переносе различных программ на различные платформы.
На этом пожалуй все, спасибо за внимание 🙂
Вы спросите: кто же они? Они - мёртвая компания, которую я считаю истинным убийцей 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. История упущенных возможностей, величайшей глупости, умышленного безрассудства и банальных нелепостей.
