Графический компьютерный разработчик мультимедийный

Геометрические и растровые примитивы. На основе геометрических и растровых примитивов строятся все объекты. Из геометрических примитивов библиотека предоставляет: точки, линии, полигоны. Из растровых: битовый массив (bitmap) и образ (image)
Использование В-сплайнов. B-сплайны используются для рисования кривых по опорным точкам.
Видовые и модельные преобразования. С помощью этих преобразований можно располагать объекты в пространстве, вращать их, изменять форму, а также изменять положение камеры из которой ведётся наблюдение.
Работа с цветом. OpenGL предоставляет программисту возможность работы с цветом в режиме RGBA (красный-зелёный-синий-альфа) или используя индексный режим, где цвет выбирается из палитры.
Удаление невидимых линий и поверхностей. Z-буферизация.
Двойная буферизация. OpenGL предоставляет как одинарную, так и двойную буферизацию. Двойная буферизация используется для того, чтобы устранить мерцание при мультипликации, т.е. изображение каждого кадра сначала рисуется во втором (невидимом) буфере, а потом, когда кадр полностью нарисован, весь буфер отображается на экране.
Наложение текстуры. Позволяет придавать объектам реалистичность. На объект, например шар, накладывается текстура (изображение), в результате чего наш объект теперь выглядит не просто как шар, а как разноцветный мячик.
Сглаживание. Сглаживание позволяет скрыть ступенчатость, свойственную растровым дисплеям. Сглаживание изменяет интенсивность и цвет пикселей около линии, при этом линия смотрится на экране без всяких зигзагов.
Освещение. Позволяет задавать источники света, их расположение, интенсивность, и т.д.
Атмосферные эффекты. Например, туман, дым. Всё это также позволяет придать объектам или сцене реалистичность, а также «почувствовать» глубину сцены.
Прозрачность объектов.
Использование списков изображений.

1.2 Дополнительные библиотеки OpenGL

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

Первая из этих библиотек называется GLU. Эта библиотека стала стандартом и поставляется вместе с главной библиотекой OpenGL. В состав этой библиотеки вошли более сложные функции, например для того чтобы определить цилиндр или диск потребуется всего одна команда. Также в библиотеку вошли функции для работы со сплайнами, реализованы дополнительные операции над матрицами и дополнительные виды проекций.
Следующая библиотека, также широко используемая – это GLUT. Это также независимая от платформы библиотека. Она реализует не только дополнительные функции OpenGL, но и предоставляет функции для работы с окнами, клавиатурой и мышкой. Для того чтобы работать с OpenGL в конкретной операционной системе (например Windows или X Windows), надо провести некоторую предварительную настройку и эта предварительная настройка зависит от конкретной операционной системы. С библиотекой GLUT всё намного упрощается, буквально несколькими командами можно определить окно, в котором будет работать OpenGL, определить прерывание от клавиатуры или мышки и всё это не будет зависеть от операционной системы. Библиотека предоставляет также некоторые функции, с помощью которых можно определять некоторые сложные фигуры, такие как конусы, тетраэдры, и многие другие предметы сложной формы
Есть ещё одна библиотека похожая на GLUT, называется она GLAUX. Это библиотека разработана фирмой Microsoft для операционной системы Windows. Она во многом схожа с библиотекой GLUT, но немного отстаёт от неё по своим возможностям. И ещё один недостаток заключается в том, что библиотека GLAUX предназначена только для Windows, в то время как GLUT поддерживает много операционных систем.
Существуют и другие дополнительные библиотеки для OpenGL. Все они добавляют что-то своё или ориентированы на какую-то платформу. Например, существует такая библиотека как GLX – это расширение для X Windows, позволяющее использовать в X Windows OpenGL. GLX предоставляет не только локальный рендеринг, но и рендеринг по сети.

1.3 Эволюция OpenGL

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

Развитие стандарта OpenGL осуществляется специальной структурой, известной как Architectural Review Board (ARB) – Комитет по пересмотру архитектуры. Комитет состоит из представителей основных компаний, заинтересованных в развитии и использовании библиотеки. В их числе 3D Labs, SGI, Apple, NVIDIA, ATI, Intel, id Software и, конечно, Microsoft.
C начала 90-х годов прошлого века OpenGL используется в различных областях индустрии и науки. Архитектура библиотеки получилась настолько удачной, что уже на протяжении более десяти лет она остается стабильной и предсказуемой. OpenGL де-факто является стандартом в области программирования графики. Но в этом скрыт и ее недостаток. ARB работает довольно медленно – любое изменение стандарта требует множества согласований, документов и так далее. В силу этого OpenGL развивается небольшими темпами. Правда, до последнего времени с этим не было проблем, поскольку изначально библиотека предназначалась для быстрых рабочих станций профессионального уровня, которые обновляют не часто. Однако сейчас даже недорогие видеокарты стоимостью $100 превзошли уровень профессиональных монстров пятилетней давности стоимостью в тысячи долларов. И при этом обновление их возможностей происходит в среднем раз в год. Фактически OpenGL не поспевает за индустрией, поэтому игровые разработчики вынуждены использовать так называемый механизм расширений (extensions), чтобы получить доступ к новейшим функциям видеокарт.



Рисунок 1 – Эволюция OpenGL

На данный момент OpenGL прошла путь от версии 1.0 до версии 1.4 (и это за десять лет). Версия 2.0, обещающая революционные изменения, находится в процессе стандартизации. Развитие графической аппаратуры вышло за пределы исходной спецификации. Вторая версия OpenGL призвана поднять планку и вновь создать стандарт для компьютерной графики на десятилетия. Помимо прочего OpenGL 2.0 включает в себя возможность программирования всего графического конвейера на языке высокого уровня.

2. DirectX. Общая характеристика

DirectX – это набор определенных инструментов и технологий, который используют разработчики игр и мультимедийных приложений для того, чтобы обеспечить взаимодействие между драйверами устройств и операционной системой.

2.1 Основные компоненты DirectX

Практически все части DirectX API (интерфейса программирования приложений) представляют собой наборы COM-совместимых объектов.

В целом, DirectX подразделяется на:

• 
  DirectX Graphics, набор интерфейсов, ранее (до версии 8.0) делившихся на:
  
  • 
    DirectDraw: интерфейс вывода растровой графики (его разработка давно прекращена).
    
  • 
    Direct3D (D3D): интерфейс вывода трёхмерных примитивов.
    
• 
  DirectInput: интерфейс, используемый для обработки данных, поступающих с клавиатуры, мыши, джойстика и пр. игровых контроллеров.
  
• 
  DirectPlay: интерфейс сетевой коммуникации игр.
  
• 
  DirectSound: интерфейс низкоуровневой работы со звуком (формата Wave).
  
• 
  DirectMusic: интерфейс воспроизведения музыки в форматах Microsoft.
  
• 
  DirectShow: интерфейс, используемый для ввода/вывода аудио и/или видео данных.
  
  • 
    DirectX Instruments – технология, позволяющая на основе мультимедийного API DirectX создавать и использовать программные синтезаторы.
    
• 
  DirectSetup: часть, ответственная за установку DirectX.
  
• 
  DirectX Media Objects: реализует функциональную поддержку потоковых объектов (например, кодировщики/декодировщики)
  
• 
  Direct2D: интерфейс вывода двухмерной графики
  

2.2 Возможности DirectX

Рассмотрим современные достижения на примере DirectX 11. Одна из проблем, вставших сегодня перед разработчиками игр, связана с гибкостью шейдеров и их масштабируемостью, поскольку из-за этого они все больше усложняются. Например, если при выполнении какой-либо задачи необходимы несколько шейдеров, зачастую используется большой uber-шейдер, потому что он объединяет все шейдеры, которые могут понадобиться в этой задаче, в одной части кода.

Однако, обратной стороной этого подхода является то, что он приводит к возникновению невероятно сложных шейдеров, которые не только не превосходят по эффективности (в плане производительности) отдельные шейдеры, но они также очень плохо поддаются отладке. Другим решением этой проблемы является написания множества специализированных шейдеров, которые покрывают не только все возможные сценарии работы, но и различные классы аппаратных средств.
В целях улучшения производительности не желательно использовать очень сложные шейдеры на аппаратных средствах, не способных обрабатывать их достаточно быстро. Идеальное решение в данном случае состоит в том, чтобы использовать нечто, что будет гораздо быстрее обрабатывать на аппаратных средствах бюджетных классов, иначе это приведет к тому, что весь процесс слишком усложнится и появятся большие накладные расходы, связанные с переключением шейдеров. Понятно, что это может повлечь за собой большие объемы дополнительных работ - uber-шейдер является самым простым вариантов для разработчика когда дело доходит до написания кода, но это точно не является идеальным решением.
Microsoft полагает, что ответом на эту проблему являются подпрограммы, позволяющие разработчикам объединять шейдеры – это означает, что разработчики могут создать более простой и более специализированный шейдер для различных целевых классов аппаратных средств, при этом уменьшая частоту использования регистра по сравнению с вариантом, когда используется один шейдер, который управляет всеми остальными. Хотелось бы надеяться, что заставит быть разработчиков более амбициозными при написании шейдеров, однако это вряд ли окажет какое-либо прямое влияние на геймеров.
Прошло много времени с того момента, как Microsoft обновила алгоритмы сжатия текстур DirectX и, послушав отзывы и рекомендации разработчиков, компания почувствовала, что уже давно требуются новые усовершенствования. Из всех жалоб, поступивших от сообщества разработчиков, Microsoft обратила свое внимание на слабую поддержку текстур HDR-формата, а также на тот факт, что после мультитекстурирования результирующее изображение часто оказывалось чересчур «блочным», независимо от разрешения оригинальной текстуры.
Чтобы удовлетворить эти потребности, в D3D11 будут введены два новых формата текстур – BC6 (или BC6H) и BC7. Прежний формат текстур высокого разрешения, не мог избежать потерь; вместо него будет предложено сжатие 6:1 с 16 bpc (bit per channel) – это позволит осуществлять эффективное, но при этом относительно высококачественное текстурирование в сценах с широким использование HDR-освещения, однако текстуры при этом будут немного отличаться от оригинала.
BC7, в свою очередь, является LDR (low dynamic range) форматом текстур и предлагает сжатие для RGB в пропорции 3:1. Кроме того, BC7 также можно использовать вместе с альфа-каналом, но с небольшим падением производительности – степень сжатия при этом будет уже 4:1, однако качество текстур все еще очень будет высоким.
Microsoft также добавляет, что декомпрессия текстур в DirectX 11 должна будет проводиться в полном соответствии со спецификациями этого API. Причиной этого является стремление компании еще увеличить качество декомпрессии текстур, потому как до момента выхода DirectX 11 у производителей аппаратных средств будет некоторый запас по времени для настройки аппаратных способов декомпрессии текстур на устройствах класса DirectX 10 и ниже.

2.3 Эволюция DirectX

Изначально нацеленный на разработку видеоигр, DirectX стал популярен и в других областях разработки программного обеспечения. К примеру, DirectX, наряду с OpenGL, получил очень широкое распространение в инженерном/математическом ПО.

В 1994 году Microsoft была практически готова выпустить следующую версию Windows – Windows 95. Главным фактором, определяющим, насколько популярна будет новая ОС, являлся набор программ, которые можно будет запускать под её управлением. В Microsoft пришли к выводу, что, пока разработчики видят DOS более подходящей для написания игровых приложений, коммерческий успех новой ОС весьма сомнителен.
DOS позволяла разработчику получить прямой доступ к видеокарте, клавиатуре/мыши/джойстику и прочим частям системы, в то время как Windows 95, с её защищённой моделью памяти, предоставляла более стандартизованный, но в то же время весьма ограниченный и накладный доступ к устройствам. Microsoft нуждалась в новом способе дать разработчику всё, что ему необходимо. Айслер (Eisler), Сэйнт Джон (St. John), и Энгстром (Engstrom) решили эту проблему, назвав само решение DirectX.
Первый релиз DirectX был выпущен в сентябре 1995 года, под названием «Windows Game SDK».
Ещё до появления DirectX, Microsoft включила OpenGL в ОС Windows NT. Direct3D позиционировался как замена OpenGL в игровой сфере. Отсюда берёт своё начало «священная война» между сторонниками кросс-платформенной OpenGL и доступной лишь в Windows (в том числе Windows NT) Direct3D. Так или иначе, остальные части DirectX очень часто комбинируются с OpenGL в компьютерных играх.
В 2002 году Microsoft выпустила DirectX 9 с улучшенной и расширенной поддержкой шейдеров. С 2002 года DirectX неоднократно обновлялся. В августе 2004 года в DirectX была добавлена поддержка шейдеров версии 3.0 (DirectX 9.0c).
В апреле 2005 интерфейс DirectShow был перемещён в Microsoft Platform SDK.
Ключевые особенности версий: