Directx7 введение в directdraw


Directx7: введение в directdraw

DirectDraw это часть DirectX и представляет из себя API. Первоначально с появлением Windows оказалось, что игры писать практически нельзя. То есть они очень медленно работали. При программировании в Windows графики используется GDI. Но как раз этот GGI очень медленный. Проблема не нова. Те кто программировал в DOS знают, что наибольшею скорость можно достичь, напрямую обращаясь к видеопамяти. Посмотрите на схему ниже, все операции производятся в обход GDI. И мы можем работать либо с уровнем HAL либо HEL. Разница в совместимости. HAL обеспечивает запись в память. Данный компонент имитирует большой участок памяти в независимости от реальной организации видео карты. Для вас память сплошная. При попытке обращения этот уровень разбирается, куда и что нужно писать в реальную память адаптера. HEL создан для унификации. Дело в том, что многие адаптеры поддерживаю ряд возможностей, помогая существенно упростить управление ими. Например, пересылку блоков памяти из одного участка в видео памяти в другой на уровне адаптера. Но этого может и не быть. Вот если этого нет HEL эмулирует данную возможность программно и позволяет не думать о том кто это сделает. Если видео карта, то хорошо, нет программным путем.

Для работы с DirectDraw он должен быть у Вас установлен. Есть много версий DirectDraw. Мы пока будем рассматривать DirectX 7, а соответственно и DirectDraw 7.

Глава 1. Краткий курс DirectDraw

Полностью рассмотреть в одной главе всю библиотеку DirectDraw было бы нереально. В конце концов, даже о простейших аспектах DirectDraw написаны целые книги. DirectDraw представляет собой мощный и гибкий API, с помощью которого можно создать практически любое графическое приложение Windows. Именно гибкость существенно усложняет любые описания. Следовательно, было бы глупо пытаться рассмотреть все, от начала до конца, в одной главе.

И все же я решил попробовать.

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

Кроме того, я пропускаю многословные рассуждения о HAL (Hardware Abstraction Layer, прослойка абстрактной аппаратуры), HEL (Hardware Emulation Layer, прослойка эмуляции аппаратуры) и все кошмарные диаграммы, которые встречаются в справочных файлах SDK и некоторых книгах по DirectDraw. Вы читаете эту книгу, чтобы освоить программирование для DirectDraw, а не потому, что собираетесь писать драйверы устройств DirectDraw или изучать тонкости внутреннего устройства библиотеки.

В этой главе мы поговорим о практическом применении DirectDraw с точки зрения программиста. Прежде всего мы разберемся с тем, что же такое DirectDraw, и перейдем к обсуждению DirectDraw API. После этого будут рассмотрены некоторые практические вопросы, несомненно представляющие интерес при программировании для DirectDraw.

Что такое DirectDraw?

Весьма интересное определение DirectDraw можно найти у одного из его самых яростных противников — FastGraph. Графический пакет FastGraph появился уже довольно давно. В настоящее время существует версия FastGraph, которая поддерживает DirectDraw, но скрывает DirectDraw API за своим собственным нестандартным API. Тед и Диана Грубер (Ted and Diana Gruber), создатели и поставщики FastGraph, разместили на своем Web-узле файл, в котором доказывается, что FastGraph лучше DirectDraw.

В числе прочих доводов Груберы заявляют, что DirectDraw представляет собой «просто механизм блиттинга». Такая формулировка оказывается довольно точной, но чрезмерно упрощенной. Правильнее было бы сказать, что DirectDraw — аппаратно-независимый механизм блиттинга, наделенный некоторыми возможностями программной эмуляции. Главная задача DirectDraw как раз и заключается в том, чтобы по возможности быстро и надежно копировать графические изображения в память видеоустройств (блиттинг).

DirectDraw можно рассматривать и с другой точки зрения — как менеджер видеопамяти. DirectDraw распределяет блоки памяти и следит за состоянием каждого блока. Программы могут по своему усмотрению создавать, копировать, изменять и уничтожать такие блоки, причем конкретные подробности этих операций остаются скрытыми от программиста. Такое описание тоже оказывается излишне упрощенным. Во-первых, DirectDraw может использовать не только видеопамять, но и обычную память (RAM). Кроме того, при проектировании менеджеров памяти основное внимание обычно уделяется надежности, а не быстродействию. При проектировании же DirectDraw главной целью было именно быстродействие.

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

Термины и концепции

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

Видеорежимом называется набор параметров, поддерживаемый аппаратурой видеокарты (видеоадаптера) и позволяющий организовать вывод графического изображения. Самым известным атрибутом видеорежима является разрешение экрана. По умолчанию в Windows используется видеорежим с разрешением 640×480. Это означает, что на экране выводится 640 пикселей по горизонтали и 480 пикселей по вертикали. Также часто встречаются видеорежимы с разрешением 800×600 и 1024×768. Некоторые видеокарты поддерживают так называемые режимы ModeX. Типичный режим ModeX имеет разрешение 320×200.

Видеорежимы также различаются по глубине пикселей (pixel depth). Этот параметр определяет количество различных значений, принимаемых отдельным пикселем, и, следовательно, количество отображаемых цветов. Например, в видеорежиме с глубиной пикселей в 8 бит каждый пиксель может иметь один из 256 различных цветов. В режимах с 16-битной глубиной пикселей поддерживается отображение до 65536 цветов. Глубина пикселей обычно равна 8, 16, 24 или 32 битам.

Видеорежимы реализуются специальным устройством, установленным на компьютере, — видеокартой. На видеокарте устанавливается отдельная память, не входящая в основную память компьютера. Память, установленную на видеокарте, мы будем называть видеопамятью, а обычную память (RAM) — системной памятью. Объем памяти, необходимой для поддержки определенного видеорежима, определяется разрешением и глубиной пикселей в этом режиме. Например, для видеорежима 640×480×8 (640×480 пикселей, каждый из которых имеет глубину в 8 бит) требуется 307300 байт. Видеорежим 1024×768×16 требует 1572864 байт. Для поддержки видеорежимов используется видеопамять. Следовательно, режимы, поддерживаемые конкретной видеокартой, ограничиваются объемом установленной видеопамяти. Скажем, режим 1024×768×16 не поддерживается видеокартами с 1 Мбайт памяти, потому что для него такой объем памяти недостаточен.

Одна из ключевых возможностей DirectDraw — переключение видеорежимов. Она позволяет приложению DirectDraw обнаружить и активизировать любой режим, поддерживаемый установленной видеокартой. Переключение режимов подробно рассматривается в главе 4.

Основная причина, по которой DirectDraw обеспечивает оптимальное быстродействие, состоит в том, что во всех возможных случаях применяется аппаратное ускорение. Это означает, что видеокарта выполняет некоторые операции с помощью встроенных в нее аппаратных средств. Аппаратное ускорение обладает двумя основными преимуществами. Во-первых, в нем используются средства, спроектированные специально для ускорения графических операций. Тем самым обеспечивается максимальная скорость выполнения всех действий. Во-вторых, аппаратное ускорение освобождает процессор компьютера от необходимости выполнения этих операций, благодаря чему процессор может заняться другими задачами.

Поверхностью (surface) в DirectDraw называется прямоугольная область памяти, обычно содержащая графические данные. Блок памяти, изображающий поверхность, может находиться как в системной, так и в видеопамяти. Хранение поверхностей в видеопамяти обычно повышает скорость работы программы, поскольку большинство видеокарт не может обращаться к системной памяти напрямую.

Поверхности делятся на несколько типов. Простейшими являются внеэкранные (off-screen) поверхности. Внеэкранная поверхность может находиться как в видеопамяти, так и в системной памяти, но не отображается на экране. Такие поверхности обычно используются для хранения спрайтов и фоновых изображений.

Первичная (primary) поверхность, напротив, представляет собой участок видеопамяти, отображаемой на экране. Любая программа DirectDraw, обеспечивающая графический вывод, имеет первичные поверхности. Первичная поверхность должна находиться в видеопамяти.

Первичные поверхности часто бывают составными (complex), или, что то же самое, переключаемыми (flippable). Переключаемая поверхность может участвовать в переключении страниц — операции, при которой содержимое всей поверхности мгновенно отображается на экране с помощью специальных аппаратных средств. Переключение страниц используется во многих графических программах как с поддержкой DirectDraw, так и без, поскольку оно обеспечивает очень гладкую анимацию и устраняет мерцание. Переключаемая первичная поверхность на самом деле состоит из двух поверхностей, одна из которых отображается на экране, а другая — нет. Невидимая поверхность называется вторичным буфером (back buffer). При переключении страниц поверхности меняются местами: та, которая была вторичным буфером, отображается на экране, а та, что ранее отображалась, превращается во вторичный буфер.

Как внеэкранные, так и первичные поверхности делятся на две разновидности: палитровые (palettized) и беспалитровые (non-palettized). Палитровая поверхность вместо конкретных значений цветов содержит индексы в цветовой таблице, которая называется палитрой. В DirectDraw палитровыми являются только 8-битные поверхности. Поверхности с глубиной пикселей, равной 16, 24 и 32 битам, являются беспалитровыми. Вместо индексов в них хранятся фактические значения цветов.

Поскольку в каждом пикселе беспалитровой поверхности находятся реальные цветовые данные, необходимо знать, в каком формате хранятся отдельные пиксели поверхностей. Формат пикселя описывает способ хранения красной, зеленой и синей (RGB) составляющих. Он зависит от глубины пикселей, видеорежима и аппаратной архитектуры. Форматы пикселей подробно рассматриваются в главе 5.

На жаргоне, принятом в компьютерной графике, «блиттингом» называется операция копирования. Примером типичного блиттинга служит копирование внеэкранной поверхности во вторичный буфер. Если аппаратное ускорение невозможно, DirectDraw эмулирует блиттинг на программном уровне. Такая эмуляция справляется со своей задачей, однако выполняется намного медленнее аппаратного блиттинга. Обычно аппаратные средства видеокарты допускают блиттинг лишь для поверхностей, находящихся в видеопамяти.

В блиттинге обычно участвуют две поверхности: источник (source) и приемник (destination). Содержимое поверхности-источника копируется в поверхность-приемник. В результате операции содержимое поверхности-источника остается неизменным; блиттинг влияет лишь на поверхность-приемник. Кроме того, блиттинг не всегда изменяет все содержимое приемника; любой прямоугольный фрагмент источника можно скопировать в любое место приемника.

При блиттинге непрямоугольных областей (например, спрайтов) применяется эффект прозрачности. Для этого некоторые пиксели поверхности помечаются так, чтобы они не копировались в ходе блиттинга. Такая пометка осуществляется с помощью цветовых ключей (color key).

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

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

К сожалению, некоторые возможности вообще не эмулируются DirectDraw (например, цветовые ключи приемника). Их использование оказывается рискованным, потому что без поддержки со стороны видеокарты такие операции могут закончиться неудачей. У разработчика остаются два варианта: отказаться от данной возможности или включить в приложение собственную программную эмуляцию.

Приложение, работающее в 8-битном видеорежиме, должно иметь палитру. Палитрой называется таблица цветов, к которой можно обратиться в любой момент. Если бы 8-битные видеорежимы обходились без палитры, то приложениям пришлось бы работать с фиксированным набором из 256 цветов. Палитра же позволяет указать, какие именно 256 цветов будут использоваться в приложении.

При использовании палитровых видеорежимов необходимо позаботиться о том, чтобы во всех графических объектах вашего приложения использовалась одна и та же палитра. В противном случае некоторые объекты будут отображаться в искаженных цветах. Палитры могут причинить немало хлопот, особенно когда вам придется выбирать единую палитру для отображения большого количества графических объектов. Тем не менее они обладают некоторыми преимуществами. Как упоминалось выше, палитры позволяют представить в ограниченном наборе максимальное количество цветов. Кроме того, с помощью палитр можно организовать палитровую анимацию (palette animation).

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

В идеальном случае блиттинг сводится к копированию всей поверхности на другую поверхность. Однако на практике источник довольно часто копируется на край приемника, или же приемник частично перекрыт другой поверхностью или окном. В таких случаях применяется отсечение (clipping). Оно позволяет скопировать лишь отдельную часть (или несколько частей) поверхности.

Отсечение чаще всего оказывается необходимым при написании оконных приложений DirectDraw, поскольку эти приложения должны подчиняться «правилам поведения» для рабочего стола Windows. Мы поговорим об оконных приложениях позднее в этой главе.

DirectDraw обеспечивает полноценную поддержку прямоугольного отсечения. Тем не менее в некоторых ситуациях бывает полезно написать свою собственную процедуру отсечения. Нестандартное отсечение рассматривается в главе 3.

Другие типы поверхностей

Внеэкранные и первичные поверхности (со вторичными буферами) образуют основу всех приложений DirectDraw. Тем не менее существуют и другие разновидности поверхностей. В их число входят оверлейные поверхности, альфа-поверхности, Z-буферы и поверхности 3D-устройств.

Оверлеи (overlay) представляют собой аппаратные спрайты; следовательно, они доступны лишь на видеокартах, поддерживающих работу с оверлеями. В отличие от программного спрайта при перемещении оверлея нет необходимости восстанавливать фоновое изображение.

Альфа-поверхности (alpha channel surface) используются для выполнения альфа-наложения (alpha blending). Альфа-наложение является более сложной формой прозрачности и позволяет осуществлять «полупрозрачное» копирование поверхностей. Альфа-поверхность может использоваться для управления прозрачностью отдельных пикселей. Такие поверхности имеют глубину в 1, 2, 4 или 8 бит. Альфа-поверхность с глубиной 1 бит поддерживает лишь два уровня прозрачности: нулевой (непрозрачный пиксель) и стопроцентный (полностью прозрачный пиксель). С другой стороны, 8-битные альфа-поверхности позволяют задавать до 256 различных степеней прозрачности. Альфа-наложение относится к числу возможностей, не эмулируемых в DirectDraw. Следовательно, для использования альфа-наложения необходимо иметь видеокарту, обладающую соответствующими аппаратными средствами, или же написать собственную функцию для программной эмуляции альфа-наложения.

Z-буферы и поверхности 3D-устройств используются в трехмерных приложениях. Эти типы поверхностей были включены в DirectDraw специально для поддержки Direct3D. Z-буферы используются при визуализации трехмерных сцен; они определяют, какие объекты сцены находятся ближе к зрителю и, следовательно, отображаются перед другими объектами. Поверхности 3D-устройств могут использоваться для синтеза трехмерных изображений в DirectDraw. Z-буферы и поверхности 3D-устройств в этой книге не рассматриваются.

