Эх, было бы все так просто с 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, че тут хотеть), очень сильно различаются подходы к оптимизации
Михаил вы немного не правы. Выбирать DirectX нужно только в одном единственном случае. Если вы хотите ограничить свою аудиторию не только платформой виндоус но и одной версией винды и точным совпадением по производителям и сериям копмлеткующих компа с использованым для разработки. И хотя никто не будет спорить что написанное с использванием директа будет работать и на других комплектующих и даже некоторых версиях винды, всё же при любом несовпадении картинка будет отличаться в худшую сторону так же как и производительность. Во всех остальных случаях если разработчик хочет донести своё творение в том виде как он это делал нужно просто обязательно выбирать OpenGL.
DiDi, вот странные вещи ты говоришь. Во-первых, D3D9 есть везде начиная с XP, и, сюрприз-сюрприз, на XBox и некоторых Windows Mobile телефонах. D3D11 есть на всех PC c Vista+, WinRT, WP8. Видимо будет в следующем поколении XBox.
OpenGL на PC работает экстремально плохо. Шансов, что все будет работать на AMD мало. Про Intel я вообще промолчу. У пользователя, особенно на хрюшке может не стоять драйверов, что обеспечит ему клевый софтварный рендер и поддержку аж API 1.1. При этом есть отличный шанс на то, что D3D игра будет работать великолепно.
crsib , надеюсь у вас есть свои игровые проекты.. мне достаточно того что я насмотрелся сколько кода пишут что бы картинка просто была везде где есть этот D3D9, я не буду спорить что большая часть программистов использующих DirectX не ленивые люди в отличие от предпочитающих OpenGL но это не дает добавляет достоинства самому DirectX. В конце концов лично для меня мерилом явлются затраты разработчиков а в случае с директом они несоизмеримо больше с куда меньшим полезным выхлопом в итоге.
У меня-то как раз есть. Причем на 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.
Заметная особенность библиотеки 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 практически не применяется в играх, для разработки их движков. Эта библиотека может найти свое место на мощных компьютерах, используемых для научных исследований, в образовательных мероприятиях и других областях, имеющие необходимость в переносе различных программ на различные платформы.
На этом пожалуй все, спасибо за внимание 🙂
На минувшей неделе был представлен API Vulkan, о широкой поддержке которого заявили AMD и NVIDIA. Новый графический интерфейс разрабатывал Khronos Group, консорциум, основанный в 2000 году. Khronos Group отвечает за разработку и поддержку открытых стандартов в сфере мультимедийных приложений на разных платформах и устройствах. Консорциум поддерживают AMD и NVIDIA, а также многие другие компании.
На минувшей неделе была ратифицирована финальная версия 1.0 API Vulkan. AMD и NVIDIA представили соответствующие бета-драйверы. AMD заранее выпустила бета-версию Radeon Software еще 14 февраля. NVIDIA представила драйвер GeForce 356.39, который тоже ориентирован на поддержку API Vulkan.
Подход API Vulkan очень похож на API Mantle. Суть заключается в том, чтобы разработчики получили более глубокий доступ к «железу», чтобы выжать из него максимум. Такой подход позволяет максимально избежать существующих «узких мест». С другой стороны, разработчики должны точно знать, что они делают – например, при работе с памятью. Интерфейс OpenGL не так популярен, как DirectX, но позволяет выжать больше.
Интерфейс API Vulkan в версии 1.0 поддерживается под Windows 7, Windows 8.1, Windows 10, Android и Linux. Разработчики игр пока что не объявили о поддержки в конкретных играх, но здесь стоит дождаться Games Developer Conference, которая будет проводиться с 14 по 18 марта в Сан-Франциско. Из игровых движков пока есть информация о Source 2, который уже поддерживает API Vulkan. Процесс отладки облегчается поддержкой Valve, LunarG и Codeplay.
Хорошо, но какая игра или движок поддерживают API Vulkan? Игра The Talos Principle разрабатывалась компанией Croteam, которая и в прошлом была известна поддержкой многих графических API. И в последней итерации игра The Talos Principle не стала исключением – она поддерживает DirectX 9, DirectX 11, OpenGL и теперь Vulkan. Для студии разработчиков Vulkan является пробным шаром, хотя API Vulkan доступен в версии 1.0, поддержка пока находится в бета-стадии. На добавление поддержки разработчики Croteam затратили порядка трех месяцев. Но универсальный характер API позволяет вскоре представить вариант Linux.
API Vulkan теоретически совместим с несколькими платформами – но пока что тесты и сравнения можно провести только под Windows, причем здесь имеются свои ограничения. Реализация пока остается на очень раннем этапе. Путь рендеринга DirectX 11 совершенствовался многие годы, поэтому потенциала для оптимизации здесь уже нет. Здесь ситуация больше зависит от разработчиков драйверов, а именно AMD и NVIDIA. Игра The Talos Principle стала первой с поддержкой Vulkan. Поэтому пока нет возможности сделать сравнительный тест для оценки хорошей или плохой реализации поддержки.
Новые технологии первое время реализуются в примерах, подготовленных производителями. В случае DirectX 12 акцент был выставлен на Draw Calls, тот же тест 3DMark DirectX 12 опирается только на измерение производительности Draw Calls, игры DirectX 12, подобные Star Wars, тоже пытаются задействовать подобную нагрузку. Но The Talos Principle не так сильно зависит от высокой скорости Draw Call, чтобы низкоуровневый API дал большую разницу.
Поддержка API Vulkan версии 1.0 находится на ранней стадии, то же самое касается драйверов AMD и NVIDIA. Оба драйвера, по сути, относятся к бета-версиям, именно так их рассматривают производители GPU. Здесь обычно нет новых улучшений производительности или поддержки новых технологий, так что мы получаем шаг назад. Но как только определенный уровень разработки будет достигнут, драйверы обоих разработчиков GPU получат поддержку Vulkan в финальной версии. Когда это произойдет – не совсем понятно. Но пока ключевые приложения не используют Vulkan и игры с поддержкой API находятся в состоянии бета-версии, так что разработчики GPU могут спокойно дорабатывать свои драйверы.
Для тестов мы взяли нашу тестовую систему для видеокарт. Драйверы видеокарт AMD и NVIDIA мы уже описали выше. В настройках мы выставили максимальный уровень графики, но при этом протестировали и низкие разрешения вплоть до 1.280 x 720 пикселей, чтобы увеличить производительность Draw Call.
Тест The Talos Principle - 1.280 x 720 пикселей
Тест The Talos Principle - 2.560 x 1.440 пикселей
Тест The Talos Principle - 3.840 x 2.160 пикселей
Как можно видеть по результатам, API Vulkan дает существенный прирост по сравнению с OpenGL. Но до производительности DirectX 11 новый API не дотягивает. Тому есть несколько причин. С одной стороны, разработка под Vulkan находится в ранней стадии. Это касается и самого API, и драйвера, и игры The Talos Principle. По сравнению с OpenGL новый интерфейс позволяет освободить часть ресурсов и избежать «узких мест». Но DirectX много лет совершенствовался до текущего уровня. В любом случае, потенциал у API Vulkan очень хороший.
Если погрузиться в детали, то визуальных отличий между API Vulkan и DirectX 11 мы не обнаружили. Так что путь рендеринга очень хорошо адаптирован. У текущей реализации The Talos Principle видеокарты с 2 Гбайт памяти получают падение производительности, вероятно, из-за не самой эффективной работы с памятью. Как и Mantle и DirectX 12, API Vulkan может обращаться к ресурсам памяти на более глубоком уровне – сей факт можно рассматривать как преимущество, но он может стать и недостатком, если разработчики не смогут эффективно использовать память.
Несколько разочаровала ошибка в текущем драйвере NVIDIA, из-за которой после каждого теста приходилось перезагружать систему. Без перезагрузки игра «вылетала». Хотя с драйвером AMD мы не обнаруживали подобной ошибки.
Нынешняя реализация API Vulkan кажется обещающей. Пока что для игр на настольных ПК она будет не такой актуальной, поскольку рынок DirectX 11 и 12 очень велик, и по сравнению с тем же DirectX 12 затраты на реализацию могут быть слишком велики, а отдача слишком мала. Но если игры необходимо запускать на разных платформах с разными аппаратными требованиями, Vulkan может сыграть важную роль. В любом случае, следует дождаться реакции со стороны разработчиков игр, иначе мы получаем проблему курицы и яйца, из которой сложно выйти.
По всей видимости, очень многие пользователи, в частности, все те, кто предпочитает использовать компьютер для установки и прохождения современных ресурсоемких игр, знают, что в настройках графики можно использовать специальные средства ускорения вывода изображения и повышения качества картинки OpenGL или DirectX. Что лучше задействовать для полного использования всех скрытых ресурсов компьютерной системы и добиться максимальной производительности? Вопрос этот является достаточно спорным, и ответить однозначно в пользу какой-то одной платформы обычно не представляется возможным, поскольку все зависит от конкретной цели, которую ставит перед собой пользователь или разработчик, а также от каждой конкретной ситуации, которая частично может быть связана с «железным» оборудованием в виде графического ускорителя, его программной поддержкой в виде драйверов и некоторыми дополнительными аспектами. Попробуем разобраться, что лучше — OpenGL или DirectX, — обратившись и к официальным источникам информации, и опираясь на мнения пользователей и разработчиков программного обеспечения, которое может требовать поддержку таких технологий.
Начнем с того, что среди рядовых пользователей бытует ошибочное мнение, что эти два описываемых компонента представляют собой графические движки. Отсюда и возникают некорректные вопросы по поводу того, какой движок лучше — OpenGL или DirectX?
Дело в том, что к движкам этим платформы относятся лишь частично, поскольку являются исключительно программным обеспечением, которое позволяет взаимодействовать программному движку программы (игры) с установленным оборудованием (чаще всего с видео- и звуковым картами) через их драйверы, которые выполняют роль посредников. На самом же деле OpenGL и DirectX являются частью интерфейсов прикладного программирования с необходимым наборами библиотек, классов, дефиниций, структур, констант и функций, применяемых для обеспечения работы с внешними программными продуктами, устанавливаемыми в операционную систему.
Естественно, очень часто можно встретить и вопросы по поводу того, какая графика лучше — OpenGL или DirectX? Такая постановка тоже частично является некорректной, поскольку речь может идти не только о задействовании ресурсов видеокарт, но и звуковых или любых других «железных» и виртуальных устройств мультимедиа. Но чаще всего речь действительно идет именно о графических ускорителях. При этом нужно четко понимать, что выбор в пользу того или иного «моста», обеспечивающего взаимодействие видеокарты с установленной игрой или любой другой программой, где это необходимо, может зависеть и от того, насколько обязательной является такая поддержка.
В современных играх со сложными текстурами и досконально пририсованными динамическими сценами такая поддержка крайне необходима. Но проблема в том, что далеко не все графические ускорители могут корректно использовать такую поддержку. В этом случае все зависит уже от драйверов. Будь карта какой угодно ультрамодной, но с устаревшим управляющим ПО (драйверами) она не сможет использовать все те возможности, которые изначально были заявлены производителем. Тем не менее в большинстве игр или в программах для работы с мультимедиа (например, для обработки видео) очень часто и приходится выбирать, какую именно поддержку устанавливать в настройках противопоставляя одну платформу другой (в английском варианте это обычно выглядит как «OpenGL vs DirectX»).
Что же касается основных отличий, не вдаваясь в технические аспекты функционирования, сразу же можно отметить, что платформа DirectX, являющая эксклюзивной разработкой корпорации Microsoft, предназначена исключительно для применения в Windows-системах и частично на Xbox, а OpenGL представляет свободно распространяемую кроссплатформенную технологию, применимую в других ОС (даже в мобильных). Лицензия GNU позволяет любому желающему вносить в компоненты этого API собственные изменения и дополнения, касающиеся ее усовершенствования с целью повышения производительности тех же видеокарт, в то время как улучшений DirectX приходится ждать только по мере выхода новых версий платформы. При этом даже с самыми новыми драйверами при использовании на старых версиях моста графические ускорители не выдают заявленных производителем показателей.
Говоря о том, что лучше — OpenGL или DirectX 11 (12), отдельно стоит отметить, что первая платформа предназначена только для графики, а вторая может использоваться вообще для всего того, что относится к мультимедиа (за графику в данном случае отвечает компонент Direct3D).
Кроме того, многим экспертами отмечается, что в очень высокой степени выбор в пользу того или иного моста может зависеть и от типа графической карты. Но, если подходить к сравнению непредвзято, считается, что в плане охвата платформ лучше выглядит OpenGL, но DirectX выигрывает в плане того, что является готовым программным продуктом вроде класса Plug&Play. Однако не стоит забывать и том, что инструментальный набор DirectX последних версий и так доступен в OpenGL, а вот обратной поддержки нет.
Что же касается игр, и тут однозначного ответа дать нельзя. Так, например, довольно часто можно встретить комментарии по поводу того, что графические чипы линейки Radeon 9800 лучшие результаты в тестах показывают на основе DirectX, а карты GeForce серии 5XXX - при использовании OpenGL. Зато у DirectX есть еще одно неоспоримое преимущество.
Поскольку мост OpenGL изначально создавался для других платформ, с ним в Windows возможно появление разного рода багов, а вот DirectX позволяет довольно сносно пользоваться играми даже на относительно устаревших компьютерах без всяких торможений (яркий пример тому - игра Age Of Empires).
Бывает и наоборот. Так, например, некоторые пользователи отмечают, что DOOM 3 на картах серии Radeon X1XXX с использованием OpenGL просто «летает», а Half-Life 2 очень часто «тормозит». Но тут, видимо, все зависит еще и от драйверов.
Но, по большому счету, если игра поддерживает использование обеих технологий, лучше всего посмотреть, каким будет результат работы видеокарты при использовании каждого режима попеременно. Само собой разумеется, что достижения оптимальной производительности и сами платформы, и драйверы графических ускорителей должны быть обновлены до самых последних версий.
Достаточно часто можно встретить и вопросы по поводу использования одного из самых популярных эмуляторов Android-систем под названием BlueStacks. Какую платформу предпочесть в BlueStacks — OpenGL или DirectX? Увы, и тут однозначного ответа дать нельзя.
Однако негласно считается, что в случае установки через этот эмулятор именно игр, лучше задействовать OpenGL, а вот, если игра будет тормозить, тогда придется переключиться на DirectX. Но, опять же, все это касается только игровой графики. В случае с профессиональной обработкой и рендерингом видео придется достаточно серьезно экспериментировать.
Наконец, если говорить о том, что лучше — OpenGL или DirectX - для разработчика, который только начинает освоение этих технологий и делает первые шаги, большинство специалистов в этой области отмечают, что сначала лучше ознакомиться с принципами функционирования и инструментальным набором DirectX, поскольку эта платформа выглядит для новичка более простой, и для нее постоянно выпускаются неплохие комплекты SDK, предназначенные как раз для упрощения адаптации программных продуктов к «железу», а только потом переходить к изучению OpenGL.
Впрочем, многое может зависеть и от того, какую конечную цель вы перед собой ставите и какой именно функционал каждой платформы будет использоваться в каждом конкретном случае (только графика, только звук или какие-то объединенные решения).
Подводя итоги, как уже понятно, однозначного вывода в пользу одного или другого компонента сделать достаточно сложно. Между этими платформами идет постоянное соревнование. Иногда новая версия DirectX по своим параметрам опережает OpenGL, но по мере устаревания, а также внесения в OpenGL каких-то инноваций начинает проигрывать. В целом же при выборе следует отталкиваться исключительно от общеизвестного принципа, что истина познается в сравнении. Пробуйте и то и другое! Только после получения конкретных результатов и для каждого конкретного случая и будет ясно, к какой чаше весов склонится ваш выбор.
OpenGL (= Open Graphics Library) - это программный интерфейс для управления графическим процессором состоит примерно из 250 команд, зашитых в двух библиотеках oglcore и oglutilities . Разрабатывается с 1990 года компанией SGI (Silicon Graphics Inc.). Цель - создание мульти-платформенного графического интерфейса для разработчиков графических карт и программного обеспечения.
DirectX
- это общее название для коллекции из
10 Windows-библиотек (см. таблицу ниже) для низкоуровнего программирования "железа" от различных производителей. Разрабатывается компанией
Microsoft с 1994 (первое название "Games SDK") с постоянно меняющимся функционалом, разделенным на версии (текущая версия 11). Цель и главная задача - позиционировать Windows, как платформу для Multimedia. Почти для всех Graphiс-, Sound-, Radio-, Video-, TV- hardware разработаны DirectX-Драйвера.
До версии DirectX 9.0 (включительно) DirectX-библиотеки принципиально отличались от других Windows-APIs (Application Programming Interfaces). Они не гарантировали исполнение необходимых запросов
. Каждый программист должен самостоятельно контролировать - может ли, программируемое через DirectX, железо выполнить нужную операцию, и если да, то в каком объеме и форме. На практике, многие программисты доверяют
DirectX-Драйверам с надеждой на то, что Драйвер целевого железа настолько хорош, что не просто отклонит некорректные для данного железа запросы, а попытается с помощью аварийной системы их обработать корректно. (см. ниже описание HEL).
Со временем появилось несколько подходов к программированию DirectX:
1) C++ и
DirectX Software Development Kit = DXSDK
;
2)
Managed DirectX
для C# - примерно также быстр в исполнении, но проще в программировании, чем 1) и является частью DXSDK;
3)
XNA
для C# - это последователь 2) для новых Windows-PC, XBox, Windows-Phone;
4)
Windows Presentation Foundation = WPF
вместе с XAML и C# → DirectX11 упаковано в одну огромную библиотеку классов.
Managed DirectX
быстро стал популярным
, так как предлагал простой и элегантный доступ к DirectX с высокой скоростью исполнения, и в период с 2002 по 2007 стал самой популярной оболочкой для разработки PC-игр под WindowsXP.
В 2007году Microsoft объявил о развитии Managed DirectX разработав два новых DirectX-APIs:
1)
XNA
, который в отличии Managed DirectX значительно упрощал доступ к DirectX для разработок на PC- , XBox- и WindowsPhone- платформах;
2)
WPF
, с целью полной и цельной интеграции DirectX во все программные оболочки и интернет-страницы.
| Свойство | OpenGL | DirectX |
| Объектно-ориентирован | нет | да |
| Библиотеки классов | QT | Managed DX, XNA, WPF |
| Поддержка Audio/Video/Game Input Устройств | нет | да |
| Поддержка операционных систем | многие | только Windows (на PC, Xbox, Windows Phone) |
| Наличие качественных драйверов | Дорогие GPU | почти на все видео-карты |
| Качество драйверов | часто среднее или плохое | часто лучше, чем OpenGL-Драйвер |
| используется | Универы, Лабы, CAD | Игровая индустрия |
| Новые версии | каждые 5 лет (в промежутках только "Extensions") | каждые 15 месяцев |
| Собственность | Silicon Graphics Inc. | Microsoft |
OpenGL состоит из двух библиотек (DLL), которые исключительно заточены на Графику.
Microsoft под именем DirectX собрал все, что в рамках операционной системы обращается напрямую к железу. В Managed DirectX эти библиотеки организованы в форме Namespaces. Только первые четыре из этих Namesspaces занимаются Графикой.
| OpenGL lib | DirectX |
| oglcore | Microsoft.DirectX, Microsoft.DirectX.DirectDraw, Microsoft.DirectX.Direct3D |
| oglutilities | Microsoft.DirectX.Direct3DX |
| .NET Namespace | API = Application Programming Interface |
| Microsoft.DirectX | общие базовые функции |
| Microsoft.DirectX.DirectDraw | подмножество из Direct3D-lib: basic 2D functions, bitmaps, window management |
| Microsoft.DirectX.Direct3D | API for 3D graphics: wireframes, textures, light, Vertex and Pixel Shaders |
| Microsoft.DirectX.Direct3DX | 3D utilities library, Mesh class and scene graph |
| Microsoft.DirectX.DirectPlay | network support for multiplayer games, host administration for DirectPlay sessions |
| Microsoft.DirectX.DirectSound | contains DirectMusic, API for real time multichannel mixer, 3D sound |
| Microsoft.DirectX.DirectInput | API for keyboard, mouse, joystick, trackball, touchpad, gamepad, wheel, force feedback |
| Microsoft.DirectX.AudioVideoPlayback | API for simple sound and video |
| Microsoft.DirectX.Diagnostics | system diagnostics API |
| Microsoft.DirectX.Security | system security API |
Графический чип современной графической карты содержит множество графических процессоров в форме так называемых каскадных пайплайнов (Pipeline). Первая половина этих процессоров занята работой с векторной графикой, вторая с растровой графикой. Цепочки команд в OpenGL и Direct3D отражают принцип цепочек процессоров графического чипа. Следовательно набор команд OpenGL и Direct3D направлены примерно поровну на 3D-Векторную и Растровую графику. Таким образом, фундаментальное отличие между Векторной и Растровой Графикой нейтрализуется и скрывается, чтобы облегчить решение проблемы Векторно-Растрового перехода. Также скрывается проблема разделения работы между CPU и GPU, Что еще сложнее учитывая разнообразие возможных вариантов.
Таким образом, многие новички поначалу иллюзорно считают, что понимание работы "железа" не так уж необходимо.
Схема 3D-Pipeline
в OpenGL & Direct3D повторяет архитектуру GPU:
В DirectX есть возможность отключить всю Векторную часть через флаг CreateFlags.SoftwareVertexProcessing. Если в компьютере нет полноценного или вообще никакого GPU, то Pipeline будет симулироваться внутри OpenGL/DirectX, используя для всех расчётов CPU. В этом случае данные термины - Vertex Shader, T&L Engine, HSSL/Cg - не имеют никакого смысла и лучше говорить о CPU-Графике - HEL und HAL.
Vertex Shader
= каскад последовательно включенных микропроцессоров внутри GPU. Современные GPU содержат до 8 таких каскадов параллельно: программа, написанная на
HLSL
или
для Vertex Shader, также называется Vertex Shader.
Задача Vertex Shader
: преобразование 3D-треугольников (в мировых координатах) в 2D-треугольники (в экранных координатах).
Процессы в Vertex Shader
: Tesselation (триангуляция), координатная трансформация, 3D-Scroll+Zoom+Rotation, Clipping, Back Face Culling.
T&L Engine
- Transform & Light Engine - Fixed Vector Pipeline - наименование от одного до 8 параллельных Vertex Shader, которые программируются через заранее прошитые алгоритмы (Firmware), не дающиие большой свободы, но при этом значительно более быстрые. Управление этими Firmware осуществляется из вне, через:
a) флаги состояний, Пример:
device.Lights.Enabled = true;
и
b) 3x3-матрицы, Пример:
device.Transform.View = Matrix.LookAtLH(new Vector3(0f, 0f,-4f),
new Vector3(0f, 0f, 0f),
new Vector3(0f, 1f, 0f)); .
Clipping
= обрезка линий и конвексных Полигонов по границе экрана через алгоритм Коена-Сазерленда.
Back Face Culling
: примерно 50% треугольников обращены к наблюдателю тыльной стороной - если эти полигоны выбросить из рассчетов, то это ускорит растровые операции примерно в двое.
Pixel-Shader
= Rasterizer = включенный после Vertex-Shader специальный процессор графического чипа, специализирующийся на растровой графике = текстурирование и отрисовка (рендер) отдельного Пиксела, программируется через
HLSL
или , в графическом чипе содержится до 32-х параллельных Pixel-Shader.
Texture
= деформация растрового прямоугольника так, что он умещается в заданный Полигон.
BitBlitter
= сокращение от Bit Block Transfer = добавление растеризованных Шрифтов, линий, четырехугольников, эллипсов и т.д.
Z-Test
= Depth Test = Удаление скрытых Пикселей.
Alpha & Color Blending
= наложение масок прозрачности.
Fog
= добавление тумана в зависимости от расстояния между наблюдателем и объектом.
Dithering
= сглаживание цветов.
При установке Драйвера Графических карт, звуковых карт, джойстиков и т.д. определятся в операционной системе в форме Device Driver Interface DDI. С помощью определенного DDIs каждая DirectX-Библиотека при старте инициализирует один Hardware Emulation Layer HEL и один Hardware Abstraction Layer HAL. HEL содержит низкоуровневые вызовы базовых функций и кода CPU. HAL содержит внешние, автономные микро-программы для Графических, звуковых карт и т.д. HAL имеет более высокий приоритет исполнения, чем HEL, но приэтом все библиотечные вызовы выполняются, даже тогда, когда HAL мало что может. HEL-Графика, HEL-Анимация, HEL-Звук, HEL-Видео и пр., как правило медленны в исполнении, но они гарантированно исполнимы.
Производители CPU - Intel и AMD конкурируют с производителями Графических и Мультимедийных карт. Они постоянно улучшают графическую и звуковые компоненты и общую архитектуру CPU, для того чтобы усилить HEL против HAL. И делают это с большим успехом: в простых играх и мультимедиа трудно заметить разницу в производительности, и для офисных приложений достаточно обычного on-board-Videocontroller без отдельной видео-памяти (используется общая память).
| Пример: прорисовка через GDI+ или DirectDraw HEL/HAL
Существует три пути, чтобы что-то нарисовать: 1) обычный Windows-вызов без DirectX работает через GDI+ und DDI. Пример: graphics.DrawLine(mypen, 0, 0, 100, 100); 2) через DirectDraw, HEL и DDI 3) через DirectDraw и HAL Если вариант 3)
существует, то 2)
закрыт. |  |
это важнейший Direct3D-Класс, который непосредственно управляет Графической Картой. Его главная функция - Device.Present , переключать BackBuffer Графической Карты на FrontBuffer и таким образом отображать прорисованную функцию на мониторе.
Далее этот класс содержит Свойства/Функции как для Векторной Графики
(Viewport, Vertex Format, Transform) так и для Растровой Графики (Material, Texture, адресса и длины для Output-Buffer).
При старте любой программы, использующей Direct3D, создается данный класс и резервиуются ресурсы и права доступа к Графической Карте.
| Важные свойства | of Direct3D class "Device " |
| DeviceCaps | Возвращает структуру, представляющую возможности железа - используется для определения доступна ли та или иная фича для использования в текущем приложении |
| Viewport | Возвращает/Определяет прямоугольный регион для отрисовки на текущем устройстве |
| Material | Возвращает/Определяет материал для использования при прорисовке (рендере) |
| Lights | Возвращает коллекцию источников света, которые могут быть активированы при прорисовке (рендере) |
| RenderState | Возвращает колекцию состояний рендера, которые используются для контроля различных состояний Direct3D пайплайна. |
| VertexDeclaration | Возвращает/Определяет описание вертексных форматов используемых вертексным шейдером |
| VertexFormat | Возвращает/Определяет описание вертексных форматов, используемых в Fixed Vector Pipeline |
| VertexShader, PixelShader | Возвращает/Определяет the vertex/pixel shader to use for rendering |
| Важные методы | Direct3D class "Device " |
| BeginScene | Готовит устройство для прорисовки примитивов (простых форм) в кадре. BeginScene должна быть вызвана перед прорисовкой любых примитивов в кадре. |
| EndScene | Сигнал устройству, что все примитивы в кадре отрисованы. EndScene должна быть вызвана, когда все примитивы в кадре отрисованы. |
| DrawPrimitives | Прорисовывает примитивы. |
| Clear | Очищает окно перед прорисовкой следующего кадра. |
| Present | Отображает прорисованный буфер и готовит следующий для прорисовки. Present вызывается после EndScene и до следующей BeginScene (для следующего кадра). |
| GetTransform, SetTransform | Возвращает/Определяет мировые, экранныеи другие трансформации. Трансформации применяются для вертексных позиций и нормалей и/или текстурных координат. |
| GetTexture, SetTexture | Возвращает/Определяет текстуры связанные с данным текстурным состоянием. |
| Начиная с W7 весь пользовательский интерфейс базируется на DirectX. Таким образом, DirectX уже не просто графическая библиотека, а основная часть операционной системы. Microsoft предписывает разработчикам графических чипов детальный план необходимой функциональности, которому должны соответствовать все драйвера, находящиеся между операционной системой и DirectX. Производители не имеют особых вариантов - они обязаны следовать предписаниям Microsoft, иначе они теряют рынок Windows-машин. см: Windows Display Driver Model WDDM W7 Display Driver Model Windows Driver Kit (WDK) | 
|
Плюсы
:
1)
Mожно положиться на то, что W7 использует Графическое железо по полной. Не существует ни DDI не HEL, а только HAL.
2)
Mожно быть уверенным, любой драйвер для W7 предлагает минимальный набор команд "Direct3D 10".
3)
Пользовательский интерфейс W7 предлагает быструю высококачественную графику, прозрачность, анимацию, 3D и видео.
4)
Интернет-Страницы могут использовать WPF для быстрой DirectX-Графики.
Минусы
:
1)
Старые Графические карты, принтера, сканеры, не имеющие DirectX10.1-драйвера не будут работать под W7.
2)
Старые DirectX-игры, как правило не работают под W7.
Основными элементами W7-Графики являются:
a)
Desktop Window Manager
= DWM
b)
Windows W7 Display Driver Model
= WVDDM или короче WDDM, поддерживаемые W7-Графическими картами.
Работает так:
1.) Все окна и графические элементы (включая шрифты) в W7 - это Векторная Графика.
2.) Данные и команды Векторной Графики хранятся, управляются и позиционируются через DVM.
3.) DVM передает данные и команды WVDDM-драйверу.
4.) Драйвер преобразует все в формат данных и команд DirectX и загружает это все в свою Графическую карту.
5.) Графический пайплайн на карте отрисовывает картинку автономно (без участия CPU) с максимальной скоростью в Back-Buffer.
6.) как только Back-Buffer заполнен, Графическая карта переключает его как в состояние Front-Buffer для вывода на экран.
Плюсы
:
1)
WPF генерирует только Векторную Графику (за исключением текстур и видео) как
Минусы
:
1)
WPF работает только под Windows (Исключение -
