• DDOVERLAYFX
• DDPIXELFORMAT
• DDSURFACEDESC
• DDSCAPS
• DDBLTBATCH
• DDCOLORKEY
С некоторыми из этих структур мы уже встречались. Например, структура DDCOLORKEY упоминалась при обсуждении функции SetColorKey() интерфейса DirectDrawSurface. В настоящем разделе мы не станем детально рассматривать каждую структуру, а вместо этого разберемся с одной особенностью DirectDraw, которая способна причинить немало бед, если о ней забыть.
Пять (точнее, первые пять) из восьми перечисленных структур содержат поле с именем dwSize, в котором хранится размер структуры. Присвоение значения этому полю лежит на вашей ответственности. Более того, все функции DirectDraw, получающие эти структуры в качестве аргументов, не смогут работать, если полю dwSize не будет присвоено правильное значение.
Например, фрагмент для работы со структурой DDSURFACEDESC может выглядеть так:
DDSURFACEDESC surfdesc;
surfdesc.dwSize = sizeof(surfdesc);
surf->GetSurfaceDesc(&surfdesc);
Сначала мы объявляем структуру, затем присваиваем полю dwSize значение, используя функцию sizeof(). После этого структура передается функции GetSurfaceDesc() интерфейса DirectDrawSurface. Если забыть присвоить значение полю dwSize, вызов функции закончится неудачей.
На первый взгляд это выглядит глупо. С какой радости DirectDraw настаивает на передаче размера структуры, в ней же и определенной? Причина, по которой эти пять структур содержат поле dwSize, состоит в том, что в будущем они могут измениться. DirectDraw будет проверять размер структуры и по нему определять ее версию. Сейчас DirectDraw требует передачи правильного размера, чтобы приучить к этому разработчиков. Позднее это окупится, поскольку дальнейшие версии DirectDraw смогут корректно работать со старыми программами DirectDraw.
Раз уж речь зашла о структурах, следует упомянуть, что перед использованием структур желательно заполнять их нулями. В этом случае предыдущий фрагмент будет выглядеть так:
DDSURFACEDESC surfdesc;
ZeroMemory(&surfdesc, sizeof(surfdesc));
surfdesc.dwSize = sizeof(surfdesc);
surf->GetSurfaceDesc(&surfdesc);
Функция Win32 ZeroMemory() заполняет нулями область памяти, начало которой передается в качестве первого аргумента. Второй аргумент функции определяет размер инициализируемой области. Преимущество такого подхода состоит в том, что теперь можно выяснить, какие поля структуры изменились в результате вызова функции GetSurfaceDesc(). Если не инициализировать структуру, случайные значения в ее полях можно принять за величины, занесенные в нее DirectDraw.
Создание приложений DirectDraw
После знакомства с DirectDraw API мы поговорим о том, как эта библиотека используется для создания готовых приложений. В этом разделе рассматриваются некоторые общие принципы построения приложений DirectDraw.
Все приложения DirectDraw делятся на два основных типа: оконные (windowed) и полноэкранные (full-screen). Оконное приложение DirectDraw выглядит, как обычная Windows-программа. О полноэкранных приложениях речь пойдет ниже.
В оконных приложениях присутствуют интерфейсные элементы, знакомые нам по традиционным Windows-приложениям, — рамка, строка заголовка и меню. Поскольку оконные приложения DirectDraw отображаются на рабочем столе вместе с окнами остальных приложений, они вынуждены использовать видеорежим (разрешение экрана и глубину пикселей), установленный в Windows в настоящий момент.
Оконные приложения содержат первичную поверхность, однако не могут выполнять «настоящее» переключение страниц. Кроме того, первичная поверхность не соответствует клиентской области окна (то есть области, расположенной внутри рамки). Вместо этого первичная поверхность изображает весь рабочий стол. Это означает, что ваша программа должна следить за расположением окна и его размерами, чтобы графика выводилась в нужном месте. Другими словами, оконное приложение DirectDraw может рисовать на всем рабочем столе.
Так как переключение страниц запрещено, изображения приходится копировать на первичную поверхность из внеэкранных буферов. Это увеличивает вероятность расхождения, потому что блиттинг происходит медленнее, чем переключение страниц. Чтобы избежать расхождения, приходится синхронизировать блиттинг со сменой кадров на мониторе.
Оконные приложения хорошо работают в том случае, если в видеопамяти удается разместить внеэкранный буфер для клиентской области окна. В этом случае содержимое окна можно построить на внеэкранной поверхности, а затем быстро скопировать на первичную поверхность с применением аппаратного ускорения.
Когда нехватка памяти заставляет вас создавать внеэкранные буфера в системной памяти, быстродействие заметно падает. К сожалению, эта ситуация встречается очень часто, особенно для видеокарт с памятью объемом 2 Мбайт, потому что для рабочего стола Windows большинство пользователей выбирает режимы с высоким разрешением. Например, в режиме 1024×768×16 только для первичной поверхности требуется почти 2 Мбайт памяти. При наличии только 2 Мбайт видеопамяти для внеэкранных поверхностей остается слишком мало места.
Другая проблема, характерная для оконных приложений, - отсечение. Хорошо написанное приложение должно иметь объект отсечения, присоединенный к первичной поверхности. При этом снижается быстродействие программы, потому что каждую операцию блиттинга приходится выполнять в нескольких мелких прямоугольных областях, в соответствии со списком областей отсечения. Кроме того, не удается использовать оптимизированную функцию BltFast(). Блиттинг приходится выполнять с помощью медленной (и громоздкой) функции Blt().
Наконец, в оконных приложениях не удается полностью управлять содержимым палитры. Так как Windows резервирует 20 элементов палитры, можно задать лишь 236 из 256 возможных цветов. Зарезервированные цвета занимают первые и последние 10 элементов системной палитры. Следовательно, на долю палитровых изображений остаются лишь 236 «средних» цветов.
В полноэкранном режиме приложение DirectDraw получает исключительные права на работу с видеоустройствами. Полноэкранное приложение может свободно выбрать любой из режимов, поддерживаемых видеокартой, и управлять содержимым всей палитры. Кроме того, полноэкранные приложения могут выполнять переключение страниц. Благодаря этим преимуществам полноэкранные приложения превосходят оконные по скорости и гибкости.
Работа типичного полноэкранного приложения начинается с определения допустимых видеорежимов и активизации одного из них. Затем приложение создает переключаемую первичную поверхность с одним или несколькими вторичными буферами, а оставшуюся видеопамять использует для создания внеэкранных поверхностей. После истощения видеопамяти используется системная память. Подготовив очередной кадр во вторичном буфере, приложение выполняет операцию переключения страниц. Даже если первичная поверхность занимает всю доступную видеопамять, полноэкранные приложения опережают своих оконных собратьев благодаря способности к «настоящему» переключению страниц.
Так как полноэкранные приложения не ограничиваются текущим видеорежимом Windows, проблема с наличием свободной видеопамяти становится менее серьезной. При наличии всего 2 Мбайт видеопамяти можно сэкономить память за счет установки видеорежима с низким разрешением. Если будет обнаружено 4 Мбайт видеопамяти, ваше приложение сможет выбрать более требовательный видеорежим и при этом обеспечить хорошее быстродействие.
Полный контроль над содержимым палитры тоже оказывается полезным. Вы можете использовать все 256 элементов палитры и обойтись без переназначения цветов, обусловленного наличием 20 зарезервированных цветов Windows.
Комбинированным называется приложение, которое может работать как в полноэкранном, так и в оконном режимах. Обычно комбинированные приложения довольно сложно устроены, но зато они предоставляют разумный компромисс. Пользователь может запустить приложение в оконном режиме, а если оно будет работать слишком медленно — перейти в полноэкранный режим.
Оптимальный подход к созданию комбинированного приложения заключается в написании нестандартной библиотеки с функциями, работающими независимо от выбранного режима (полноэкранного или оконного). Впрочем, эта книга посвящена программированию для DirectDraw, а не написанию библиотек, поэтому комбинированные приложения в ней не рассматриваются.
Подготовка инструментов
После такой основательной (хотя и несколько поспешной) теоретической лекции можно переходить к практическим вопросам. Перед тем как заняться изучением программ, имеющихся на CD-ROM, или написанием собственных приложений DirectDraw, необходимо подготовить инструментарий. Вам потребуются четыре отдельных программных компонента:
• Windows NT или Windows 95
