Теория и технологии программирования

DirectX и OpenGL

Вот недавно читал журнальчик один.
И в нем в одной из статей промелькнула такая строчка, что
DirectX и OpenGl очень сильно схожи, но второй имеет кучу каких-то преимуществ
перед первым.
Якобы то, что умеет делать DirectX OpenGl это давно умела,
а что реализовано в DIrectX 10 OpenGl делает это без труда и не с такими требованиями к железу.
Я хотел узнать у знающих: так ли это все?
Если да, то почему не используют OpenGl вместо DirectX?
И вообще, в чем их отличие?
(Извиняюсь если тема не там открыта)
Как-то помню игру одну видел. Была там при старте в окне опция: использовать OpenGl или DirectX. На DirectX работало в несколько раз быстрее и выглядело в несколько раз красивее. Возможно, конечно, разработчики той игры что-то недописали в OpenGlе, но мне все-таки кажется, что OpenGl устарел.
ну насколько мне извесно ОпенГЛ кроссплатформенный(Виндовс, Линукс) ввиду это разумеется страдает производительность.
ДиректХ поддерживается и развивается блягодаря компании Майкрософт, и многие разработчики игр используют именно его как основную платформу(поэтому так мало игр для Линукс).
Ну и конечно вокруг директХ намного больше шумихи - чего только стоит отказ Майкрософот выпускать ДиректХ 10 для ВинХП.
По моему субьективному геймеровскому мнению Директ намного глючнее чем OpenGl.Когда в игре предлагается выбрать - всегда ставлю opengl.С ним хотябы Всё нормально идёт...а то помнится в НФС ХП2 играть с директом с прозрачными машинами весело было....ну или не совсем весело 1 миссию месяц проходил....:huh:
Может правда я ошибаюсь?и это всё из-за моих кривых рук?
А все-таки какая в них кардинальная разница-то?
Итак, подливаю масла в огонь холивара )
Что же все-таки скрывается за словами OpenGL и DirectX? Слова эти именуют те самые Application Programming Interface (API - Интерфейс Прикладного Программирования), библиотеки для обработки графической информации и прямого доступа к железу («software interface to graphics hardware», как обозначаются они в спецификации). Думаю, не надо объяснять, что библиотеки содержат набор уже однажды написанных функций, от самых простых (вывод точки на экран) до довольно сложных (построение готовых примитивов, например, трехмерной пирамидки), которые применяются практически в каждой программе. Базовые функции реализованы аппаратно, в виде части GPU, более сложные функции представляют собой программные модули, построенные на базовых командах. Видеокарта не всегда аппаратно поддерживает нужные для работы приложения функции, и в этом случае библиотека использует программные модули, эмулирующие требующиеся возможности.
Если попытаться объяснить понятным языком общую схему работы библиотеки (рис. 1), то она выглядит примерно так: программист дал команду сделать Tri-linear Filtering (трилинейную фильтрацию – уменьшить искажения в картах текстур). Программа вызывает графическую часть DirectX (Direct3D) и предает библиотечной функции данные и что нужно с ними сделать. Модуль библиотеки, отвечающий за работу с драйвером видеокарты, в свою очередь, передает ему необходимые данные и «выясняет», аппаратно или программно будет происходить обработка. Драйвер «видит», что D3D этой версии полностью поддерживается на железном уровне и «отвечает», что есть аппаратная поддержка, и «передает» информацию дальше – видеоадаптеру. Но на этой стадии разработчики видеокарты и драйвера могут внести в процесс свои коррективы. Например, Tri-linear Filtering – очень ресурсоемкая операция, поэтому на уровне драйверов она заменяется менее точной, но более быстрой Bri-linear Filtering (брилинейная фильтрация, реализована на картах ATi). И дальше драйвер «кладет» в регистры GPU все данные, которые обрабатываются в соответствии с запросом, после чего во framebuffer поступает двухмерный кадр, который и выводится на монитор.
На данный момент обе библиотеки являются мощными разработками с равным потенциалом. Нельзя сказать, кто лучше, кто хуже, также у обеих разработок имеется набор специфических, только им присущих «фишек».
Основные принципы работы
OpenGL. Изначально это только графическая библиотека. Основой для этой API является ядро, которое «умеет» обрабатывать примитивные объекты (как правило, треугольники). Сам интерфейс (для программиста) содержит много (порядка нескольких сотен) процедур и функций, необходимых для создания высококачественных графических изображений. Чтобы аппаратно реализовать многие функции (например, antialiasing или texturing) от видеокарты требуется наличие framebufferа (кадровый буфер), причем некоторые операции могут выполняться исключительно в нем.
Для работы с библиотекой программа сначала должна открыть окно во framebuffer (где будет происходить все операции), и потом уже контекст библиотеки связывается с этим окном. Такую операцию нужно проделать один раз, а далее все действия определяются через параметры обработки (рисование простых геометрических объектов: линии, точки, полигоны; рендеринг примитивов, включая их положение и цвет).
Для разработчика процессора видеокарты OpenGL является набором команд, которые влияют на работу графического железа. Если в наличии имеется только адресуемый framebuffer, то библиотека должна быть встроена в GPU. Чаще же плата содержит еще и графический ускоритель (состоящий из растровой подсистемы, которая занимается renderом 2D линий и полигонов). Графические процессоры способны лишь просчитывать и трансформировать геометрические данные (аналог элементарных операций, с которыми умеет работать обычный CPU - сложение и присваивание). Задачей создателя графической платы является разработка программного интерфейса GPU для разделения обработки команд OpenGL между GPU и остальным графическим железом. Такое деление должно быть специально оптимизировано под выполнение команд библиотеки.
Сама же библиотека реализована в виде информации о структуре, определяющей, как объекты будут нарисованы во framebuffer, причем некоторые из структур доступны пользователю, который может создавать различные вызовы процедур для изменения параметров.
Чуть выше мы рассмотрели, как вообще работает библиотека, сейчас же остановимся на простом примере - рисование текстурированной пирамиды средствами OpenGL. Для этого посмотрим на базовые понятия (не забывая рисунок 2), требующиеся программисту для выполнения этой задачи:
Vertex (вершины) - образуются после указания координат в 2-х, 3-х или 4-мерном пространстве. В нашем случае мы задаем четыре координаты в 3D пространстве, которые обозначают вершины фигуры.
Vertex Arrays (массив вершин) – для работы с множеством вершин требуется обрабатывать большое количество команд (для образования простых геометрических фигур), чтобы избежать ненужной вычислительной нагрузки существует объединение вершин. В этом случае из них образуется массив, который содержится в памяти. Для работы с пирамидой в целом вершины объединяются под единым именем.
Buffer Objects (буферные объекты) – если требуется сохранить данные (те же Vertex Arrays) в быстрой памяти видеоадаптера для последующего повторного использования, существуют Buffer Objects, которые осуществляют распределение, инициализацию и извлечение информации об объекте из памяти.
Evaluators – средства для множественных преобразования координат и цвета. После создания четырех вершин определяются команды для обработки (которые записываются в Display List) и проводятся усреднения и просчет геометрической поверхности (на этом шаге уже появляется каркас объекта).
Coordinate Transformation (трансформация координат) – все объекты перед выводом во framebuffer претерпевают изменение своих координат (из их программного представления в «оконное» для framebuffer), схема такого преобразования представлена на рисунке 3. Причем в этот момент происходит подготовка к растеризации (обрезаются лишние части фигуры, которые вылезают за экран).
Rasterization – процесс, в котором вся картинка преобразовывается к 2D виду. Растеризатор обрабатывает объект, раскрашивает его, накладывает текстуру, и на выходе получается кадр, который далее поступает во framebuffer, а уже оттуда на монитор.
То есть видно, что программист последовательно определяет только основные параметры для той или иной операции. Дальнейшее происходит без его участия, средствами библиотеки, драйвера и, наконец, видеоадаптера.
FrameBuffer (кадровый буфер) - некая область памяти для временного хранения информации о точках, составляющих один кадр изображения на мониторе. Открыть окно во FB – это значит распределить видеопамять под изображение.
DirectX. Этот API является комплексной библиотекой, которая содержит в себе интерфейсы (для программиста) по обработке не только графики. Мы же рассматриваем только графическую ее часть.
Так же как и OpenGL, DirectX на низком уровне взаимодействует с аппаратной частью компьютера и предоставляет программисту набор интерфейсов для обработки графики, однако большим отличием от конкурента является использование Component Object Model (COM). То есть для работы с изображением нужно не просто вызвать определенную функцию или процедуру, а провести еще ряд дополнительных манипуляций для получения доступа к объектам (работа с которыми происходит только через интерфейсы), а после этого каждому объекту нужно заполнить некий набор необходимых свойств, без которых он является неопределенным. Актуальными все эти шаги являются только для программиста, поскольку после компиляции программы команды на обработку графики (для драйвера и видеоплаты) идут последовательно, вне зависимости от того, как было создано приложение.
Чтобы начать работать с графической библиотекой, требуется открыть окно программы, но далее нужно также создать устройство отрисовки и тем самым произвести инициализацию Direct3D. После выполнения этого шага идет процесс просчета и отображения сцены.
На аппаратном уровне API выполняется следующим образом: D3D обеспечивает независимость от Hardware Abstraction Layer (HAL - аппаратный уровень абстракции). HAL – это железо-зависимый интерфейс (не поддерживающий эмуляции), который разрабатывается создателем видеоадаптера и включает в себя поддержку D3D. В данном случае Microsoft описала, как должна быть реализована D3D аппаратно, а уже производители реализуют нужные функции в своих чипах. То есть получается такая ситуация, когда программа ничего не знает об установленном оборудовании и напрямую с ним не взаимодействует.
HAL может содержать три разных типа модели обработки вершин (на одном устройстве) - программный, аппаратный (который зависит от конкретного девайса) и смешанный. Аппаратный тип поддерживает только обработку вершин и дает возможность небольших изменений состояния устройства по запросу приложения. Кроме использования возможностей видеокарты, DirectX в полной мере пользуется инструкциями AMD 3DNow! и Intel Pentium SIMD (одна команда – много данных), которые включены в обработку некоторых вершинных шейдеров.
Для создания сцены потребуется инициализировать D3D объект для рисования, включая создание объекта, указание параметров отображения, создание D3D устройства, причем в параметрах устройства можно указать способ обработки вершин – аппаратный или программный. Далее производятся похожие с OpenGL преобразования, но с учетом того, что все операции работают над объектами. При завершении программы нужно закрыть устройство, но на деле все же этот процесс выглядит немного сложнее.
В последней версии DirectX появились интересные возможности, увеличивающие реалистичность графики:
HLSL (High-Level Shader Language - Высокоуровневый Язык Шейдеров) - позволяет управлять потоком команд;
Контроль над выполнением шейдера;
Взаимодействие с GDI (Graphics Device Interface);
Поддержка замещающих карт (Displacement mapping) - изменение координат полигона;
Поддержка 40-битного цвета (более 1.0 млрд. цветов).
Pixel Shaders - это небольшие подпрограммы (выполняются на графическом процессоре), которые работают с каждым пикселем при создании текстуры и применяются для просчета света, создания различных эффектов. В библиотеке OpenGL они отсутствуют по причине того, что когда создавалась спецификация, шейдеры еще не были придуманы, и поэтому сегодня их включили в виде расширений.
Отличия. По своей сути обе библиотеки различаются обработкой графической информации, и если OpenGL – это процедурная система, то DirectX основан на COM-модели. Однако, даже несмотря на различную природу работы с информацией, обе они «заточены» под взаимодействие с «железом». OpenGL не поддерживает Pixel Shaders, однако это не повод отказываться от работы с этой библиотекой (пример тому Unreal Tournament, движок которого построен на основе OpenGL). Библиотека DirectX умеет эмулировать некоторые функции, не поддерживаемые аппаратно, однако на пиксельном уровне это неосуществимо и программа должна сама проверять возможности такой эмуляции. Чтобы внедрять новые технологии, у OpenGL существует механизм расширений, когда различные функции (недоступные изначально, но реализованные аппаратно) разрабатываются производителем железа и поддерживаются спецификацией для конкретной модели видеоадаптера. В DirectX система немного другая - версия библиотеки может содержать или не содержать определенных функций (даже если они присутствуют в железе) и для их поддержки требуется ждать нового релиза DX, однако Microsoft активно общается с производителями видеокарт, и такая ситуация возникает достаточно редко.
То есть, хотя поддержка на уровне железа и реализована по-разному (различается как реализация базовых функций, так и фирменные технологии, направленные на улучшение качества графики), выявить лучший механизм сложно, поскольку новые функции OpenGL доступны лишь через extensions, тогда как у DirectX приходится ждать новой версии библиотеки.
Программная поддержка
OpenGL. Поскольку эта библиотека разрабатывалась группой компаний, она является мультиплатформенной и поддерживается большим количеством языков программирования (включая Java, Perl, Python), операционных систем (Windows, Macintosh, *nix). Причем любой производитель видеоадаптеров может купить лицензию и выпустить свою версию OpenGL не только для компьютера, но и для других устройств (существуют реализации под игровые консоли, КПК и даже телефоны). Причем ARB рассматривает большинство расширений, созданных производителями железа, и всегда есть вероятность их включения в спецификацию следующей версии библиотеки.
DirecX. Это детище одной лишь Microsoft, и соответственно официальная поддержка только операционных систем семейства Windows и платформы XBox. И исходя из такой монопольности, развитием и внедрением новых функций занимается только эта корпорация.
Точка зрения программиста
Если посмотреть на программную реализацию обоих библиотек, то можно сделать единственный вывод: программировать приложения с использованием OpenGL гораздо легче, чем писать их под DirectX (для примера: чтобы нарисовать обыкновенный треугольник на экране с использованием DirectX нужно написать почти в 5 раз больше текста, чем с использованием OpenGL). Правда, разработчики D3D постоянно пытаются облегчить работу программистов, объединяя наиболее часто используемые вызовы и операции в Common Files.
Выводы
Итак, обе библиотеки облегчают работу конечного программиста и обеспечивают интерфейс программы с конкретным железом. Они не совместимы между собой и имеют свои фирменные особенности, поэтому производителям приходится реализовывать в своих ядрах базовые функции обоих API, причем учитывать дополнительные функции новых версий и расширений.
Окончательно можно сделать следующий вывод: обе библиотеки достаточно мощные и производительные, но их преимущества проявляются в разных областях. DirectX оптимально подходит для создания игр и других графических приложений под операционной системой Windows (что чаще всего и происходит), OpenGL же лучше всего проявляет себя на мощных рабочих станциях и там, где требуется совместимость приложений с различными платформами (как программная, так и аппаратная). Хотя и в сфере игр эта библиотека так же достаточно востребована (Doom III, Unreal Tournament 2004).
Издательский дом ООО "Гейм Лэнд" ЖУРНАЛ ЖЕЛЕЗО #6, АВГУСТ 2004 г.
DirectX против OpenGL
Алексей Малашин
Xakep Железо, номер #006, стр. 006-068-7
--------------------------------------------------------------------------------
В будущем планируется использование «железа», программируемого при помощи языка HLSL – High Level Shading Language у DirectX 9 и программирования графического конвейера на языке высокого уровня OpenGL версии 2.0, что должно поднять уровень графики на новую высоту.
Основными изменениями в OpenGL 2.0 станет поддержка программируемых GPU (то есть в процессе обработки картинки можно будет управлять поведением пиксельного конвейера), управление памятью и сжатием пикселей (pixel packing), что позволит уменьшить занимаемый текстурой объем памяти. Реализовано это будет через новый высокоуровневый язык (который, как и библиотека, останется независимым от аппаратной платформы). Так же планируется включить в стандарт OpenML - набор функций, добавляющий возможность обработки видео.
Будет два вида второй версии библиотеки - Pure OpenGL 2.0 и OpenGL 2.0, отличаться они будут тем, что в первую будет включена полная спецификация версии 1.3 (сделано это для сглаживания процесса перехода к новой спецификации), а вторая будет лишена всех ненужных функций.
Microsoft включает в Windows библиотеки OpenGL, причем версии «слегка» устаревшей, которая ко всему прочему не использует аппаратные возможности ускорения, это серьезное «упущение» исправляют драйверы графических ускорителей.
Полезные ссылки:
http://www.microsoft.com/directx - официальная страница DirectX.
http://msdn.microsoft.com/directx - документация и статьи по DirectX.
http://www.opengl.org – официальная страница OpenGL.
http://www.ati.com/developer - поддержка разработчиков приложений под видеоадаптеры ATI.
http://developer.nvidia.com/page/home - поддержка разработчиков приложений под видеоадаптеры nVIDIA.
Dx - любят создатели игр, за мега пак D3d, DInput, DPlay, DSound (ничего не забыл?)
OGL - любят все остальные и другие(назовем так) создатели игр.
Сравнение Dx и OGL является безграмотным, корректное сравнение OGL и D3d.
Оба апи хороши в чем то...
В плюс DirectX я всегда ставлю то, что этот набор либ позволяет работать с различными вещами (звуковуха, джойстик и т. п.), а не только с графикой.
хотелось бы уточнить:
1)Говорят в DX10 программировать легче чем в 9 это так?
1.1)если это так то где легче программировать в dx10 или opengl?
2)На сколько они бесплатны?т.е. платно ли создание на них коммерческих и опен сорс проэктов?
3)OpenGL вроде собиралась дать ответ 10dx т.к. её(openGL) версия уже несколько устарела... что про это слышно?
4)Дайте пример игры на OpenGL с самой хорошей графикой.
5)Какая примерно разность в производительности?
6)говорите кросс платформенность OpenGL, а под кпк можно? с использованием видеокарты? intel 2700G.
Компания Microsoft пошла путем внесения изменений в свою графическую библиотеку Direct3D. Переодически выпускается новая версия, измененная для поддержки новых возможностей. При этом эти изменения зачастую оказываются довольно радикальными. И фактически обнуляют усилия, потраченные на изучение предидущей версии этой библиотеки.
Иногда бывает что новые возможности так и не вошли в очередную версию Direct3D в связи с какими-то соображениями компании.
Разработчики OpenGL пошли другим путем - в место постоянных серьёзных изменений интерфейса библиотеки был введен механизм, позволяющий разработчикам граф. ускорителей самим давать разработчикам ПО доступ к новым аппаратным возможностям. Этот механизм полчил название расширений OpenGL extensions.
Это собственно и ответ на заявление, что OGL устарела.
При установке новейшего драйвера на свой device ты устанавливаешь последнюю версию OGL.
А моя старинькая FX5500, к примеру имеет около 110 extensions.
Есле хотите то оставляйте email, скину мою прогу, которая выводит версию OGL и все расширения которые поддерживает ваш device.
Вот недавно читал журнальчик один.
И в нем в одной из статей промелькнула такая строчка, что
DirectX и OpenGl очень сильно схожи, но второй имеет кучу каких-то преимуществ
перед первым.
Якобы то, что умеет делать DirectX OpenGl это давно умела,
а что реализовано в DIrectX 10 OpenGl делает это без труда и не с такими требованиями к железу.
Я хотел узнать у знающих: так ли это все?
Если да, то почему не используют OpenGl вместо DirectX?
И вообще, в чем их отличие?
(Извиняюсь если тема не там открыта)
OpenGL наверняка все же более производительный чем DirectX. Поскольку в основу рендеринга OpenGL положены полигоны, а в основу DirectX - триугольники. по-этому даже для прорисовки квадрата в OpenGL необходимо задать всего 4 вершины, в то время как в DirectX в вуершинный буффер необходимо занести 6 вершин, что непосредственно влияет на скорость обработки объекта и просто напросто расходует лишнюю память. Но с введением буфера индексов вершин эта проблема была разрешена. По-этому если делать проэкты с умом, OpenGL никогда не превзойдет DirectX. Незря ведь около 90% разработчиков используют библиотеки DirectX а не OpenGL. Еще около 5% процентов - Jamax, который некоторым образом зависит от DirectX, но является более производительным и более простым для понимания.
Кстати как по мне, нашел вполне неплохой сайт посвященный DirectX http://DXGraphic.ho.ua. Есть мелкие недочеты с ссылками внутри текстов, но сайт оставляет вполне приятное впечатление!)
Самое главное преимущество OpenGL - переносимость приложений при использовании GLUT или SDL.
И я не думаю, что Кармак просто так начал бы делать свою игру Rage именно с использованием OpenGl, а не DX, если бы он не был уверен в превосходстве первого. Т.к. там используется _ОЧЕНЬ_ тяжелая технология (мегатекстуры), то ему надо наибольшая производительность. ДУмаю, что Кармак знает свое дело, поэтому про превосходство DirectX вопрос довольно спорный. Кстати в книге по OpenGL "OpenGL: Суперкнига" было написано почему все считают DirectX более произоводительным для real-time рендеринга.
дх не переносим в отличае от ОГЛ. ОГЛ стандартизирован, а в ДХ мелкомяхкие воротят что хотят. У ДХ есть приемущество- управление, звук...вобщем не только графика в отличае от ОГЛ, но если на то уж пошло то почему бы не писать на XNA, он тоже не переносим, но зато огромный набор всякой всячины для работы со звуком и джостиками... возможность без заплётов писать игры под винду и Хбокс360, только проблема с производительностю, тк пакет ООП гораздо медленее апишных аналогов, + хна хочет себе фрэймворк.
Сообщение от sbk89
OpenGL наверняка все же более производительный чем DirectX. Поскольку в основу рендеринга OpenGL положены полигоны, а в основу DirectX - триугольники.
Треугольник и есть полигон(частный случай). В конечном итоге все полигоны триангулируются.
Мое скромное мнение - производительность в этом случае зависит исключительно от прямоты рук разрабов.
Кстати, ОпенГЛ как раз обновляется медленнее.Еще не сильно нравится механизм расширений - на мой взгляд графический апи должен быть монолитным, строгим и не должен вызывать лишних вопросов. Гибкость - это хорошо,конечно....но все же.