Спецификация COM фирмы Microsoft

Библиотека DirectDraw реализована в соответствии со спецификацией COM (многокомпонентная модель объекта, Component Object Model) фирмы Microsoft. Спецификация COM предназначена для создания стопроцентно переносимых программных компонентов, наделенных возможностью безопасного обновления. О COM можно рассказать довольно много, но эта книга посвящена другой теме. Мы рассмотрим COM лишь в объеме, необходимом для использования DirectDraw.

В COM используется объектно-ориентированная модель, более жесткая, чем модели, принятые в языках типа C++. Так, доступ к COM-объектам всегда осуществляется с помощью функций. COM-объекты не могут иметь открытых переменных. Кроме того, наследование в COM выглядит ограниченным по сравнению с C++.

Объекты и интерфейсы

В COM четко разграничены понятия объектов и интерфейсов. COM-объекты обеспечивают настоящую функциональность, тогда как COM-интерфейсы предоставляют способы для работы с ней. Обращения к COM-объектам никогда не осуществляются напрямую, а только через интерфейсы. Это правило соблюдается так строго, что мы даже не знаем имен COM-объектов. Известны лишь имена интерфейсов, используемых для работы с объектами. Поскольку прямое обращение к COM-объектам невозможно, в дальнейшем речь пойдет в основном об интерфейсах.

COM-объект может поддерживать сразу несколько интерфейсов. На первый взгляд это может показаться странным, но все объясняется тем, что в соответствии со спецификацией COM-интерфейс после своего определения не может быть изменен или дополнен. Это было сделано для того, чтобы не нарушать работу старых программ при обновлении COM-объекта. Исходный интерфейс остается неизменным, а для работы с новыми функциональными возможностями объекта добавляется новый альтернативный интерфейс.

Все COM-интерфейсы являются производными от интерфейса IUnknown. Префикс I (от слова interface, то есть интерфейс) является стандартным для имен COM-интерфейсов. Имена всех интерфейсов DirectDraw начинаются с I, однако в документации обычно приводятся без префикса. В этой книге при упоминании COM-интерфейсов префикс I также будет опускаться.

Интерфейс IUnknown содержит три функции, наследуемые всеми COM-интерфейсами.

Функции AddRef() и Release() обеспечивают поддержку такого средства COM, как инкапсуляция времени существования (lifetime encapsulation). Она представляет собой протокол, согласно которому каждый объект сам отвечает за свое уничтожение.

Инкапсуляция времени существования реализована с помощью счетчика ссылок. Каждый объект содержит внутреннюю переменную, в которой отслеживается количество указателей или ссылок на него. В момент создания объекта счетчик равен 1. При создании дополнительных интерфейсов или указателей на интерфейсы значение счетчика увеличивается, а при уничтожении указателей на интерфейсы — уменьшается. Когда счетчик ссылок падает до нуля, объект уничтожает себя.

Функция Release() уменьшает значение внутреннего счетчика ссылок. Ее следует применять при завершении работы с указателем или его выходе из области видимости. Обе функции, AddRef() и Release(), возвращают значение, равное новому состоянию счетчика ссылок объекта.

Функция QueryInterface() позволяет обратиться к COM-объекту с запросом о том, поддерживает ли он тот или иной интерфейс. Вспомните, например, что обновленные COM-объекты предоставляют дополнительные интерфейсы, не изменяя существующих. Если данный интерфейс не поддерживается запрашиваемым объектом, возвращается указатель на альтернативный интерфейс.

Чтобы обратиться к объекту с запросом о поддержке некоторого интерфейса, используя функцию QueryInterface(), необходимо как-то идентифицировать этот интерфейс. Для этого используется значение GUID (глобально-уникального идентификатора, Globally Unique IDentifier) данного интерфейса. GUID представляет собой 128-битное значение, уникальное для всех практических целей. Значения GUID всех интерфейсов DirectDraw включены в заголовочные файлы DirectX.

Такого краткого введения в COM вполне достаточно для эффективной работы с DirectDraw API. Далее, по мере обсуждения DirectDraw API, вы поймете, насколько важна эта информация.

DirectDraw API

Один из способов оценить API — посмотреть на его размер. Большой, сложный API может быть результатом неудачного планирования. С другой стороны, большой API иногда свидетельствует и о том, что разработчики учли все возможные ситуации и позаботились о вас. Маленькие API нередко характерны для новых пакетов с ограниченными возможностями. С другой стороны, это может говорить и о том, что API делает только самое необходимое и ничего больше.

DirectDraw API невелик. В сущности, он настолько мал, что все его функции можно рассмотреть в одной главе (так мы и поступим), не превращая ее в справочное руководство. DirectDraw обладает некоторыми удобными средствами и подчиняется нескольким ограничениям.

Библиотека DirectDraw оформлена в виде четырех COM-объектов. Доступ к каждому объекту осуществляется через один или несколько интерфейсов. Вот их полный список:

Мы рассмотрим все интерфейсы вместе с входящими в них функциями. Тем не менее этот раздел не претендует на то, чтобы заменить собой справочное руководство. Help-файл, входящий в состав DirectX SDK, несмотря на все ограничения, содержит достаточно справочной информации, так что мы не станем подробно рассматривать все функции, а поговорим вместо этого о том, что делает каждая функция, для чего и с какой вероятностью она вам может понадобиться.

Интерфейсы DirectDraw и DirectDraw2

В первоначальном варианте библиотеки DirectX (еще в те времена, когда она называлась Game SDK) вся основная функциональность DirectDraw была сосредоточена в интерфейсе DirectDraw. Позднее, с выходом DirectX 2, рабочий интерфейс был усовершенствован. В соответствии со спецификацией COM интерфейс DirectDraw не изменился, а для работы с новыми возможностями использовался новый интерфейс DirectDraw2. Следует заметить, что интерфейс DirectDraw2 представляет собой расширение DirectDraw. Он предоставляет все возможности интерфейса DirectDraw, а также ряд дополнительных. При работе с DirectX версий 2 и выше можно выбирать между интерфейсом DirectDraw и DirectDraw2. Поскольку DirectDraw2 делает все то же, что и DirectDraw, а также многое другое, вряд ли можно найти какие-то доводы в пользу работы с DirectDraw. Кроме того, Microsoft выступает против хаотичного, непоследовательного использования этих интерфейсов. По этим причинам во всех программах, приведенных в книге, будет использован интерфейс DirectDraw2.


Ниже перечислены все функции интерфейсов DirectDraw и DirectDraw2 (в алфавитном порядке):

Далее рассмотрены функции интерфейса DirectDraw. Обратите внимание на то, что в оставшейся части этой главы термин интерфейс DirectDraw относится как к интерфейсу DirectDraw, так и к DirectDraw2. Уточнения будут приведены лишь в тех случаях, когда функция отличается в двух интерфейсах.

Функции создания интерфейсов

Интерфейс DirectDraw представляет саму библиотеку DirectDraw. Этот интерфейс является главным в том отношении, что в нем создаются экземпляры всех остальных интерфейсов DirectDraw. Интерфейс DirectDraw содержит три функции, предназначенные для создания экземпляров интерфейсов:

Функция CreateClipper() создает экземпляры интерфейса DirectDrawClipper. Объекты отсечения (clipper) используются не всеми приложениями DirectDraw, так что в некоторых программах эта функция может отсутствовать. Вскоре мы рассмотрим интерфейс DirectDrawClipper подробнее.

Функция CreatePalette() создает экземпляры интерфейса DirectDrawPalette. Палитры, как и интерфейс DirectDrawClipper, используются не всеми приложениями DirectDraw. Например, приложению, работающему только с 16-битными видеорежимами, палитра не понадобится. Тем не менее приложение, работающее в 8-битном видеорежиме, должно создать хотя бы один экземпляр DirectDrawPalette.

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

Экземпляры самого интерфейса DirectDraw создаются функцией DirectDraw Create(). DirectDrawCreate() — одна из немногих самостоятельных функций DirectDraw, не принадлежащих никакому COM-интерфейсу.

Интерфейс DirectDraw позволяет точно узнать, какие возможности поддерживаются как на программном, так и на аппаратном уровне. Функция GetCaps() инициализирует два экземпляра структуры DDCAPS. Первая структура показывает, какие возможности поддерживаются непосредственно видеокартой, а вторая — что доступно посредством программной эмуляции. Функция GetCaps() помогает определить, поддерживаются ли нужные возможности.

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

В DirectX SDK входит программа DXVIEW, которая сообщает о возможностях всех компонентов DirectX, в том числе и DirectDraw. На большинстве компьютеров информация о DirectDraw отображается в двух категориях: Primary Display Driver и Hardware Emulation Layer. Первая категория сообщает о возможностях аппаратных видеосредств. Во второй перечислены возможности, эмулируемые DirectDraw при отсутствии аппаратной поддержки. На компьютерах с двумя и более видеокартами, поддерживаемыми DirectDraw, DXVIEW выводит сведения о способностях каждой из них.

Функция SetCooperativeLevel() определяет уровень кооперации — степень контроля над видеокартой, необходимую для данного приложения. Например, нормальный (normal) уровень кооперации означает, что приложение не сможет изменить текущий видеорежим или задать содержимое всей системной палитры. Монопольный (exclusive) уровень допускает переключение видеорежимов и предоставляет приложению полный контроль над палитрой. Независимо от выбранного уровня вам необходимо вызвать SetCooperativeLevel().

Функции для работы с видеорежимами

Интерфейс DirectDraw содержит четыре функции для работы с видеорежимами:

С помощью функции EnumDisplayModes() можно получить от DirectDraw список доступных видеорежимов. По умолчанию EnumDisplayModes() перечисляет все видеорежимы, но по описаниям можно исключить из списка режимы, не представляющие для вас интереса. Функция EnumDisplayModes() не обязана присутствовать в программе, однако это желательно, если вы собираетесь организовать переключение видеорежимов. На рынке существует огромное количество видеоустройств, каждое из которых обладает своими возможностями и ограничениями. Не стоит полагаться на автоматическую поддержку любого конкретного видеорежима, за исключением принятого по умолчанию в Windows режима 640×480×8.

Функция SetDisplayMode() активизирует заданный видеорежим. Версия SetDisplay Mode() из интерфейса DirectDraw2 позволяет дополнительно задать частоту смены кадров. Этим она отличается от функции из интерфейса DirectDraw, в которой можно задать только горизонтальное и вертикальное разрешения и глубину пикселей. Функция SetDisplayMode() присутствует в любой программе, осуществляющей переключение видеорежимов.

Функция RestoreDisplayMode() восстанавливает видеорежим, действовавший до вызова SetDisplayMode(). Перед вызовом функций SetDisplayMode() и RestoreDisplayMode() необходимо предварительно установить монопольный уровень кооперации вызовом функции SetCooperativeLevel().

Функции для работы с поверхностями

Помимо функции CreateSurface() интерфейс DirectDraw содержит следующие функции для работы с поверхностями:

Функция DuplicateSurface() создает копию существующей поверхности. Она копирует только интерфейс поверхности, но не ее содержимое. Копия поверхности использует ту же область памяти, поэтому модификация содержимого памяти приведет к изменению изображения, представленного обеими поверхностями.

Функция EnumSurfaces() используется для перебора всех поверхностей, удовлетворяющих заданному критерию. Если критерий не указан, составляется список всех существующих поверхностей.

Функция FlipToGDISurface() используется перед завершением приложения, осуществляющего переключение страниц, чтобы обеспечить правильное восстановление первичной поверхности. Вспомните о том, что при переключении страниц происходит попеременное отображение двух поверхностей. Это означает, что приложение может завершиться, не восстановив исходной поверхности, отображаемой на экране. Если это произойдет, Windows будет осуществлять вывод на невидимую поверхность. Такой ситуации можно легко избежать с помощью функции FlipToGDISurface().

Функция GetGDISurface() возвращает указатель на единственную поверхность, с которой работает GDI. Весь графический вывод Windows осуществляется именно на поверхность GDI. Примером ситуации, когда эта функция может оказаться полезной, является программа копирования экрана, в которой DirectDraw используется для копирования произвольной части рабочего стола.

Функция GetAvailableVidMem() возвращает объем текущей доступной видеопамяти. Эта функция присутствует в интерфейсе DirectDraw2, но отсутствует в DirectDraw. С ее помощью приложение может определить, сколько поверхностей ваше приложение сможет создать в видеопамяти.

Функция Compact() не реализована в DirectX, однако в будущем она обеспечит механизм дефрагментации видеопамяти. Если ваше приложение постоянно создает и уничтожает поверхности, находящиеся в видеопамяти, дефрагментация может высвободить немало места.

Функции для работы с частотой смены кадров

Интерфейс DirectDraw содержит четыре функции, относящихся не к видеокарте, а к устройству отображения (монитору):

Говоря конкретно, эти функции относятся к механизму смены кадров на мониторе. С их помощью можно реализовать анимации с минимальным мерцанием и задержками. Тем не менее следует учесть, что эти функции поддерживаются не всеми комбинациями видеокарт и мониторов.

Функция GetMonitorFrequency() возвращает текущую частоту смены кадров монитора. Эта частота обычно измеряется в герцах (Гц). Например, частота в 60 Гц означает, что состояние экрана обновляется 60 раз в секунду.

Функция GetScanLine() возвращает номер строки развертки (горизонтального ряда пикселей), обновляемой в данный момент. Она не поддерживается некоторыми комбинациями видеокарт и мониторов. Если данная способность не поддерживается, функция возвращает код ошибки DDERR_UNSUPPORTED.

В высокопроизводительных графических приложениях обновление экрана обычно синхронизируется с процессом вертикальной развертки. Другими словами, первичную поверхность желательно обновлять в тот момент, когда монитор закончил очередное обновление экрана. В противном случае в одной части экрана будут отображаться новые данные, а в другой — старые. Подобный эффект называется расхождением (tearing). По умолчанию DirectDraw автоматически синхронизирует обновление экрана с завершением вертикальной развертки. В нестандартных ситуациях можно добиться синхронизации с помощью функций GetVerticalBlankStatus() и WaitForVerticalBlank().

Наш обзор интерфейса DirectDraw завершается функцией GetFourCCCodes(). Она возвращает коды FourCC, поддерживаемые видеокартой. Коды FourCC используются для описания YUV-поверхностей, не относящихся к стандарту RGB. Мы не будем рассматривать такие поверхности, так как они выходят за рамки этой книги.

Интерфейсы DirectDrawSurface

Множественные интерфейсы DirectDrawSurface, как и интерфейсы DirectDraw, возникли из-за особенностей спецификации COM. В исходном варианте работа с поверхностями осуществлялась через интерфейс DirectDrawSurface. В DirectX 2 появились новые функциональные возможности, представленные интерфейсом DirectDrawSurface2, а в DirectX 5 возник интерфейс DirectDrawSurface3.

Хотя в этой книге вместо DirectDraw повсюду используется интерфейс DirectDraw2, для работы с поверхностями мы будем придерживаться исходного интерфейса DirectDrawSurface, потому что нововведения интерфейсов DirectDrawSurface2 и DirectDrawSurface3 не слишком важны. В оставшейся части книги термин интерфейс DirectDrawSurface будет обозначать все три интерфейса, если при этом не возникает двусмысленности.

Илон Маск рекомендует:  Фильтр Emboss

Самый большой из всех интерфейсов DirectDraw, DirectDrawSurface, позволяет копировать и стирать содержимое поверхности, а также напрямую работать с ним из программы. В общей сложности он поддерживает 36 функций, перечисленных ниже (в алфавитном порядке):

Хронология версий DirectX

Лекция №6. DirectX. Основные положения.

DirectX (от direct — прямой, непосредственный) — это набор API, разработанных для решения задач, связанных с программированием под Microsoft Windows.Наиболее широко используется при написании компьютерных игр. Пакет средств разработки DirectX под Microsoft Windows бесплатно доступен на сайте Microsoft.DirectX API обновляется достаточно часто.

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

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

· DirectX Graphics, набор интерфейсов, ранее (до версии 8.0) делившихся на:

o DirectDraw:интерфейс вывода растровой графики (его разработка прекращена).

o Direct3D (D3D): интерфейс вывода трёхмерных примитивов.

· DirectInput: интерфейс, используемый для обработки данных, поступающих с клавиатуры, мыши, джойстика и пр. игровых контроллеров.

· DirectPlay: интерфейс сетевой коммуникации игр.

· DirectSound: интерфейс низкоуровневой работы со звуком (формата Wave).

· DirectMusic: интерфейс воспроизведения музыки в форматах Microsoft.

· DirectShow: интерфейс, используемый для ввода/вывода аудио и/или видео данных.

· DirectX Instruments — технология, позволяющая на основе мультимедийного API DirectX создавать и использовать программные синтезаторы.

· DirectSetup: часть, ответственная за установку DirectX.

· DirectX Media Objects: реализует функциональную поддержку потоковых объектов (например, кодировщики/декодировщики).

· Direct2D: интерфейс вывода двухмерной графики

Версия DirectX Логотип Номер версии Операционная система Дата релиза
DirectX 1.0 4.02.0095 Windows 95a 30 сентября 1995
DirectX 2.0 / 2.0a 4.03.00.1096 Windows 95 OSR 2 и Windows NT младше 4.0 5 июня 1996
DirectX 3.0 / 3.0a 4.04.0068 / 69 Windows 95 OSR 2.5 и Windows NT 4.0 SP3 последняя поддерживаемая версия DirectX для Windows NT 4.0 15 сентября 1996
DirectX 4.0 не выпущен
DirectX 5.0 4.05.00.0155 (RC55) Доступен как бета для Windows NT 4.0 16 июля 1997
DirectX 5.0 4.05.01.1721 / 1998 Windows 98 5 мая 1998
DirectX 6.0 4.06.00.0318 (RC3) Windows 98 SE последняя поддерживаемая версия DirectX Media для Windows NT 4.0 а также он был в Dreamcast 7 августа 1998
DirectX 6.1 4.06.02.0436 (RC0) Windows 95/98/98SE 3 февраля 1999
DirectX 7.0 4.07.00.0700 (RC1) Windows 2000 и Windows ME 22 сентября 1999
DirectX 7.0a 4.07.00.0716 (RC1) Windows 95/98/98SE/2000
DirectX 8.0 4.08.00.0400 (RC10) Windows 95/98/98SE/ME/2000 30 сентября 2000
DirectX 8.0a 4.08.00.0400 (RC14) Последняя поддерживаемая версия DirectX для Windows 95 7 ноября 2000
DirectX 8.1 4.08.01.0810 4.08.01.0881 (RC7) Windows XP 12 ноября 2001
DirectX 8.1b 4.08.01.0901
DirectX 8.2 4.08.02.0134 (4.09.0000.0134)
DirectX 9.0 4.09.0000.0900 Windows Server 2003 24 декабря 2002
DirectX 9.0a 4.09.0000.0901 26 марта 2003
DirectX 9.0b 4.09.0000.0902 (RC2) 13 августа 2003
DirectX 9.0c 4.09.0000.0904 (RC0) Windows XP SP2 последняя поддерживаемая версия DirectX для Windows 98SE Windows Me и Windows XP 9 августа 2004
DirectX 9.0L 4.09.0000.0905 Предоставляет дополнительные интерфейсы IDirect3D9Ex и IDirect3DDevice9Ex с функциональностью, доступной лишь через LDDM-драйверы ОС Windows Vista.
DirectX 10 (включен в состав Windows Vista) 6.0.6000.16386 Первая версия для Windows Vista. Информация по Direct3D10 10 ноября 2006
DirectX 10.1 (включен в состав Windows Vista SP1) 6.00.6001.18000 Windows Vista Service Pack 1,Windows Server 2008 Информация по Direct3D10.1 4 февраля 2008
DirectX 11 (включен в состав Windows 7) 6.01.7600.16385 Windows Vista Service Pack 2, Windows 7 Официальный анонс состоялся на Gamefest 2008. Информация по Direct3D11 22 июля 2009
DirectX 11.1 Windows 8 Developer Preview 14 сентября 2011


Не нашли то, что искали? Воспользуйтесь поиском:

DirectX Control Panel — описание

На современных компьютерах с последними версиями Windows нередко возникают проблемы, если попробовать запустить старое приложение, программу или игру. Неполадки с совместимостью случаются по разным причинам: отсутствие поддержки нового «железа», отсутствие нужных драйверов и их настроек и так далее. Именно для решения ситуаций второго типа предназначена DirectX Control Panel.

Описание

Под таким лаконичным названием скрывается расширение для панели управления Виндовс — пульт настройки DirectX. Он открывает доступ к ранее закрытым настройкам графики. Сразу же хотим упомянуть, что разработка утилиты не была завершена, хоть и велась компанией Microsoft. Так что часть опций все равно будет недоступной.

Рекомендуем! InstallPack Стандартный
установщик
Официальный дистрибутив DirectX
Тихая установка без диалоговых окон
Рекомендации по установке необходимых программ
Пакетная установка нескольких программ

DirectX-for-pc.ru рекомендует InstallPack, с его помощью вы сможете быстро установить программы на компьютер, подробнее на сайте.

DCP существует только на английском языке. Интерфейс состоит из восьми вкладок. Вкратце рассмотрим каждую из них:

  • DirectX — заглавное окно утилиты. Здесь содержатся сведения о текущей версии библиотеки (отображается не выше 9) и кнопка вызова информации о ПК DxDiag.
  • Direct3D — настройки 3D-графики. Наибольший интерес здесь представляет опция Allow Hardware Acceleration. Нередко именно ее настройка позволяет решить проблемы с совместимостью.
  • DirectDraw — параметры отрисовки. Здесь есть аналогичный тумблер — Use Hardware Acceleration, который тоже окажется полезным. Если нажать Advanced Settings, то отобразится расширенный набор опций.
  • DirectInput — установки по части устройств ввода. Здесь ничего интересного нет.
  • DirectShow — вкладка, актуальная для разработчиков с режимом отладки.
  • DirectSound — звуковые установки. Здесь получится выбрать устройство вывода звука и его захвата (микрофон).
  • DirectPlay и DirectMusic — нефункционирующие вкладки.


Установка

Запустить DirectX Control Panel на Windows XP, 7 и более поздних версиях ОС от Microsoft получится без каких-либо проблем. Но для начала «пульт управления» нужно установить. Делается это так:

  1. Загрузите directx.cpl с нашего сайта.
  2. Скопируйте полученный файл по пути: «системный диск\Windows\System32».
  3. Перезагрузите систему.
  4. Откройте панель управления и запустите элемент DirectX.

Альтернативный вариант

Иногда соответствующий элемент не появляется в панели управления. Но это не значит, что Control Panel не получится запустить. Есть и альтернативный вариант:

  1. Скопируйте полученный файл в любое место.
  2. Щелкните на него ПКМ.
  3. Выберите опцию с названием «Открыть с помощью панели…».

DirectX 7.0

Характеристики

Новая версия: 7.0

Обновлено: 2020-09-04 06:39:39

Разрядность: 32 и 64 бит

Совместимость: Windows XP, Windows Vista, Windows 7, Windows 8, Windows 10

Язык: Русский, Английский, Немецкий, Французский

Описание

Операционная система Windows 7 имеет достаточные характеристики для современных требований компьютерной графики. Утилита DirectX 10 для Windows 7 имеет усовершенствованные характеристики, которые нужны для создания реалистичной анимации, которая достигается четкой прорисовкой объектов, света и тени, различных текстур. Утилита реализует следующие функции:

Объекты имеют очень мягкие, но при этом четкие тени.

Ландшафт получил большее количество текстур, из-за счет чего стал более насыщенным.

Не только предметы, но и эффекты стали объемными.

Групповые сцены стали более прорисованными, при том это касается не только детальных, но и масштабных.

Отображения в стеклянных объектах или в воде, а изображение облаков и дыма, максимально реалистично. Также качественно отображен эффект преломление от попадающих солнечных лучей, которые отражаются от различных поверхностей.

Геймерам очень важно, когда графика идет одновременно со звуком. Это реализовано за счет многопоточной передачи данных. Обработка звука и изображений производиться разными компонентами.

Так звуковой компонент направлен на то, чтобы оборудование (звуковая карта, микрофон, наушники, колонки) были тесно связаны с программной частью и системой.

Графические компоненты отдельно отвечают за трехмерную и двухмерную графику. Двухмерную графику используют все программы операционной системы. Трехмерная является специфической и используется лишь некоторыми графическими программами и играми.

Благодаря DirectX 10 для Windows 7 происходит слаженная работа программной и аппаратной части компьютера. Оптимально налаживается связь между программами, системой и железом. Также распределяется нагрузка между процессорами компьютера и его жестким диском.

Старые игры и Windows 7 — новое лекарство от проблем

Нашелся человек, занявшийся проблемой работы классических игр в последних версиях Windows.

или же картинка будет выглядеть нормально, только вот отрисовываться будет буквально что «со скоростью света» — можно наблюдать обновление отдельных пикселов изображения невооруженным глазом. Конечно, путем хитрых и неочевидных манипуляций с ярлыками и рабочим столом проблему обычно можно решить, но финальный результат всё равно оставляет желать много лучшего.

Финскому программисту Jari Komppa надоели проблемы с запуском Gold-изданий игр серии Wing Commander и он решил взяться за проблему радикально. В результате на свет появился DirectDraw→OpenGL враппер DDHack (

0,1 Мб), решающий большинство графических проблем в текущих версиях Windows для многих старых игр. Достаточно скопировать содержимое архива в папку игры. В числе проверенных игр отмечены Wing Commander 1-4, Starcraft, Warcraft II и первые две части Fallout. Автор намерен со временем доработать враппер для поддержки большей части функционала DirectDraw, используемого в играх.

Комментарии

  • Леонид Сизиков 21 мая 2015 года, 23:18

Морские титаны — не работает

Илья Коваленко 2 января 2014 года, 17:10

Не помогло, только цвета потемнели

Борис Олесов 20 октября 2013 года, 19:18

Павел Долгоруков 1 декабря 2012 года, 19:05

забавно)) работает))) раньше к игрулькам батник подсовывал, который explorer перед запуском игры убивал и снова возрождал его при выходе из нее.

Иван Южный-парк 13 мая 2012 года, 14:27

У меня я без этого все работает

Tony Montana 10 марта 2012 года, 09:48

В Win7 и Vista игры с проблемами такого рода нужно запускать после закрытия процесса — EXPLORER

    Андрей Левчук 28 августа 2012 года, 21:32

Спасибо тебе, братишка :3
Теперь сможем с корешем в Казаков нормально по сетке поиграть :D

Андрей Охотник 23 октября 2011 года, 17:37

    Игорь Шевченко 24 октября 2011 года, 11:55

Нужно создать тему у нас на Форуме и подробно описать проблему.

Андрей Охотник 24 октября 2011 года, 13:15


А по какому адресу находится форум. Спасибо, что не оставили без внимания.

Игорь Шевченко 25 октября 2011 года, 15:09

Максим Пеньковских 6 октября 2011 года, 19:02

помогло но в игре все время если нажать на левую кнопку то сразу указатель уходить вверх и не как не опустиь=(

Феодосий Кипчук 19 августа 2011 года, 23:47

Посоветуйте не устаревшую книги по DirectX на русском языке

В этом разделе есть список литературы. Почти все книги по DirectX там устарели и всегда что-то не работает. Да и учить старое не охота, а ведь много чего изменилось. Я в разных примерах в разных книгах вижу совсем разный код.
В том списке есть книга 2008 года выпуска, т.е. вроде как еще свежая, под названием «DirectX 10 — это просто. Программируем графику на С++», но я так не нашел в интернете ее содержание(оглавление).
Покупать в слепую не хочу. Кто-то сказал, что эта книга является переводом документации по DirectX. Я не знаю на сколько там все подробно описано.

Хотелось бы книгу свежую, подробную, хорошо бы с теорией(математикой), хотя это можно и отдельно найти.

09.07.2012, 06:17

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

Книги на русском языке по Лазарусу
Доброго времени суток! Мне нужна бы печатная книга по lazarus! Подскажите пожалуйста, где её можно.

Поиск книги на русском языке OpenGL
Подскажите пожалуйста есть ли перевод этой книги ? .

Книги и пособия по SFML на русском языке
Здравствуйте, есть ли книги,пособия по sfml на русском языке?

Посоветуйте документацию на русском языке
Посоветуйте документацию ну русском языке про C#, начальную и легко доступную.

09.07.2012, 18:15 2 10.07.2012, 10:17 [ТС] 3

Да вот только примеры из книг не работают с последнем DirectX SDK(2010 June). Поставил старый sdk(8.1). Компилятор находит синтаксические ошибки в .h файлах sdk.

Добавлено через 23 минуты
Хотя только единственный пример не работает.

Добавлено через 2 минуты
Все таки остальные не работают.

10.07.2012, 19:44 4
10.07.2012, 19:44
11.07.2012, 05:16 [ТС] 5
11.07.2012, 07:46 6
11.07.2012, 08:21 [ТС] 7

Заказал книгу автора Алексей Попов «DirectX 10 — это просто. Программируем графику на С++.»
Отзывы на озоне хорошие, но этой книги в инете не нашел, поэтому я кроме оглавления не знаю что там. Посмотрим. Но мне хотя бы познакомиться в DirectX, чтобы я понял, что к чему и смог уже разобраться в нормальных, иностранных авторов(переведенных на русский) и более сложных книгах и, если что, исправить код примеров( если код устарел ). Да и книга не старая, т.е. код должен быть рабочим.

Если эта книга не понравиться, то буду читать Станислав Горнаков — «DirectX 9: Уроки программирования на С++». И пусть отзывы плохие и книжка может быть плохая, но как я уже повторил, хотя бы познакомлюсь с DirectX и перейду на другие книги. Так же книга вроде как не старая, т.е. код должен работать.

Потом наверно перейду к более сложным таким как:Франк Луна — «Введение в программирование трехмерных игр с DirectX 9» — первое издание, Тодд Баррон — «Программирование стратегических игр с DirectX 9»,Андре Ламот
Программирование трехмерных игр для Windows. Советы профессионала по трехмерной графике и растеризации

12.07.2012, 22:24 8
13.07.2012, 07:20 [ТС] 9

Arkanoid
Я лучше познакомлюсь с DirectX с помощью более простой книги, потом на Луну перейду.

Добавлено через 36 секунд

13.07.2012, 11:09 10
13.07.2012, 11:22 [ТС] 11

А что в DirectX11 полностью отличается от 10 и 9 версии? Т.е. названия функций, классов, интерфейсов — все это разное? И там все работает по другому?

PS моя видеокарта не поддерживает DirectX11

13.07.2012, 11:24 12

Не согласен категорически, сейчас у народа машины дома от суперкомпьютеров до калькуляторов, причем чаще ближе ко второму, а так может вообще учится кодить сразу там под Хbow с его оперативой? Нет это глупости, начинать надо с того, с чем проще работать. Советую 9 директ, книг -масса, примеров рабочих -масса, работать будет на любых ОС.

Поверьте мне) Когда ваша прога будет где то с год работы над ней — проблем будет много, а новые фичи уводят от понимания принципов работы. Так что вначала надо все ручками и то что попроще. А перейти на чтото новое будет просто потом, чем сразу в нем утонуть с головой.

13.07.2012, 12:09 13
13.07.2012, 14:49 14
13.07.2012, 16:17 15
13.07.2012, 21:32 16
13.07.2012, 23:33 [ТС] 17
14.07.2012, 00:28 18

Сударь, вы меня поражаете своим архиаизмом, вот сколько Вам лет если не секрет? Не думаю что Вы на много старше или младше меня ))) . Видеокарта, которая поддерживает DX11 у меня втыкнута в дешёвый ноут за 17 тыщь прошлогодней давнести. Да..есть ещё комп, на которм стоит GeForce 9800 GTX+, там только DX10 с шейдер моделью десятой. но этот коп у меня как антиквариат стоит ))
так для справки, вы видели графику, которую я тут как то по ссылке показывал из якобы battlefield 4 — http://www.youtube.com/watch?v=mV-gnh1En6E и вы думаете что у Ваших допотопных технологий есть будущее? Ну тут собственно дела каждого. Лично я ща пишу программу совершено не игрового сценария, но так вот я там хочу задействовать как можно больше вычислительной мощности графиш процессор юнита, ибо на обычном сипию очень медленно считается.

А собственно тут выбор за разработчиком. Если ты хочешь написать игру продаваемую — добро пожаловать в современные технологии, если ты настальгируеш — можешь хоть писать игры на DirectX 3. Но тут дело бизнеса. Хобби есть хобби, работа — есть работа. Каждому свою. Можно конечно ваще все на МАСМЕ писать, но тут вопрос, стоит ли игра свеч.

Перенос проекта из DirectDraw в DirectX (Direct2D)

Есть очень крупный проект и в нем есть файл на 6к строк, в котором описаны различные функции отрисовок (в основном графиков в реальном времени) с использованием DirectDraw(писалась лет 10 назад под xp). Встал вопрос о переносе на Win7. Начал искать информацию как и с чем тот DirecDraw есть. На вики сказано, что библиотека устарела и ее слили с DirectX`ом. Собственно сам вопрос, можно ли как-то перенести этот проект отделавшись малой кровью? Может быть кто сталкивался с подобным или знает сохранились ли, или хотя бы как именно видоизменились старые API. За ранее спасибо.

Microsoft DirectX – это очень просто!

Microsoft DirectX – это очень просто!

О чем пойдет речь в статье:

    Что такое DirectX?
    Для чего нужен DirectX?
    Что входит в DirectX?
    Что такое шейдер?
    Зачем нужны шейдеры? Конвейер и шейдерная модель
    Что дает пользователю компьютера очередная версия DirectX?
    DirectX 10. Эволюционное обобщение пройденного
    DirectX 10.1 Как же теперь жить? И пара слов об OGL

Когда говорят о “Microsoft DirectX”, то разные категории людей могут вкладывать в это различные понятия. Давайте разберемся, что может иметься в виду и что это такое на самом деле, для чего он нужен и чем же отличаются последние версии DirectX друг от друга.

Обратимся к первоисточнику – самой Microsoft:

http://msdn2.microsoft.com/en-us/library/bb219737.aspx
“DirectX is a set of low-level APIs for creating games and other high-performance multimedia applications. It includes support for high-performance 2D and 3D graphics, sound, and input”.

Учитывая, что API (Application Programming Interface) – это интерфейс разработки программ, буквальный перевод звучит так: “DirectX – это набор низкоуровневых программных интерфейсов для создания игр и других высокопроизводительных приложений. Он включает в себя поддержку высокопроизводительной 2D и 3D графики, звука и устройств ввода”.

Применим эти знания на практике. Если моя карта поддерживает DirectX, это значит, что она . поддерживает набор низкоуровневых. ну и далее по вышеприведенному тексту. Не срастается! Что-то здесь не так. Что же на самом деле поддерживает видеокарта? Попробуем разобраться.

В действительности, Microsoft предоставляет это определение для разработчиков программного обеспечения, следовательно, само собой под DirectX подразумевается APIs DirectX. А с точки зрения пользователя все выглядит несколько иначе. Поэтому дадим более общее определение, хотя оно при этом будет подлиннее.

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


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

Для поддержки разработчиков программного обеспечения Microsoft предоставляет DirectX SDK (Software Developing Kit) – набор программ и утилит разработчика программного обеспечения под технологию DirectX, а для системных программистов и разработчиков компьютерного оборудования есть WDK (Windows Driver Kit )– набор программ и утилит для разработки драйверов. Оба этих программных продукта распространяются свободно и доступны для скачивания с сайта Microsoft. К слову сказать, по прилагаемой к DirectX SDK лицензии, все графические и мультимедийные файлы и компьютерные модели разрешается использовать в своих программах для демонстрационных некоммерческих целей.

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

Сегодня уже трудно найти видеоадаптер, не поддерживающий хотя бы DirectX 7, поэтому для нормальной работы приложения, разработанного в соответствии с конкретной спецификацией DirectX, нужно, во-первых, чтобы операционная система поддерживала эту версию (плюс к тому были установлены соответствующие или более новые библиотеки DirectX в виде dll – файлов, которые обычно автоматически устанавливаются при инсталляции программы, если на компьютере установлены более старые версии библиотек), во-вторых, чтобы видеокарта была с поддержкой соответствующего DirectX и, в третьих, чтобы был установлен подходящий драйвер видеокарты. Несоблюдение первых двух условий не позволит приложению запуститься, а в случае с драйвером может оказаться так, что самый последний доступный драйвер не является лучшим для конкретного приложения (вплоть до полной неработоспособности программы), хотя, в целом, действует правило, что лучше использовать самые свежие версии драйверов и рекомендуется этого правила придерживаться.

Часто можно услышать фразу “графический стандарт DirectX”. Это верно лишь c большой натяжкой, особенно до DirectX 10, поскольку ничто не мешало производителям видеокарт легко утверждать о соответствии DirectX даже при несоответствии этой спецификации (хотя она и делится на обязательную и опциональную часть), вводя покупателя и пользователя в заблуждение. Этому способствовало и порождение компанией Microsoft нескольких вариантов DirectX одной версии и, в особенности, множества модификаций шейдерных моделей (SM — Shader Model), чем особенно отличилась версия DirectX 9. Впрочем, этому есть и свое логичное объяснение. Так сложилось исторически, что, хоть программируемый конвейер и возможность исполнения шейдеров впервые появились в версии DirectX 8, настоящая их обкатка происходила уже в DirectX 9.
Но к конвейеру и шейдерам мы вернемся чуть позже.

Несколько слов о том, что явилось катализатором появления DirectX. Безусловно, в первую очередь, это компьютерные игры. Персональные компьютеры и сейчас далеки от вычислительной мощности, позволяющей кинематографически реалистично воспроизводить на экране монитора с высоким разрешением полноценное интерактивное 3D действие в реальном режиме времени, тем более это им было не под силу двадцать лет назад. Поэтому программисты всегда боролись за каждый байт и мегагерц компьютерных ресурсов (а основные ресурсы – это процессорное время и оперативная память), выжимая все из топовых аппаратных решений, доступных на рынке. И в эпоху, когда основной ОС домашних компьютеров была DOS, очень много игр писалось на языке Ассемблер, что было достаточно трудоемко, но в умелых руках позволяло использовать 100% возможностей техники, так как позволяло напрямую программирвать видеокарту, модель распределения памяти и управлять системными ресурсами. Для тех, кто не застал это время, поясню, что, в отличие от Windows, MS-DOS (наиболее распространенная ОС того времени) – это однозадачная ОС, то есть запускаемая программа забирала все компьютерные ресурсы себе. Чтобы запустить другую программу, первую нужно было обязательно завершить, что часто делалось простой перезагрузкой компьютера.

Производители видеокарт тоже включились в эту гонку, выпуская новые и новые видеокарты, которые частенько и опережали свое время, и оказывались впоследствии тупиковым направлением развития. Но это уже совсем другая история.

Появление новой ОС – Windows 3.х привело к противоречию между конкретной программой, требующей в свое распоряжение максимальное количество ресурсов, и многозадачной ОС, делящей эти ресурсы по “справедливости” между приложениями. Кроме того, драйверы устройств перестали быть доступны программе напрямую – появилась прослойка в виде виртуальных драйверов. Несмотря на имеющуюся иерархию приоритетов у выполняемых в ОС программ, в первых версиях Windows быстродействие игр оказывалось неудовлетворительным. Поэтому долгое время DOS, которой разработчики игр отдавали предпочтение, сосуществовала параллельно с Windows. Но такое положение вещей не вписывалось в стратегию развития Microsoft и привело к интенсификации усилий по решению имеющихся проблем с быстродействием. Так появилcя Game SDK, впоследствии сменивший название на DirectX, призванный сделать программную прослойку от выполняемой программы до мультимедийного и графического оборудования универсальной, не требующей детального знания оборудования (это – дело производителя, задача которого – написать функциональный драйвер), легко создаваемой и сопровождаемой, минимальной по длине и максимальной по быстродействию.

Мы выяснили, что означает, фраза “моя карта поддерживает DirectX”. Впрочем, тут есть один нюанс. DirectX – это собирательное понятие набора программных компонент, и, хоть графическая часть и есть его наиболее существенная, сложная и объемная составляющая, там присутствует и поддержка оборудования, отличного от видеокарт. К примеру, видеокарта вряд ли поддерживает DirectInput (хотя технически ничто не мешает, например, установить на ней пару USB-разъемов для подключения джойстика или геймпада). Поэтому, правильно говорить о поддержке видеокартой компоненты DirectGraphics (которая, на самом деле, только “прикрывает” настоящие компоненты – Direct3D и Direct3DХ), составной части DirectX, но маркетинг – он и в Африке маркетинг – поэтому не только короче, но и гораздо солиднее звучит именно вариант поддержки DirectX целиком! И никаких гвоздей! Поэтому от этого стереотипа уже практически не избавиться. Мы ведь живем, по большей части, в демократических государствах, и, раз большинство считает, что поддерживает, то несколько голосов за правду утонут в общем хоре негодования. Чтобы не прослыть белой вороной, заявляем – наши видеокарты поддерживают DirectX! Однозначно и в полном объеме!

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

    DirectGraphics
    DirectSound
    DirectInput


Коротко, логично и понятно. В свое время в разные версии DirectX в разное время включались, убирались и восстанавливались вновь и другие компоненты – DirectDraw, DirectMusic, DirectPlay, DirectShow и еще несколько, но они или уже существуют только для обратной совместимости либо перенесены в другие SDK, и их использование не рекомендуется либо уже попросту невозможно.

Так классифицирует DirectX сама Microsoft. Но я бы добавил сюда и DirectX Graphics Infrastructure (DXGI) – компоненту инфраструктуры DirectX 10, которая вполне этого заслуживает. Более того, сама Microsoft в других местах ее так и позиционирует. К примеру, при описании отличий DirectX 10 от предыдущих версий читаем, среди прочего:
“Common 2D, focus and adapter-management functionality refactored into a new component: DXGI” ,
что в переводе звучит так:
“В новую компоненту DXGI выделены все общие операции в режиме 2D и функциональность, связанная с поддержанием фокуса и управления видеоадаптером”.

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

Последняя версия DirectX SDK на момент написания статьи (Август 2007) добавляет еще одну компоненту,

The Windows Vista Game Explorer,

обеспечивающую соответствие новым правилам Microsoft по разработке игр для платформы Windows — Games for Windows: Technical Requirements, Microsoft Corporation, Version 1.2.0007, August, 2007. В этих правилах, кстати, впервые прозвучало требование обязательной поддержки разрешения 1680х1050 (поддержка более низких разрешений 16:10 требовалась и раньше), а до сих пор это в драйверах Nvidia было лишь опциональным. С текстом этого документа можно ознакомиться на сайте разработчика, есть он и в составе DirectX SDK, начиная с августовской версии 2007 года.

The Windows Vista Game Explorer обеспечивает легкий, настраиваемый способ представить в ОС Windows Vista компьютерную игру. Эта компонента обеспечивает управление доступом, особенностями запуска, локализацию информации об игре и визуализацию ее представления (все игры теперь должны попадать в специальную папку Games, которую наверняка видели все пользователи этой ОС).

Несколько слов о компонентах DirectSound, DirectMusic и DirectInput.
DirectSound и DirectMusic находятся в подвешенном состоянии – обе компоненты получили от Microsoft “черную метку”. Это значит, что они более не развиваются (правда, в интерфейс DirectSound пока еще вносятся незначительные изменения) и при первом удобном случае будут заменены. На что? Это давно уже не секрет. Microsoft в последние годы сильно озаботилась мультиплатформенностью, правда часто вкладывая в это понятие свой смысл, но, тем не менее, такой шаг можно только приветствовать. И на знаменах (логотипах, заставках) DirectX, и в SDK уже давно присутствуют названия, начинающиеся с буквы “Х” — XNA, XACT, X3DAudio, XAudio2, XInput.
Говоря об использовании DirectXInput vs XInput, Microsoft прозрачно намекает (вернее, говорит открытым текстом), чем использование XInput предпочтительнее DirectXInput. Если посмотреть документацию, то выходит, что Xinput легче использовать, инициировать, он имеет единый кроссплатформенный интерфейс под Windows и Xbox 360, контроллеры от Xbox 360 будут вибрировать только через этот API, а иначе – не будут!, и будущие контроллеры под Xbox 360 (например, рули) смогут работать даже под Windows!
Надеюсь, намек все поняли.

В связи с этим удивляет положение Managed DirectX и анонс о прекращении упоминания о нем в следующей, ноябрьской версии DirectX SDK. Похоже, Microsoft хочет добиться, чтобы и наши правнуки играли на приставках Xbox 360, говоря о том, какой это удачный и современный продукт. Я понимаю, что департамент по развитию Xbox360 нанес удар по своей репутации (ведь правда, какая мелочь потерять несколько сотен миллионов для такого гиганта, как Microsoft) и должен как-то реабилитироваться. Ни в коей мере не умаляю достоинств этой приставки (скорее, наоборот, по совокупности потребительских качеств и учитывая возможности разработчика, считаю ее лучшей приставкой), мне просто не нравятся некоторые шаги Microsoft, которая частенько похожа на того медведя в лесу, который, чтобы сорвать всего лишь одну маленькую ягодку, мимоходом задевает и разрушает своей косматой лапой муравейник, вырывает малинник с корнями, даже не интересуясь, почему маленькие обитатели леса (те, кому удалось выжить) так его не любят. Он их даже не замечает. Только этот медведь, сидя на той же опушке через год, удивленно будет чесать свой затылок лапой — почему же там больше не выросло ни одной ягодки?

А на досуге предлагаю наиболее продвинутым пользователям компьютера решить задачу — поддерживает ли их видеокарта DirectSound, если она обеспечивает передачу звука по HDMI.

Слово «шейдер» очень часто употребляют неправильно, не понимая что это такое и отождествляя его с частью компьютерного оборудования. Но это понятие не относится к категории «hardware».
Что же такое “шейдер”? Это слово пришло в мир бытовых компьютеров из кинематографии, где так именовались специальные программы (“shaders”), участвующие в рендеринге (формировании) итогового изображения на экран (или в память). Поэтому шейдеры – это относительно небольшие программы, написанные на специализированных языках, которые выполняются графическим процессором. Для чего служат эти программы и почему заранее известно, что они небольшие? Современные ГПУ обрабатывают потоковую информацию – большие массивы однородных данных простых типов, которые надо обработать по короткому алгоритму и быстро передать дальше, чем меньше программа – тем быстрее обработка, хотя тенденция к усложнению явно прослеживается. Впрочем, большими эти программы (по крайней мере по отдельности) еще долго нельзя будет называть, а размер первых шейдеров вообще очень сильно ограничивался возможностями видеокарт (это определялось наличием в ГПУ регистров для хранения обрабатываемых данных и установленным ограничением на число выполняемых инструкций).
А зачем им нужен специализированный язык? ГПУ имеет многочисленные внутренние специализированные потоковые процессоры с ограниченной функциональностью и упрощенной системой команд. Для потоковой обработки этого вполне достаточно. Это – компромисс между функциональностью, стоимостью и быстродействием, оптимальный на сегодня.
Но даже для небольшой игры может потребоваться написание большого числа шейдеров. Шейдеры группируются в логически связанные блоки, именуемые эффектами (“effects”). Дополнительную информацию по этому вопросу можно получить из документации к DirectX SDK.

Зачем нужны шейдеры? Конвейер и шейдерная модель

Было время, когда о шейдерах никто и не думал. Хорошее было время! Откуда же они свалились на нашу голову? Для того, чтобы понять это, надо знать, как работает современная видеокарта и графический процессор и как это было в то далекое время, когда дети, увидев морскую волну, не кричали радостно “Шейдеры! Шейдеры!”. Поэтому будет уместно сделать маленькое лирическое отступление от непосредственной темы DirectX и разобраться в этом. Я постарался максимально упростить технические детали, насколько это мне удалось – судить вам.

Попробуем упрощенно описать, как функционирует видеокарта. Тут удобно применить технологию “черного ящика”, широко используемую в автоматике. У ящика есть вход и выход, внутренняя функциональность нас интересует весьма приблизительно, причем не интересует, как это происходит на самом деле, а важно лишь то, как это видится снаружи “черного ящика”. Этим черным ящиком и будет выступать видеокарта. Мы должны узнать, что подается на вход, что является выходом и в общих чертах понять, что происходит внутри этого “черного ящика”.

Что является выходом, большинству сразу понятно – к видеокарте подключается монитор и то, что мы на нем видим, и есть выход. Пока будем считать, что так оно и есть, хотя это является истиной далеко не всегда – карта может работать ведомой в SLI или CF без монитора, видеокарта может производить неграфические вычисления и также не подключаться к монитору, выполняя полезную работу как сопроцессор к ЦПУ, либо часть процессорного времени ГПУ может отдаваться задачам, не связанным непосредственно с графикой.

Так что же подается на вход видеокарты? Смотря что видно сейчас на мониторе, если, конечно, видеокарта у нас работает как видеокарта, а не считает, к примеру физику или химию .
Допустим, программа должна выводить на экран трехмерный куб.
Как вообще можно описать куб математически? Способов существует много, но если речь идет о DirectX, то трехмерный объект представляется набором треугольников. Чтобы получился квадрат, нужно два треугольника а на шесть граней куба нужно уже 12 треугольников. Каждый треугольник имеет 3 вершины, поэтому всего нужно будет определить 36 вершин. Каждая вершина может быть представлена в виде трех чисел – ее координат в трехмерном пространстве. Область памяти, где хранится информация о вершинах объекта, называется вершинным буфером, или буфером вершин. Кому-то может показаться, что можно бы уложиться и в восемь вершин, и он будет не далек от истины, так как в действительности выборка может происходит по данным дополнительного индексного буфера, содержащего только индексы, привязанные к буферу вершин, а вершинный буфер может состоять только из уникальных координат, но эти нюансы мы здесь не рассматриваем. Координаты всех 36 вершин, одна за одной, непрерывным потоком, каждый кадр, поступают в видеокарту. Как правило, вершины имеют более сложный формат (хотя это и не обязательно), например, используются текстурные координаты для правильного наложения текстуры, вектор нормали, цвет и другие данные, но это выходит за рамки темы данной статьи.
Конечно, поток из 36 чисел за кадр – не нагрузка даже для самого древнего графического процессора, но более сложные объекты – игровые персонажи, окружающие предметы, природа могут содержать миллионы треугольников, и такой поток данных один или два потоковых процессора, имевшихся в наличии у старых видеокарт, уже не смогут обработать без катастрофического падения производительности. Поэтому число потоковых процессоров у видеоадаптеров, поддерживающих DirectX 9, измеряется десятками, а у нынешних топовых карт под DirectX 10 – сотнями. Без сомнения, скоро счет перейдет на тысячи, даже без учета объединения нескольких ГПУ на кристалле, плате видеокарты и в целом на материнской плате (а о кластерах даже думать не будем).

Таким образом, данные о вершинах хранятся в памяти, в буфере вершин, и периодически поступают на обработку в видеокарту. Что происходит с ними дальше – зависит от того, какую версию DirectX поддерживает видеокарта и какую версию DirectX поддерживает программа. Грамотное DirectX приложение при старте проверяет, удовлетворяют ли возможности видеокарты требованиям программы, и только при положительном ответе (после опроса системных данных) разрешает работу.
Итак, пока мы определились, что в видеокарту постоянно будет поступать информация из буфера вершин.

Теперь самое время обсудить, что такое “графический конвейер”. Тут – почти полная аналогия с заводским конвейером. От входа до выхода бежит лента транспортера, на которую поступают входные детали. И пока они на этой ленте направляются к концу конвейера, все, кто работает за конвейером, в соответствии с порученными технологическими операциями, производят соответствующие манипуляции, кто-то что-то привинчивает, или наоборот, отвинчивает, и в итоге начальную деталь вообще не узнать, ибо, как принято говорить, с конвейера уже сходит готовый продукт.

Представьте, что конвейер стал автоматизированным. Все операции выполняются роботами – станками и манипуляторами. Роботы запрограммированы раз и навсегда на выполнение конкретной операции в технологической цепочке. Если на транспортер конвейера ставили более мощный двигатель или рядом ставили еще один конвейер, оказывалось, что старые роботы уже сдерживают увеличение пропускной способности конвейера, независимо от числа линий. Поэтому в таких случаях каждый раз приходится менять роботов на более современных. Опять же, замена требовалась, если хотя бы чуть-чуть менялась технология обработки деталей.

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

Это несколько утрированное описание вполне можно отнести к конвейерам графических процессоров. Линии конвейера будут соответствовать потоковым процессорам, диспетчер – управляющее устройство ГПУ, программирование роботов — это выполнение программ-шейдеров, а если роботам добавить машинное зрение, обеспечить возможность выполнение любых технологических операций, используемых на производстве, поставить несколько дополнительный линий, возвращающих уже обработанные детали снова на вход конвейера (или отправляющих вообще на отдельный выход для обработки в соседнем цехе), то будет почти полная аналогия с универсальной шейдерной архитектурой.

Вернемся к вопросу, а что происходит дальше с данными вершин (в нашем примере – с координатами) в видеокарте? Как их связать с экраном монитора? Потихоньку мы доберемся и до монитора, но сейчас отметим, что то, как выглядит наш куб на мониторе, определяется не только координатами вершин треугольников, из которых складывается куб, но также и положением и ориентацией в пространстве наблюдателя (камеры), и параметрами самой камеры (угол поля зрения, формат кадра и т.д.). Поэтому должна быть возможность измерять координаты и угловую ориентацию объектов относительно общей точки отсчета, что даст возможность пересчитать положение и ориентацию любых трехмерных объектов относительно друг друга. Эти операции не очень сложные, но тем не менее требуют знания высшей математики, хотя при программировании таких задач можно полностью полагаться на известные приемы и алгоритмы, без необходимости изучения матричного исчисления (в профессиональных разработках обычно используется математика кватернионов, но, для простоты, в большинстве примеров программирования в DirectGraphics рассматриваются именно матричные операции).
Поскольку положение (то есть координаты) и ориентация (то есть углы поворота) наблюдателя (камеры) и технические параметры камеры определяют, что мы видим на мониторе, стоит задача – трансформировать 3D координаты вершин куба в 2D экранные координаты.
Для этого уже давно придумали формулы пересчета, и перевод из одной системы координат в другую это – умножение на мировую матрицу (определяющую положение в глобальной системе координат), матрицу вида (положение и ориентация наблюдателя) и матрицу проекции (с параметрами камеры).
Во времена, когда только появились первые специализированные графические процессоры, эту трансформацию координат выполнял процессор. Поскольку таких операций нужно делать много, то умножение матриц (обычно это можно оптимизировать до умножения вектора на матрицу) совокупно представляет собой весьма недешевую операцию и сильно загружает процессор. А поскольку это — операция рутинная и однородная, выполняющаяся над всеми вершинами всех объектов трехмерной сцены, то решено было разгрузить ЦПУ, переведя эти вычисления в ГПУ, на специализированный потоковый процессор, автоматически выполняющий такой пересчет.
Вот по такой логике и стали работать первые ГПУ с аппаратным блоком трансформации и освещения “T&L” (Transform And Lighting) — NVidia GeForce256. Чтобы не загромождать материал статьи, я не буду вдаваться в детали расчета освещения и отсылаю заинтересованных читателей к http://www.nvidia.com/object/transform_lighting.html

Отныне (но не навсегда!) аппаратная поддержка “T&L” стала символом высокой производительности видеокарт, это давало серьезную прибавку быстродействия программам и было поддержано всеми игроделами – вскоре все 3D игры для запуска стали требовать графического процессора с поддержкой “T&L”. И все бы было хорошо, но прогресс не стоит на месте. Поскольку логика трансформации “T&L” была жестко “зашита”в ГПУ (отсюда и произошло название – фиксированный конвейер), она сильно ограничивала и выравнивала выразительные возможности создаваемых программ, кроме того, жестко реализованная модель освещения во многих случаях была слишком примитивной для реализации красочных или реалистичных эффектов. Да и Microsoft добавляла что-то новенькое в DirectX только каждые год – полтора. Техника мультитекстурирования, некоторое время решавшая проблему и широко использовавшаяся в дошейдерную эпоху для придания “красивостей” игровым объектам, уперлась в пропускную способность видеопамяти – требовалось многократное чтение из текстурной памяти и многократное чтение-запись в буфер кадра. Было очевидно, что долго так продолжаться не сможет. И было предложено революционное решение, предопределившее стратегическое направление развитие графических процессоров на долгие годы — замена фиксированного конвейера на программируемый – вместо блока “T&L” появился блок потоковых процессоров, выполняющих обработку потока данных из вершинного буфера по программе вершинного шейдера. Блок мультитекстурирования сменил блок потоковых процессоров, выполняющих обработку потока данных (уже обработанных вершинным шейдером и прошедшими операции удаления невидимых и неотображаемых поверхностей), по программе пиксельного шейдера.
С выходом DirectX 8, определившим спецификацию новой технологии, появилась возможность относительно легко реализовывать любые модели освещения, произвольные трансформации и попиксельную обработку изображения (намного более гибкую и совершенную, чем появившуюся еще в DirectX 6 технику DOT3 с картами нормалей).

Новая эпоха шейдерного графического программирования принесла не только улучшение качества графики, но и головную боль программистам и покупателям видеокарт.

Программисты пострадали из-за того, что новый путь развития графического программирования был новаторским, зачастую методом проб и ошибок, что приводило к постоянным изменениям спецификации от Microsoft в DirectXGraphics и тем возможностям, которые предоставлял API и, следовательно, к появлению новых и новых видеокарт, каждая из которых требовала изменений в коде шейдера. При этом производители видеокарт не утруждали себя 100% воплощением возможностей API в железе, что не мешало им заявлять о полной поддержке DirectX. Особенно ярко это проявилось в DirectX 9 — появились версии 9a, 9b, 9c и различные варианты поддержки программирования шейдеров, что привело к понятию “шейдерная модель” (Shader Model, SM). Поддержка шейдерной модели означала поддержку в АPI специфических команд языка, на котором пишется шейдер, и наличие соответствующих регистров и возможностей обработки данных в видеокартах. Технические различия интересны только программистам, но пользователи стали теряться среди DirectX карт, поддерживающих SM1.0, 1.1,1.3,1.4, 2.0,2.0a, 2.0b. Плюс непонятные простым смертным аббревиатуры PS или VS рядом с этими цифрами.
Дело дошло до того, что шейдерные модели стали делиться на “для ATI” и “для Nvidia”.
Следующая шейдерная модель SM 3.0 положения со следованием стандарту не улучшила — например, ATI не стала подерживать карты смещения в вершинном шейдере, мотивируя это тем, что у Nvidia эта технология работает медленно и требует несколько десятков миллионов транзисторов на кристалле дополнительно. Вместо этого ATI предложила свой вариант рендеринга в буфер вершин, что опять потребовало от программистов создания еще нескольких программных заготовок.

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

Посочувствовав друг другу, давайте доведем поток данных по конвейеру до монитора.
После обработки по программе вершинного шейдера, происходит удаление всего того, чего не видит камера – зачем обрабатывать то, что никто не увидит? Но ничего не увидеть можно и по простой причине, если интересующий наш объект не попал в поле зрения камеры. Но если ракурс удачный, расстояние до нашего куба подобрано адекватно его размеру и камера правильно настроена, мы увидим наш куб во всей красе.
А как обеспечивается то, что в полноэкранном режиме куб будет выглядеть примерно одинаково на мониторе и при разрешении 640х480, и при 1024х768? Да очень просто. Растеризатор (блок ГПУ, который и отвечает за перевод 3Д картинки в 2Д), работает с внутренним представлением буфера, независимо от размера, имеющим диапазон по сторонам измерения -1.0..+1.0. Поэтому пересчет в абсолютные экранные пикселы, так, чтобы левый верхний угол выводимого изображения имел координаты (0,0), а правый нижний (639,479) или (1023,767) – это задача по арифметике для первого класса начальной школы.
Конечно, на самом деле растеризация – очень сложный и многоступенчатый процесс, и то, что обычно называют растеризацией, вовсе таковой не является по большому счету, но это вы можете проверить сами, прочитав соответствующие материалы, а начать, естественно, рекомендую с того же первоисточника – документации DirectX SDK, сайта Microsoft и есть масса монографий с такими математическими выкладками, которые вызывают стойкое и долговременное отвращение к любым математическим формулам.

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

Все вышеизложенное, для более сложной программы, требует сотен и тысяч строк кода (если, конечно, не пользоваться специальными фреймворками или высокоуровневым программированием), и приводится в движение волшебной командой Draw — Рисовать (как правило, их несколько на каждый кадр), которая используя многочисленные условия и договоренности, производит рендеринг (отрисовку) сцены в буфер кадра (ну или в какую — нибудь другую поверхность рендеринга, что в обоих случаях представляет собой выделенный участок видеопамяти).
В случае, если это – буфер кадра, нужно иметь в виду следующее. Как минимум, в DirectX для конкретной программы таких буферов будет два. Зачем? Потому что в процессе рисования объекты выбираются последовательно и новый объект может затирать информацию о предыдущем, если, к примеру, он его загораживает от камеры. Такая смена объектов, конечно, не заметна на глаз в деталях, но вот определенное мелькание и неприятные кратковременные “помехи” будут заметны. Поэтому, для того, чтобы от этого избавиться, применяется так называемая двойная буферизация. Создается два идентичных буфера кадра. Как только выполнены все команды Draw, по команде Present (Показать) происходит быстрое переключение адреса буфера, в котором формировалось изображение. Буфер, в который отрисовка закончилась, становится FrontBuffer (Передний Буфер) – областью памяти, которая уже формирует глобальный буфер кадра, который уже и поступает на монитор (если программа работает в полноэкранном режиме, то кадровый буфер программы и представляет собой глобальный буфер кадра). А буфер, который до этого был FrontBuffer, становится BackBuffer (Задний буфер) и в нем будет формироваться следующий кадр. Таким образом, рендеринг происходит все время в BackBuffer, а на монитор всегда идет изображение с FrontBuffer. Частота, с которой переключаются буферы кадра, определяет то число кадров в секунду, по которому судят об “играбельности” компьютерной игры и оно характеризует производительность графической подсистемы компьютера в данный фрейм. А если точнее, то в предшествующий. Но если уж совсем быть точным – то за некоторый период, зависящей от текущей 3D сцены, от объема видеопамяти и еще некоторых факторов. И в итоге это означает что это число характеризует совокупные аппаратные возможности компьютера при выполнении конкретной программы в конкретной операционной среде .

Может возникнуть вопрос, если на видеокарте, поддерживающей DirectX 9, запускается старая программа, написанная без шейдеров и требующая наличия блока “T&L”, как она выполняется, ведь современные карты уже не содержат аппаратного “T&L”? Очень просто. Драйвер видеокарты различает такую ситуацию и имеет для этих целей простейшие шейдеры с обработкой в стиле а-ля “T&L”, что обеспечивает полную совместимость со старыми приложениями.

Что дает пользователю компьютера очередная версия DirectX?

Теперь, когда мы знаем, что такое DirectX, попробуем разобраться, с точки зрения пользователя-непрограммиста, а что нам дает каждая новая версия DirectX?
Ответ однозначен – НИЧЕГО! DirectX – это одновременно и инструмент и потенциал, который надо раскрыть. Это должны сделать и разработчики программы (программисты, администраторы, художники, музыканты, дизайнеры) и программисты – драйверописатели.

Чтобы раскрыть такой потенциал, нужно немало усилий по изучению нового API и возможностей видеокарт, написанию и отладке кода и его оптимизации, постоянное отслеживание производительности десятков типов видеокарт под последними драйверами, часто вносящими хаос в уже отлаженный под предыдущий драйвер код, нужно умение и способность выкроить чуть – чуть ресурсов для создания нового эффекта, под который их нехватило в предыдущей версии движка под предыдущую версию API. иначе зачем новый API, если все-будет выглядеть по старому? И стоит только выкроить полмиллисекунды на кадр, ее тут же забирают под дополнительные полигоны в сцене, и начинается все сначала. Проходит время. Уже анонсирована следующая версия DirectX.
Это была история о программистах из деревни Виллабаджо.

А в это время в деревне Виллариба программисты под OpenGL радуются и веселятся – смена поколения видеокарт не принесла им никах проблем со сменой API, только лишь возросло быстродействие! И они только что сделали классную новую игру! И не хуже последней игры, выпущенной в деревне Виллабаджо под DirectX!

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

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

DirectX 10. Эволюционное обобщение пройденного

У Microsoft было достаточно времени – несколько лет, чтобы провести всесторонний тест выбранного направления развития графических API. И в самый расцвет DirectX 9 стало ясно, что продолжения не будет. В недрах подразделений R&D Microsoft рождалась новая операционная система. Первоначальные перемены названия преемника DirectX и кулуарные высказывания показывали, что DirectX 9 — это если не последний вариант DirectX вообще, то, по крайней мере, последний под Windows XP. Как оказалось, Microsoft все же не стала отказываться от брэнда DirectX и в новой Windows Vista увидела свет DirectX 10.

Конечно, смена поколения ОС – очень удобный повод железной рукой установить более жесткий порядок в плане следования выработанной спецификации (и тут мы всецело на стороне Microsoft). В этот период можно легко убрать те моменты, которые не устраивали, добавить то, чего не хватало и заложить резерв под будушие нужды. Но Microsoft поступила более радикально, бросив на XP тень полной бесперспективности, видимо с целью несколько ускорить естественный процесс отмирания прежних версий ОС. Ведь как бы ни уверяла Microsoft в том, что поддержка DirectX 10 настолько тесно интегрирована с ядром новой ОС, что никакая полноценная поддержка в Windows XP невозможна, очевидно, что изначально, помимо чисто технических целей улучшения (полного обновления) DirectX ставилась и цель, по чисто маркетинговым соображениям (чтобы поднять продажи ОС Vista), — получить техническую аргументацию в обосновании такой невозможности. На мой взгляд, виртуализация видеопамяти, переключение задач на ГПУ и унификация доступа к ресурсам, как наиболее влияющие на несовместимость факторы, и возникающие в связи с этим проблемы, вполне могли быть решены и в предыдущей версии ОС, если бы такая задача стояла (или, в худшем случае, была бы немного ограничена функциональность DirectX 10). По приведенной выше причине она, естественно, и не ставилась. Впрочем, это мое личное мнение, и оно может не совпадать с реальными намерениями Microsoft, но я не нашел доказательств обратному.

Гордо заявлено, что все написано с нуля. Хотелось бы спросить, а что, предыдущий опыт был отброшен? Наняты совершенно другие люди? Заведена дружба с разработчиками открытого графического ПО?
Нет, конечно. Первые описания и примеры работы с графической частью DirectX — Direct3D 10 появились публично еще в декабре 2005 года. Команда разработчиков кардинально не менялась. Более того, была сделана попытка ограничить полноценную поддержку OpenGL. Многие, кто был связан с этой темой, помнят размещенное в прошлом году объявление на первой странице официального сайта www.opengl.org , которое долгое время призывало всех оказать давление на Microsoft с целью недопустить дискредитацию OpenGL. Впрочем, эти нападки не новые, можно вспомнить и открытые письма грандов мировой игровой индустрии, направленные Microsoft (по аналогичному поводу!) и в 1997 году http://www.azillionmonkeys.com/windoze/OpenGLvsDirect3D.html .
Вообще, надо отметить, что Microsoft получает массу открытых писем ежегодно по всяческим поводам и без повода, так что ей не привыкать.
Впрочем, хватит лирики, раз приказано жить по новому, то вариантов у нас немного — значит, будем жить. Что же нового принес нам DirectX10 (и Vista) ?

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

Внедрена новая модель драйвера Windows Vista Display Driver Model (WDDM). Чем стала плоха старая модель WDM, использовавшаяся в прежних версиях Windows, можно узнать по ссылке:
http://www.microsoft.com/whdc/driver/wdf/wdf-intro.mspx
а вот все о новой модели WDDM:
http://msdn2.microsoft.com/en-us/library/ms797619.aspx

Краткий комментарий.
Произошла полная виртуализация графической памяти. Набирающая силу тенденция виртуализации всего и вся наконец-то добралась и до видеоподсистемы компьютера в полную силу. Чем же она так хороша? Да многим, и с точки зрения безопасности, и с точки зрения размера адресного пространства. Теперь каждому окну приложения выделяется собственная виртуальная память в размере полного экрана, собственный рендеринг (впрочем, WDM – Windows Display Manager трогать не будем). Разрешение экрана 1280х1024 потребует более 5Мб видеопамяти. 10 открытых приложений займет под 60 Мб. Без виртуализации, особенно на карте со 128Мб это называется приехали. Так что очень полезная штука.

Появилась возможность переключения задач на ГПУ. Теперь есть возможность прервать выполнение основной графической задачи и быстро выполнить в фоне, к примеру, расчет какого-нибудь физического взаимодействия объектов. Причем предоставляется возможность и прерывания выполнения работы над примитивом или посреди выполнения шейдера, если это поддерживается видеокартой (так как это не является требованием DirectX 10).

WDDM разрешает совместное использование поверхностей DirectX между процессами, тоже очень неплохо, что появилась официальная поддержка.
По модели драйвера вроде все, что относится к драйверописателям, не трогаем.

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

Если теперь производитель карты заверяет, что его видеокарта поддерживает DirectX 10, то этому уже, наверное, можно поверить. По новой спецификации, такая поддержка означает полное соответсвие API – все, что запрограммировано правильно, должно выполняться на любом DirectX 10 железе. Другое дело, что карты все равно разные и обеспечивают разные возможности. К примеру, Радеоны включили аппаратную тесселяцию, что скоро станет требованием DirectX, а видеокарты Nvidia 86хх имеют несколько аппаратных отличий, выгодно отличающих их (конечно, временно, до выхода нового поколения карт) от топовых решений 88хх (к примеру, это позволяет им обращаться к атомам в технологии CUDA, чего лишены их более старшие собратья, есть и другие преимущества. Впрочем, это вряд ли компенсирует владельцам этих карт банальный разрыв в быстродействии).

Появилась новая стадия в конвейере – стадия исполнения геометрического шейдера. Что можно интересного запрограммировать в коде геометрического шейдера? Как и вершинный шейдер, он на входе получает вершины и вершины же выдает на выход, но появляются существенные отличия. Входными данными уже являются не обезличенные вершины в потоке, а вершины примитивов, то есть вершины треугольника, линии или точки, а также соответствующие примыкающие вершины (три на треугольник и две на линию). В выходном потоке стадия геометрического шейдера может генерировать дополнительные вершины, образующие коллекцию вершин (point list), ломаную линию (line strip), либо группу связанных треугольников (tristrip).
Выходной поток вершин стадии геометрического шейдера может быть направлен, как входной поток, на стадию растеризации, либо в буфер памяти, и тогда он снова может являться входным источником вершин для стадии исполнения вершинного шейдера.

Безусловно, операция крайне процессороемкая (имея в виду ГПУ) в плане создания на лету высокополигональной геометрии (особенно, если делать ее за один присест).

Примеры работы геометрического шейдера владельцы видеокарт последних серий могут посмотреть, скачав свежие SDK на сайтах производителей своих видеокарт.

Шейдерная модель получила номер 4.0.
Программный язык написания шейдеров – только НLSL (хотя по-прежнему можно подключать внешний байт-код).

Произошла унификация подхода к используемым ресурсам – все ресурсы могут быть деривативами только от текстуры или буфера памяти.

Остальные отличия и нововедения, да, впрочем, как и большинство уже перечисленных, интересны только для программистов, которые эти новшества и так знают, всех интересующихся я отсылаю к документации по DirectX 10 SDK. Не думаю, что всем пользователям будут интересны сведения, звучащие как “в отличие от DirectX 9, теперь текстурные сэмплеры не ассоциированы с конкретной текстурой, а описывают применяемый к ресурсу метод фильтрации” или “DirectX 10 позволяет сократить ресурсоемкие операции смены состояния объекта Direct3D10, путем введения объектов состояния. Это особенно важно для организации обеспечения валидации объектов при их создании (а не при каждом использовании). Объекты состояния можно кэшировать в видеопамяти и в API — вызовах использовать хэндл на объект”.

Соответствуют ли изменения от DirectX 9 к DirectX 10 революционному обновлению? Мое скромное мнение – нет, это большой шаг вперед, но по значимости он не дотягивает до действительно революционного скачка от DirectX 7 к DirectX 8. Тем более очень интересная особенность – динамическая смена задач на ГПУ – не относится к DirectX.


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

Увы. Мое мнение такое. Самые новые игры под DirectX 9 напрягали соответствующие топовые видеокарты под завязку. Новые возможности API, теоретически давая очень интересный инструмент в руки разработчика, не позволят реализовать его полный потенциал на существующих топовых DirectX видеокартах (имеется в виду Nvidia 8800 и AMD 2900) так, чтобы это было играбельно.
То, что анонсируемые на этот год премьеры будут ориентированы на эти топы, понятно, но уровеь всеобщего ожидания и интерес к этим играм такой, что плохо быть сделанными они не имеют права. Значит, их будут делать хорошо, чтобы разница в передаче игровой атмосферы под DirectX 10 была бы заметна. При этом, чтобы обеспечить приемлимый фпс, наверняка частью красот придется пожертвовать. Миддл сектор в лице 8600 и 2600 отдыхает.

Что касается профессиональных применений, то они тоже более ориентированы на архитектуры будущих видеокарт. Нынешие топы прокладывают эту дорогу, и, по большому счету, не так уж они и плохи. Но быстротечен век любого компьютерного оборудования — и тут уж ничего не поделать.

Но есть и хорошие моменты.
Во-первых, это только мое личное мнение, и я очень хочу, чтобы оно оказалось ошибочным (у меня самого пара 8600GT).
Во-вторых, наверняка будет много игр, не выжимающих все из железа, но реализующих какие-нибудь интересные возможности DirectX 10.
В третьих, скоро подоспеет новый топ от Nvidia. Но я не говорил, что это хорошая новость для всех.

DirectX 10.1 Как же теперь жить? И пара слов об OGL

Вы можете спросить, а что появляется вперед – API или новое оборудование? Конечно, API определяет будущую архитектуру и первым появляется на рынке, но этот процесс итерационный и происходит путем консультаций специальной группы ведущих вендоров, безусловно с участием AMD и NVidia, с главенствующей ролью Microsoft, ибо решающее слово – за ней. С момента официального появления DirectX10 прошло уже достаточно времени для подготовки и анонса очередного изменения. И этот анонс Microsoft сделала на SIGGRAPH — DirectX 10.1 появится в Windows Vista SP1. Это получило широкий резонанс и обсуждение (люди, не разбирающиеся в этой технологии просто подняли панику, интерпретировав информацию таким образом, будто бы видеокарты только c поддержкой DirectX 10.0 уже ни на что не годны), а сделанное за четыре дня до этого заявление о релизе OpenGL 3.0, окончательный стандарт которго будет принят в конце сентября 2007 года, осталось практически незамеченным. С другой стороны, нельзя не отметить, что разработчики OpenGL всегда более взвешенно подходят к своим пользователям и более лояльно относятся к имеющемуся у них оборудованию.

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

Но вернемся к DirectX 10.1. Абсолютно ничего страшного не произошло, всего лишь мелкое эволюционное изменение, вполне соответствующее тем временным рамкам, которые были приняты между предыдущими обновлениями версий DirectX. Поскольку изменений не так много, я решил привести их все (хоть это и сугубо технические моменты), чтобы вы также смогли оценить размеры “катастрофы”.

Перевожу с английского, документация DirectX SDK за август 2007 года:

Direct3D 10.1 добавляет 3 новых API интерфейса. Они добавлены в Direct3D.1 DLL (D3D10_1.DLL и D3D10Core.dll), и будут доступны в Windows Vista Service Pack 1, а именно:
две новые функции D3D10CreateDevice1 и D3D10CreateDeviceAndSwapChain1 для создания интерфейса ID3D10Device1, который получил новые методы для создания интерфейса блендинга ID3D10BlendState1, поддерживающего независимые моды блендинга для каждой поверхности рендеринга и для создания интерфейса ID3D10ShaderResourceView1 c подержкой новых массивов кубических текстур (см. D3D10_TEXCUBE_ARRAY_SRV1).

Соответственно, появляется SM 4.1 для поддержки дополнительного метода работы с субресурсами и массивами кубических текстур.

Правда, к выходу Windows Vista Service Pack 1 список изменений может быть дополнен. Думается, что если бы Microsoft знала, какую волну подымет анонс и какой это найдет резонанс в среде технических дилетантов, она бы анонсировала его только вместе с выходом Windows Vista Service Pack 1, тем более, что всем кто следит за DirectX, о выходе версии DirectX 10.1 было известно давным-давно. Ни один разработчик не будет поддерживать DirectX 10.1 эксклюзивно, и если хочется поддерживать оба варианта, то никаких усилий для этого прикладывать не надо.

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

Все написанное автором выражает только его личную точку зрения, которая может не соотвествовать объективной реальности. Свою точку зрения (по любому вопросу) автор с радостью и благодарностью изменит, если найдет ваши аргументы убедительными. Эти аргументы, критику, предложения и любые мысли вслух, имеющие какое-нибудь отношение к рассматриваемым вопросам, можно изложить здесь

Двадцать лет спустя. Эволюция API Microsoft DirectX

Сегодня DirectX, разрабатываемый компанией Microsoft, уже воспринимается как должное. Все привыкли, что этот API является неотъемлемой частью Windows. Новая итерация «оси» под номером 10 не стала исключением. Еще осенью прошлого года Microsoft анонсировала двенадцатое поколение DirectX. Этому событию предшествовало пять лет почти полной тишины из стана Microsoft. Компания ограничивалась лишь плановыми обновлениями API, и никакой определенности насчет будущего DirectX не было. Масла в огонь подливало и то, что многие компании-разработчики в открытую поддерживали конкурирующую технологию OpenGL. В их число входила, например, компания Valve. Вдобавок ко всему, компания AMD представила свой низкоуровневый программный интерфейс Mantle, который должен был составить конкуренцию как OpenGL, так и DirectX. К счастью, Microsoft не вышла из игры, и все это время разработчики компании упорно трудились над созданием DirectX 12, который станет частью анонсированной в январе операционной системы Windows 10. Релиз «десятки» запланирован на ближайшую осень, а это значит, что уже в конце 2015 (либо в начале 2020) мы увидим первые игры, поддерживающие новый API.

Даже спустя столько лет первый Crysis по-прежнему хорош. А ведь это всего лишь DirectX 10

Чтобы немного скрасить время ожидания, мы предлагаем вам вспомнить, как создавался и развивался DirectX на протяжении последних 20 лет.

С чего все начиналось. DirectX 1.0

История появления DirectX берет свое начало в первой половине 1990-х годов, когда компания Microsoft занималась разработкой операционной системы Windows 95, которая должна была прийти на смену MS-DOS. Главным преимуществом MS-DOS было то, что она пользовалась популярностью у разработчиков игр. По мнению трех программистов Microsoft — Крэйга Эйслера (Craig Eisler), Алекса Сен-Джона (Alex St. John) и Эрика Энгстрома (Erik Engstrom) — даже после выхода Windows 95 многие разработчики могли отдать предпочтение MS-DOS как более подходящей для создания игр платформе. Чем же «дос» так нравился программистам? Все дело в том, что, программируя под MS-DOS, разработчики обращались напрямую к железу, то есть имели прямой доступ к видеокарте, клавиатуре, мыши, звуковым устройствам и другим частям системы. Подобный подход использовался в программировании под консоли, однако создание игр для компьютера осложнялось тем, что, в отличие от приставок, здесь не было фиксированной конфигурации системы. Это приходилось учитывать при написании кода, что значительно усложняло жизнь девелоперам.

Крэйг Эйслер — один из создателей DirectX

Так или иначе, но обращаться напрямую к аппаратной части компьютера в Windows 95 стало невозможно. Причиной этого была новая защищенная модель памяти, которая запретила прямой доступ к устройствам. Шел 1994 год, Windows 95 была на подходе, и Microsoft требовалось быстрое и эффективное решение возникшей проблемы. Им стал API DirectX, за создание которого отвечали как раз Эйслер, Сен-Джон и Энгстром. Релиз DirectX версии 1.0 состоялся 30 сентября 1995 года под названием Windows Games SDK.

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

DirectX 1.0 разрабатывался для Windows 95

Разработчики игр встретили DirectX довольно прохладно. Во-первых, они не были уверены, что Microsoft будет поддерживать API на протяжении долгого времени. Недоверие к Microsoft возросло после того, как компания свернула поддержку API WinG, который рассматривался как один из «помощников» в портировании игр с DOS на Windows. Во-вторых, «девяносто пятая» была требовательней к аппаратной части, из-за чего производительность в играх, как правило, снижалась в сравнении с MS-DOS. Ну и в-третьих — у DOS было огромное количество энтузиастов, которые ни в какую не хотели программировать под Windows.

Стоит сказать, что к моменту появления DirectX разработчикам игр уже был доступен API OpenGL, разработанный компанией Silicon Graphics Inc и представленный в 1992 году. Но в Microsoft решили пойти своим путем. В дальнейшем противостояние DirectX и OpenGL было похоже на битву Давида против Голиафа. Microsoft, прежде всего, брала своей финансовой мощью, а Silicon Graphics — репутацией и техническим опытом. Так, выбор в пользу OpenGL тогда сделал создатель Doom и Quake Джон Кармак (John Carmack). Он считал, что программный код DirectX слишком сложный для программирования, и поэтому в открытую поддерживал более «дружелюбный» интерфейс OpenGL. Конечно же, на планы Microsoft это никак не повлияло, но прохладная встреча DirectX со стороны разработчиков ясно дала понять, что работы у инженеров компании целый непочатый край.

Скриншот из игры Doom, за разработку которой отвечал Кармак

В роли догоняющего. DirectX 2.0 и далее

Следующее поколение API DirectX было представлено в середине 1996 года. Наконец-то в состав программного интерфейса были включены пакеты Direct3D и DirectPlay. С тех пор API состоял из следующих компонентов:

  • DirectDraw. Использовался для отрисовки двухмерной графики.
  • Direct3D (D3D). Использовался для отрисовки трехмерной картинки.
  • DirectPlay. Представлял собой сетевой программный интерфейс.
  • DirectInput. Использовался для обработки данных, поступающих с различных манипуляторов.
  • DirectX Media. Представлял собой набор API для работы с мультимедиа.
  • DirectMusic. Использовался для проигрывания музыки.
  • DirectSound. Использовался для записи и воспроизведения звука.
  • DirectSound3D. Предназначен для работы с пространственным звуком.
  • DirectX Media Objects. Потоковые объекты, такие как энкодеры, декодеры и эффекты.
  • DirectSetup. Отвечал за установку всех компонентов DirectX.

DirectX 2.0 предназначался для операционных систем Windows 95 и Windows NT 4.0. С момента выпуска первой ОС прошло совсем мало времени, поэтому для этой версии было выпущено очень мало игр. Microsoft воспользовалась моментом и начала активно продвигать API среди разработчиков. Ради этого во время конференции GDC в 1996 году Microsoft даже устроила специальное мероприятие, где представила некоторые новые возможности DirectX.

Вскоре после появления второго поколения API свет увидел и DirectX 3.0. Это случилось в сентябре 1996 года. Ближе к концу года были представлены дополнения в виде версий 3.0a и 3.0b. В сравнении со второй итерацией API третье поколения получило лишь незначительные изменения, которые так и не смогли повлиять на положение DirectX среди девелоперов.

Так выглядела картинка с применением DirectX 3.0

Немного исправить ситуацию получилось у DirectX 5.0, который появился в августе 1997 года. А что же случилось с четвертым поколением? Дело в том, что разработка 4-й и 5-й итераций API началась одновременно. DirectX 4.0 рассматривался как решение на самое ближайшее время. Оно не должно было привнести каких-либо кардинальных изменений в сравнении с версией 3.0 — только несколько новых «фич». В то же время пятая версия разрабатывалась с прицелом на перспективу. Однако разработчики не проявили интереса к новым возможностям DirectX 4.0, Microsoft свернула проект. Во избежание путаницы было решено пропустить версию 4.0 и сразу выпустить DirectX 5.0.

Главным достоинством пятой итерации DirectX стал намного упрощенный код. Писать программы с помощью API стало легче, и DirectX уже не вызывал у девелоперов такой неприязни, как поначалу. Главным же недостатком пятой «директрисы» было отсутствие поддержки технологии мультитекстурирования (multitexturing). Суть этой технологии заключается в наложении на грань сразу нескольких текстур за один проход. Но тут Microsoft улыбнулась удача. В то время алгоритмы мультитекстурирования были не столь эффективны, а железо — недостаточно производительным для того, чтобы применять технологию без ущерба для производительности. Чаще всего вместо нее разработчики использовали обычные многократные проходы, во время каждого из которых на грань накладывалась только одна текстура. Для девелоперов было важно, чтобы новые игры запускались и на старых машинах, поэтому в большинстве приложений мультитекстурирование не использовалось. Microsoft от этого лишь выиграла.

А это уже DirectX 5.0

Главный недостаток DirectX 5.0 был исправлен уже в следующем поколении API под логичным номером 6. Эта итерация DirectX появилась в августе 1998 года и вновь получила улучшения в области создания программ — код стал еще проще и еще понятнее. Также DirectX 6.0 мог похвастаться поддержкой мультитекстурирования. Но исправившись, Microsoft допустила очередную ошибку — новый API не поддерживал на аппаратном уровне технологию T&L (Transform and Lightning), которая предназначалась для обработки освещения и трансформации объектов в реальном времени. Как показало время, у Microsoft был еще год в запасе для реализации поддержки T&L. GeForce 256, первая видеокарта с движком T&L, появилась только в 1999 году. Кстати, начиная с этой версии, DirectX стал своего рода мультиплатформенным продуктом. Microsoft пыталась продвинуть свою операционную систему Windows CE для консолей и вместе с «осью» поставляла специальную версию DirectX 6. Однако эксперимент, скажем прямо, не удался.

Первая часть знаменитой серии Thief использовала DirectX 6.0

DirectX 7.0 был выпущен в сентябре 1999 года и исправил главный недостаток своего предшественника, получив поддержку технологии T&L на аппаратном уровне. Кроме этого, в рамках DirectX 7.0 Microsoft представила новый формат текстур с расширением .dds. Плюс новая версия API умела выделять вершинные буферы в видеопамяти. Это было первое существенное преимущество DirectX над OpenGL за все время существования API. И что важно, Microsoft продолжала гнуть свою линию по развитию мультитекстурирования. В этой области DirectX 7.0 также получил несколько новшеств, но написание кода для использования мультитекстурирования все еще было очень и очень непростой задачей даже для опытных девелоперов.

DirectX 7.0 в игре Midtown Madness 2

Великий перелом. DirectX 8.0 и 9.0

2001 год стал, пожалуй, переломным в истории развития DirectX. На протяжении предыдущих шести лет Microsoft находилась в роли догоняющих. И дело было даже не в конкуренции с OpenGL, за которым развитие DirectX худо-бедно успевало, а в седьмой итерации в чем-то даже и превзошло. DirectX сам по себе догонял всю индустрию. Microsoft создавала каждую версию API с оглядкой на архитектуру новейших видеокарт. В таком положении трудно было сделать по-настоящему большой шаг вперед и вырваться в лидеры. И это не устраивало компанию. Поэтому Microsoft наладила сотрудничество с NVIDIA, и DirectX 8.0 появился почти одновременно с видеокартами GeForce 3.

В восьмом поколении архитектура API претерпела значительные изменения и стала больше отличаться от таковой в OpenGL. В DirectX 8.0 появились пиксельные и вершинные шейдеры, что облегчило программистам создание различных спецэффектов. Сами шейдеры представляют собой подпрограммы, которые загружаются в видеокарту наравне с другими данными сцены. Затем драйвер преобразует эти подпрограммы в инструкции, понятные видеочипу. Кроме вершинных и пиксельных шейдеров, DirectX 8.0 мог похвастаться поддержкой тумана и таких технологий, как bump-mapping и texture-mapping (мультитекстурирование).

Помимо этого, Microsoft выделила компоненту DirectDraw, отвечающую за отрисовку двухмерной графики, в отдельный API. Также DirectX 8.0 все еще считался неудобным в использовании, но Microsoft постаралась исправить это в обновлении с индексом 8.1.

DirectX 8.1 в игре Max Payne 2: The Fall of Max Payne

Как итог, программисты наконец-то увидели перспективу в DirectX. Многие посчитали, что API от Microsoft на самом деле может стать будущим геймдева. Почему? Все потому, что программировать с помощью DirectX можно было с помощью обычного компьютера, в то время как для девелопмента под OpenGL необходима была рабочая станция. Вслед за NVIDIA свой взор на DirectX перенесла и ATI.

С выходом версии 8.1 API от Microsoft стал по-настоящему мультиплатформенным. Это произошло благодаря выходу первого поколения игровой консоли Xbox. Девелоперы получили специальный набор инструментов для платформ PC и Xbox, который значительно облегчил жизнь кроссплатформенным разработчикам. Конечно, была и обратная сторона медали: игрушки, написанные под Xbox и затем портированные на ПК, были зачастую неиграбельны из-за плохого управления.

С появлением DirectX 9.0 Microsoft лишь упрочила свои лидирующие позиции. Большинство разработчиков приняли девятое поколение API с распростертыми объятиями, а NVIDIA и ATI сконцентрировались на доработке драйверов для лучшей производительности рендеринга DirectX-приложений.

Far Cry и DirectX 9.0

Что касается технологических новшеств, то девятая итерация DirectX получила поддержку шейдерного языка высокого уровня HLSL (High Level Shader Language). Он не являлся обязательным, поэтому программисты могли самостоятельно писать низкоуровневый код для достижения максимальной производительности. Сами же пиксельные и вершинные шейдеры были обновлены до версии 2.0. Кроме этого, DirectX 9.0 получил поддержку технологии Multiple Render Targets (MRT), которая обеспечила одновременный рендеринг сразу в несколько цветовых буферов, а не в один, как было раньше. Также была добавлена поддержка технологии MET (Multiple-Element Textures) и стенсил-буфера (Stencil-buffer), который использовался при создании таких спецэффектов, как тени и отражения.

После выпуска девятой версии Microsoft не слишком торопилась с разработкой следующего поколения API. Если раньше каждая новая итерация DirectX выходила практически ежегодно, то теперь компания сделала ставку на плановые обновления. Поэтому в течение двух следующих лет свет увидели лишь дополнения DirectX 9.0 с литерами a, b и c. Основными их улучшениями были обновленные пиксельные и вершинные шейдеры. Так, DirectX 9.0a/b поддерживали Shader Model 2.0a/b соответственно, а самое крупное обновление — DirectX 9.0c — могло похвастаться не только Shader Model версии 3.0, но и поддержкой игровой консоли нового поколения Xbox 360.

DirectX 9.0c в стелс-экшене Splinter Cell

Удивительно, но DirectX 9.0c смог задержаться в компьютерах надолго. Виной всему — просчет Microsoft при выходе DirectX 10.

Неверный ход. DirectX 10

Следующее поколение DirectX было выпущено в ноябре 2006 года. Новый API поставлялся вместе с операционной системой Windows Vista, которая появилась в том же месяце. Состав DirectX претерпел некоторые изменения. Несколько компонентов были заменены. Так, DirectInput, отвечающий за обработку данных, поступающих с манипуляторов, уступил место пакету XInput, а DirectSound был упразднен в пользу системы Cross-Platform Audio Creation Tool (XACT), которая лишилась аппаратного ускорения аудио, поскольку рендеринг аудио в Windows Vista осуществлялся непосредственно на CPU.

Что касается нововведений, которые получил DirectX 10, в первую очередь нужно отметить новую версию шейдеров Shader Model 4.0, которая получила новые целочисленные инструкции и битовые операции. Кроме этого, добавилась поддержка дополнительных шейдеров, что позволило генерировать сложную геометрию полностью с помощью видеокарты. Подвергся изменениям и шейдерный компилятор HLSL, также получивший версию 4.0. Для улучшения производительности API было снижено число обрабатываемых команд на кадр, а также уменьшено время вызова функций. Был реализован и потоковый ввод/вывод, который позволил записывать результат работы вершинных и геометрических шейдеров напрямую в память.

Скриншот из игры Assassin’s Creed в режиме DirectX 10

Главным просчетом Microsoft было то, что DirectX 10 работал исключительно в операционной системе Windows Vista, вместе с которой он и был выпущен. Если раньше API Microsoft имел обратную совместимость с предыдущими версиями Windows, то теперь он был ее лишен. В итоге большинство игр разрабатывались в первую очередь с прицелом на DirectX 9.0c и операционную систему Windows XP, а поддержка DirectX 10 была лишь бонусом. По такому принципу разрабатывались, например, шутер Hellgate: London или стратегия Company of Heroes. Свою роль в провале DirectX 10 сыграло и то, что сама Windows Vista оказалась, пожалуй, самой неудачной «осью» в истории Windows.

В 2008 году Microsoft анонсировала обновление с индексом 10.1, которое стало доступно вместе с выходом Windows Vista SP1. Несмотря на то что DirectX 10.1 был всего лишь небольшим дополнением к API с индексом 10, он не поддерживался выпущенным на тот момент железом. Для DirectX 10.1 были необходимы новые видеокарты, которые, в свою очередь, сохраняли обратную совместимость с DirectX 10. В обновленном API были улучшены некоторые «фичи». Например, была обновлена шейдерная модель до версии 4.1, стали доступны независимые режимы блендинга для MRT и массивы кубических карт (cube map arrays). А несколько опциональных возможностей DirectX 10 стали обязательными в версии 10.1: например, 32-битная фильтрация и MSAA как минимум с четырьмя выборками (4x MSAA).

Сравнение DX9 с DX10

Работа над ошибками. DirectX 11

Выхода следующей версии API пришлось ждать почти два года. DirectX 11 был анонсирован еще на выставке Gamefest в 2008 году, но официальный релиз состоялся осенью 2009 года вместе с операционной системой Windows 7. Microsoft усвоила урок десятой версии API, поэтому 11-я итерация работала как с новой Windows 7, так и с Windows Vista.

Что касается новых возможностей, то в DirectX 11 в очередной раз была обновлена шейдерная модель, теперь до версии 5.0. Кроме этого, была улучшена производительность API в системах с многоядерными центральными процессорами. Все предыдущие версии разрабатывались с прицелом на одноядерные CPU. В конце концов, это стало своего рода бутылочным горлышком в производительности DirectX. Также в конвейер был добавлен вычислительный шейдер (Compute Shader) для поддержки программирования под задачи общего назначения. К примеру, всем известное быстрое преобразование Фурье работает через DirectX 11 намного быстрее, чем с помощью ранее применявшихся методов. Разработчики Microsoft также уделили внимание сжатию текстур, поэтому алгоритмы были значительно улучшены. Кстати, максимальный размер текстур также был увеличен с 4К до 16К. Но самым большим нововведением DirectX 11 стала поддержка тесселяции и переработанный конвейер визуализации, который был дополнен тремя новыми стадиями: hull-шейдером, domain-шейдером и непосредственно стадией тесселяции.

Суть тесселяции состоит в том, что по мере приближения низко детализированного объекта количество треугольников в его изображении экспоненциально увеличивается для получения более реалистичной и качественной картинки. Преимуществом метода является то, что среднее количество обрабатываемых треугольников всегда примерно одинаково, благодаря чему не происходят провалы в производительности. Особенно это актуально для игровых приставок, где изначально возможности железа ограничены.

Скриншот из шутера Crysis 2. Потрясающего качества картинки удалось достичь с помощью DirectX 11

Новшества, которые получил DirectX 11.1, вышедший в августе 2012 года для операционной системы Windows 8, были больше ориентированы на разработчиков, нежели на геймеров. Были добавлены новые команды копирования, защита от переполнения буфера, проверка на поддержку функций DirectX 11.1 со стороны видеочипов, а также отслеживание вычислений в шейдере. Вдобавок ко всему, в API была добавлена поддержка стереоскопического рендеринга. То есть отныне все игры, написанные с использованием DirectX 11.1, по умолчанию поддерживали трехмерный режим.

С выходом операционной системы Windows 8.1 DirectX также был обновлен до версии 11.2. Основными его улучшениями стали поддержка аппаратных оверлеев, компиляция и линковка шейдеров HLSL в рантайме, отображаемые в память буферы, API снижения задержек ввода и тайловые ресурсы. Среди этих возможностей, прежде всего, стоит выделить поддержку аппаратного оверлея. Он позволяет осуществлять рендер в буфер с низким разрешением, а затем увеличивать это изображение до необходимого размера и смешивать его с дополнительными буферами. Игра может отображать 3D-сцену в первом оверлее со сниженным качеством, но при этом другие графические элементы приложения могут отображаться с высоким качеством. К слову, оверлей может быть как статическим, так и динамическим. При статическом оверлее уровень масштабирования устанавливается при инициализации буфера и в дальнейшем не изменяется. В случае же использования динамического оверлея качество картинки может моментально изменяться без ущерба для производительности. В некоторых ситуациях это помогает избежать сильного падения производительности.

DirectX 11.3 и 12

На сегодняшний день DirectX 11.2 является самой свежей версией API от Microsoft. Что же ждет нас в ближайшем будущем? На эту осень запланирован запуск операционной системы Windows 10, а вместе с ней и DirectX 12. Главным отличием нового API от всех его предшественников стало снижение уровня абстрагирования оборудования. DirectX 12 предоставит иную модель программирования. Как говорят в Microsoft, приближенную к железу (closer to the metal). Используя такую модель, разработчики получат более широкий доступ к различным возможностям графического чипа. Кроме этого, DirectX 12 теперь поддерживает объекты состояния конвейера (PSO, pipeline-state object) и таблицы дескрипторов. Наконец, API получил новые возможности для конвейера рендеринга, которые значительно увеличивают производительность в таких алгоритмах, как определение коллизий, расчет прозрачности или геометрическая отбраковка.

Интересно то, что выход DirectX 12 не означает окончание жизненного цикла DirectX 11. Ближайшей осенью увидит свет еще одно дополнение под номером 11.3. При этом обновленный API позаимствует некоторые возможности у DirectX 12. Возникает вопрос: зачем Microsoft выпускать и поддерживать сразу два API? Ответ состоит в том, что двенадцатая итерация DirectX представляет собой низкоуровневую реализацию программного интерфейса. Для опытных девелоперов это, несомненно, большое преимущество, потому что такой подход позволит выжать максимум производительности и качества из «фишек» DirectX 12. С другой стороны, создавать приложения с помощью низкоуровневого API — задача не из простых. И многие программисты, в том числе и начинающие, предпочтут использовать более простую высокоуровневую модель DirectX 11.3. По этой причине Microsoft имеет смысл поддерживать развитие обоих API. По крайней мере, на первых порах.

Заключение

В сентябре нынешнего года DirectX исполнится ровно двадцать лет. За это время API прошел путь от уступающего конкурентам решения до роли ведущего программного интерфейса последнего десятилетия. Несмотря на локальные неудачи, Microsoft проделала огромный объем работы и напрямую повлияла на развитие геймдева и не только. Впереди нас ожидает инновационный DirectX 12, и будет очень интересно увидеть, какие новые графические возможности он сможет предложить.

Илон Маск рекомендует:  Что такое код flock
Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL