Рис. 4.2. Программа SuperSwitch

Отличия начинаются с того, что классы в этой программе называются SuperSwitchWin и SuperSwitchApp (вместо SwitchWin и SwitchApp). Класс SuperSwitchWin похож на SwitchWin, но в нем имеется несколько новых функций и переменных. Давайте посмотрим, что же изменилось. Объявление класса SuperSwitchWin приведено в листинге 4.6.

Класс SwitchWin

Давайте рассмотрим код программы Switch. Начнем с определения класса SwitchWin (см. листинг 4.2).

Следующие пять функций являются переопределенными версиями функций DirectDrawWin:

SelectDriver()

SelectInitialDisplayMode()

CreateCustomSurfaces()

DrawScene()

RestoreSurfaces()

С помощью функции SelectDriver() приложение выбирает используемое видеоустройство (если их несколько). Она полностью совпадает со стандартной версией, создаваемой AppWizard, и выводит меню при наличии нескольких драйверов. Функция SelectInitialDisplayMode() задает исходный видеорежим, устанавливаемый приложением. Здесь снова используется стандартная версия AppWizard, которая ищет видеорежим с параметрами 640x480x16.

Для многопоточного программирования Windows можно выбирать между классами MFC и потоковыми функциями Win32. Microsoft рекомендует использовать в MFC-приложениях классы потоков. Для работы с потоками в MFC предусмотрены следующие классы:

CWinThread

CMultiLock

Класс CWinThread представляет отдельный поток. Он присутствует во всех приложениях, потому что класс CWinApp (базовый для класса DirectDrawApp) является производным от CWinThread. Этот экземпляр класса CWinThread представляет основной поток приложения; чтобы добавить новые рабочие потоки, следует создать объекты CWinThread.

Класс CSyncObject

является виртуальным. Непосредственное создание экземпляров этого класса не разрешается; он существует лишь для того, чтобы обеспечивать функциональные возможности производных классов. Класс CSyncObject является базовым для классов CEvent, CCriticalSection, CMutex и CSemaphore. Объекты синхронизации, представленные этими классами, рассматривались в предыдущем разделе.

Классы CSingleLock и CMultiLock применяются для блокировки потоков по состоянию одного или нескольких событий. Класс CSingleLock блокирует поток до установки конкретного события, а CMultiLock— до установки одного или всех событий из заданного набора.

Позднее в этой главе мы воспользуемся классами CWinThread, CEvent, CCriticalSSection и CMultiLock.

Комбинированные приложения

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

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

Многопоточность

Когда все внимание сосредоточено на курсоре мыши, нетрудно забыть, что курсор— всего лишь часть нашего приложения. После появления курсора приложение не должно принципиально отличаться от рассмотренных выше, так что было бы нежелательно вставлять код ввода от мыши и обновления курсора в середину приложения. И даже если согласиться на это, как будет выглядеть этот код? Он должен постоянно проверять наличие новых данных от мыши. При обнаружении данных он обновляет курсор мыши; в противном случае продолжает свою нормальную работу. Постоянный опрос мыши замедлит приложение и усложнит его структуру. Более удачное решение — разделить приложение на две подзадачи, использовав многопоточность.

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

Начальные сведения

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

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

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

(streams). Этот термин говорит о том, что отдельные компоненты ролика (в случае видеоданных — растры) связаны между собой и следуют в определенном порядке. Термин «поток» часто встречается в последующих объяснениях.

Наглядное пояснение

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

Спрайты на рис. 9.1

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

Но что произойдет, если один из спрайтов сдвинется и его ограничивающий прямоугольник пересечется с другим? Теперь определить, произошло столкновение или нет, будет сложнее, потому что придется заниматься проверкой на уровне пикселей. Такая ситуация изображена на рис. 9.2.

Хотя спрайты на рис. 9.2

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

Рис. 9.1. Два несталкивающихся круглых спрайта

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

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

Рис. 9.2. Два спрайта, сталкивающиеся на уровне ограничивающих прямоугольников

Рис. 9.3.
Два спрайта, сталкивающиеся на уровне пикселей

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

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

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

Назначение классов

В реализации программы Bounce используется библиотека MFC, но без традиционной для нее архитектуры «документ/вид». Вместо этого используются классы MFC CWnd и CWinApp. Это позволяет устранить накладные расходы, связанные с архитектурой «документ/вид», и упростить приложение.

Поддержка DirectDraw сосредоточена в классах DirectDrawWin и DirectDrawApp, производных от CWnd и CWinApp соответственно. В свою очередь от DirectDrawWin и DirectDrawApp порождаются еще два класса. Эти классы (в приложении Bounce они называются BounceWin и BounceApp) обеспечивают функциональность, специфическую для конкретного приложения. На рис. 3.8 изображена иерархия этих шести классов вместе с базовыми классами MFC, используемыми в реализации CWnd и CWinApp.

Рис. 3.8. Иерархия классов в программе Bounce

Классы на рисунке соединены стрелками в соответствии с их наследственными связями. Класс CObject, лежащий в основании иерархического дерева, является базовым для всех остальных классов приложения. От него стрелки идут к классам более высокого уровня BounceWin и BounceApp.

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

Класс CObject является базовым для всех нетривиальных классов MFC. Он обеспечивает самые общие функции классов — операторы присваивания, поддержку сериализации и нестандартные версии операторов new и delete (для отладочных целей). Кроме того, класс CObject содержит виртуальный деструктор. Это гарантирует, что все классы, производные от CObject, будут правильно вести себя во время уничтожения независимо от типа используемого при этом указателя.

Поддержка схем сообщений (message maps) в MFC реализована в классе CCmdTarget, производном от CObject. Схемами сообщений называются макросы, которые ClassWizard включает в классы, чтобы реализовать обработку сообщений. Поскольку классы нашего приложения являются производными от CCmdTarget, для создания схем сообщений можно использовать ClassWizard.



Класс CWinThread используется в MFC для инкапсуляции функций программных потоков (execution thread). CWinThread применяется для написания многопоточных приложений, но в нашем случае он обеспечивает работу одного программного потока, необходимого для работы приложения.

Класс CWinApp, движущая сила всех приложений на базе MFC, использует CWinThread в качестве базового класса и добавляет в него свои функциональные возможности. С помощью поддержки потоков, унаследованной от CWinThread, CWinApp организует получение и доставку сообщений. Именно в нем заключен механизм доставки сообщений, управляющий работой всех Windows-программ. Класс CWinApp является базовым для класса DirectDrawApp, который расширяет поведение CWinApp возможностями, специфическими для DirectDraw. Класс DirectDrawApp управляет поведением приложений DirectDraw, инициализирует класс окна приложения, обновляет содержимое экрана и убирает «мусор» при завершении работы.

Класс CWnd представляет окна в MFC. CWnd - большой класс; он содержит сотни функций и может выполнять практически любую задачу, связанную с окнами. Мы используем класс CWnd в качестве базового для класса DirectDrawWin, дополняющего функциональные возможности CWnd спецификой DirectDraw. Классы, производные от DirectDrawWin, хорошо подходят для разработки приложений DirectDraw.

Не бойтесь плавающей точки

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

Нехватка видеопамяти

Нехватка видеопамяти становится очевидной после написания первого приложения DirectDraw. На большинстве новых видеокарт установлено 4 Мбайт памяти, но многие карты имеют лишь 2 Мбайт. Это прискорбно, потому что при использовании режимов High и True Color даже 4 Мбайт оказывается не так уж много.

С увеличением разрешения проблема становится еще острее. Например, режим 800x600x24 использует почти 2 Мбайт видеопамяти даже без вторичного буфера. В зависимости от объема установленной памяти можно рекомендовать использование различных видеорежимов, обеспечивающих хорошее быстродействие.

Использование видеопамяти следует тщательно продумать. Например, для видеокарт с памятью в 2 и 4 Мбайт можно использовать различные схемы распределения поверхностей. Если ваше приложение работает со множеством мелких поверхностей, попробуйте протестировать его и выяснить, какие поверхности используются чаще других. Часто используемые поверхности следует по возможности размещать в видеопамяти.

Когда свободная видеопамять кончается, поверхности создаются в системной памяти. Хотя системная память и обладает некоторыми преимуществами по сравнению с видеопамятью, быстродействие не относится к их числу. Некоторые видеокарты поддерживают передачу данных из системной памяти через DMA (Direct Memory Access, прямой доступ к памяти), но это временная мера, потому что в ближайшем будущем будет реализована спецификация шины AGP (Accelerated Graphics Port, ускоренный графический порт). AGP позволит видеокарте обращаться к системной памяти с минимальными потерями или без потерь производительности. Более того, AGP-видеокарта может вообще обходиться без видеопамяти и работать исключительно с системной памятью.

Спецификация AGP проектировалась в первую очередь для 3D-приложений, но поскольку библиотека Direct3D построена на базе DirectDraw (и использует DirectDraw для внутреннего распределения памяти), от новых возможностей AGP выигрывает и DirectDraw. К сожалению, для выхода новых аппаратных спецификаций на массовый рынок требуется немало времени. К тому же нет никаких гарантий, что AGP победит — какой-нибудь конструктивный просчет или отсутствие поддержки со стороны производителей может подорвать ее успех.

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

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

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

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

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

AddRef()

QueryInterface

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

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

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

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

Обнаружение видеорежимов

На следующем этапе необходимо определить все видеорежимы, поддерживаемые инициализированным драйвером DirectDraw. Для перечисления видеорежимов используется функция EnumDisplayModes(), аналогичная рассмотренной выше функции DirectDrawEnumerate(). В обоих случаях для перечисления используются косвенно вызываемые функции, а также предоставляются средства для передачи им данных, определяемых приложением. В нашем случае DisplayModeAvailable() является функцией косвенного вызова (callback function), а указатель this ссылается на произвольные данные. Функция DisplayModeAvailable() выглядит так:

DirectDraw вызывает функцию DisplayModeAvailable() для каждого поддерживаемого видеорежима. Структура DDSURFACEDESC, передаваемая косвенно вызываемой функции, содержит описание обнаруженного видеорежима. Функция DisplayModeAvailable() сохраняет разрешение экрана и глубину пикселей в специальном массиве, называемом displaymode. В переменной total displaymodes хранится количество обнаруженных видеорежимов; если значение totaldisplaymodes достигает MAXDISPLAYMODES, перечисление завершается возвратом кода DDENUMRET_CANCEL.

Затем функция OnCreate() сортирует элементы displaymode так, чтобы режимы с низким разрешением находились в начале массива. Это делается с помощью функции Win32 qsort(), которой передается функция косвенного вызова для «сравнения» видеорежимов. В нашем случае используется функция CompareModes(), которая сравнивает видеорежимы сначала по разрешению, а затем по глубине пикселей. Я пропускаю дальнейшее обсуждение CompareModes(), потому что оно не имеет никакого отношения к DirectDraw.

Обнаружение видеорежимов и частот смены кадров

Обновление курсора

Итак, курсор мыши должен обновляться прямо на первичной поверхности. При очередном перемещении курсора необходимо выполнить два действия:

Стереть курсор в старом месте.

Нарисовать курсор в новом месте.

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

Восстановить фоновое изображение в старом месте.

Сохранить часть изображения в новом месте.

Нарисовать курсор в новом месте.

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

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

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

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

Скопировать объединение старой и новой областей курсора на вспомогательную поверхность.



Стереть старый курсор на вспомогательной поверхности.

Сохранить фоновое изображение, занятое новой областью курсора.

Нарисовать новый курсор на вспомогательной поверхности.

Скопировать содержимое вспомогательной поверхности на первичную поверхность.


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

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

Обработка пользовательского ввода

При запуске программы Switch текст в нижней части меню подсказывает, какие клавиши управляют работой приложения. Клавиши со стрелками изменяют текущий выделенный видеорежим, клавиша Enter активизирует его (если он не является текущим), а клавиша Escape завершает работу программы. Все эти клавиши обрабатываются функцией OnKeyDown(), создаваемой ClassWizard. Ее код приведен в листинге 4.5.

Листинг 4.5. Функция SwitchWin::OnKeyDown()

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

Давайте посмотрим, как в нашей программе организована обработка ввода. Нажатые клавиши обрабатываются функций OnKeyDown(), которая выглядит так:

Остальные восемь функций, вызываемых функцией OnKeyDown(), изменяют положение поверхности во время прокрутки:

Up()

PageDown()

Каждая из этих функций определяет положение поверхности по значениям переменных x, y, xlimit, ylimit, xscroll и yscroll. Код всех восьми функций приведен в листинге 5.9.

Листинг 5.9. Функции смещения поверхности

В программе AviPlay ввод не играет особой роли. Программа реагирует всего на три клавиши, причем одинаково. Ввод с клавиатуры обрабатывается функцией OnKeyDown():

Общее решение

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

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

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

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

Оконные приложения

Все приложения DirectDraw делятся на два основных типа: оконные (windowed) и полноэкранные (full-screen). Оконное приложение DirectDraw выглядит, как обычная Windows-программа. О полноэкранных приложениях речь пойдет ниже.

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

Оконные приложения содержат первичную поверхность, однако не могут выполнять «настоящее» переключение страниц. Кроме того, первичная поверхность не соответствует клиентской области окна (то есть области, расположенной внутри рамки). Вместо этого первичная поверхность изображает весь рабочий стол. Это означает, что ваша программа должна следить за расположением окна и его размерами, чтобы графика выводилась в нужном месте. Другими словами, оконное приложение DirectDraw может рисовать на всем рабочем столе.

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

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

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

Другая проблема, характерная для оконных приложений, - отсечение. Хорошо написанное приложение должно иметь объект отсечения, присоединенный к первичной поверхности. При этом снижается быстродействие программы, потому что каждую операцию блиттинга приходится выполнять в нескольких мелких прямоугольных областях, в соответствии со списком областей отсечения. Кроме того, не удается использовать оптимизированную функцию BltFast(). Блиттинг приходится выполнять с помощью медленной (и громоздкой) функции Blt().

Наконец, в оконных приложениях не удается полностью управлять содержимым палитры. Так как Windows резервирует 20 элементов палитры, можно задать лишь 236 из 256 возможных цветов. Зарезервированные цвета занимают первые и последние 10 элементов системной палитры. Следовательно, на долю палитровых изображений остаются лишь 236 «средних» цветов.

Определение класса

В программе BmpView, как и в других программах этой книги, класс окна приложения является производным от класса DirectDrawWin. К сожалению, по нашему соглашению об именах имя производного класса образуется из имени приложения и суффикса Win. Следовательно, класс окна приложения BmpView называется BmpViewWin, что выглядит несколько неуклюже. Объявление класса BmpViewWin приведено в листинге 5.5.

OnKeyDown()

OnDestroy()

Функция OnKeyDonw() обрабатывает нажатия нескольких клавиш, среди которых клавиши со стрелками, Home, End, Page Up, Page Down, Enter, пробел и Escape.

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

Опросы и оповещения

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

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

Организация доступа к поверхностям

В наших программах чтением BMP-файлов занимается класс DirectDrawWin. Впервые эта возможность была использована в главе 3, где в программе Bounce BMP-файл загружался на поверхность. То же самое происходит и в программе BmpView, но сначала давайте рассмотрим соответствующий программный код.

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

Ошибка переключения режимов DirectDraw

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

Проблемы возникают при активизации видеорежимов, которые отличаются по глубине пикселей от текущего активного режима Windows. Например, если Windows работает в 8-битном видеорежиме, а ваше приложение DirectDraw попытается активизировать 16-битный видеорежим, ничего не получится, даже когда новый режим вполне допустим. Если попытаться установить 8-битный видеорежим при 16-битном режиме Windows, результат будет тем же. В таких случаях DirectX выдает отладочное сообщение следующего вида:

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

Такой обходной маневр нетрудно реализовать с помощью класса DirectDrawWin, представленного в этой книге. В функции SelectInitialDisplayMode()

(которая вызывается до переключения видеорежима) следует проверить глубину пикселей текущего режима. Если она отличается от требуемой, выполните «фиктивное» переключение. Программа может выглядеть так:

Основной поток

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

создание и запуск потока ввода;

обновление курсора перед каждым переключением страниц;

синхронизацию с потоком ввода;

завершение потока ввода.

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

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

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

Наконец, основной поток должен предупредить поток ввода о завершении приложения. Помните— поток ввода работает независимо от основного потока. Без извещения со стороны основного потока он не будет знать о том, что приложение собирается завершиться. Кроме того, основной поток не может просто остановить работу потока ввода; поток ввода должен завершиться сам при получении сигнала завершения от основного потока.

Отладка

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

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

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

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

Об ошибках и способах отладки написаны многие тома. Особенно ценной я считаю книгу «Writing Solid Code» Стива Магуайра (Steve Maguire) (Microsoft Press, ISBN 1-55615-551-4). Если вы не читали ее ранее, обязательно прочтите. В этом приложении мы ограничимся проблемами и способами отладки, которые относятся к полноэкранным приложениям DirectDraw.

Отладочные макросы

VisualC++ (как и многие другие среды разработки) содержит макросы, предназначенные специально для отладки. Например, макросы TRACE(), ASSERT() и VERIFY()

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

Макрос TRACE()

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

в отличие от двух других нормально работает в полноэкранных приложениях DirectDraw, так что вы можете свободно пользоваться им (этот макрос регулярно встречается в программах на CD-ROM).

Макросы ASSERT() и VERIFY()

очень похожи друг на друга, что часто приводит к недоразумениям. На самом деле между ними существует очень важное различие. В отладочных версиях макросы ASSERT() и VERIFY() работают одинаково. Оба макроса вычисляют выражение, переданное им в качестве аргумента, и прекращают работу программы с выводом сообщения в том случае, если это выражение оказывается равным нулю. Отличие заключается в том, что в окончательной версии макрос ASSERT() вместе с вычисляемым выражением полностью удаляется из кода. С другой стороны, выражение макроса VERIFY() остается в программе. Макрос ASSERT() предназначен для проверки состояния переменных, а VERIFY() — для проверки функций. Выражение макроса ASSERT()

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



Использование макросов ASSERT() и VERIFY()

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

При таких затруднениях у вас есть два варианта: отказаться от ASSERT() и VERIFY()

или предоставить нестандартные версии, работающие в DirectDraw. Второй вариант предпочтительнее, и, как выясняется, он реализуется достаточно просто.

Если покопаться в заголовочных файлах MFC, вы увидите, что в отладочном режиме макрос ASSERT() определяется так:

Отладочные сообщения DirectX

Вероятно, вы уже заметили, что при запуске приложений DirectX в окне вывода отладчика VisualC++ появляются диагностические сообщения. По умолчанию отладочные версии компонентов DirectX сообщают таким образом о важных внутренних событиях — например, об ошибках. Типичное окно вывода для приложения DirectDraw изображено на рис. А.10.

СОВЕТ

Прислушивайтесь к крикам DirectX

При установке runtime-части DirectX на рабочий компьютер возникает искушение установить окончательные версии DLL вместо отладочных (во время инсталляции вам предлагается выбрать нужный вариант). Не поддавайтесь соблазну и не устанавливайте окончательные версии! Да, они действительно работают чуть быстрее, и именно с ними будут работать пользователи вашего приложения, но при этом вы лишитесь отладочного вывода. Если во время работы над программой возникнут проблемы, вы так и не узнаете, что же DirectX пытается вам сказать.

Рис. А.10. Типичное окно вывода в отладчике

Возможно, вы не знаете, что детальность этих сообщений тоже можно изменять. В каждой из библиотек DirectDraw, Direct3D и DirectSound можно выбрать пять разных уровней отладочных сообщений. Чтобы настроить уровень отладочных сообщений, выберите значок DirectX в Control Panel и перейдите на вкладку нужного компонента DirectX. Диалоговое окно DirectX Properties с выбранной вкладкой DirectDraw изображено на рис. А.11.

Рис. А.11. Окно DirectX Properties (запускается из Control Panel)

Для библиотеки DirectDraw нажмите кнопку Advanced Settings — откроется окно DirectDraw Advanced Settings. Нужный уровень отладочных сообщений устанавливается с помощью слайдера Debug Level. Окно DirectDraw Advanced Settings изображено на рис. А.12.

Рис. А.12. Окно DirectDraw Advanced Settings

При максимальном уровне отладки каждое приложение DirectDraw, запущенное в отладчике, выдает весьма обширный и подробный протокол. Вывод протокола снижает быстродействие программы, так что максимальный уровень не стоит держать включенным постоянно.
С другой стороны, он сильно помогает в затяжной борьбе с DirectDraw. Чтобы показать, насколько подробная информация выдается при максимальном уровне отладки, я приведу отладочный протокол для небольшого полноэкранного приложения DirectDraw. Обратите внимание на то, что листинг раскрывает некоторые внутренние тонкости работы DirectDraw. Подробный отладочный протокол приведен в листинге А.1.

Листинг А.1. Подробный отладочный протокол DirectDraw

Отсечение

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

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

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

Оверлейные функции

Поддержка оверлеев в DirectDrawSurface представлена следующими функциями:

AddOverlayDirtyRect()

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

Функция UpdateOverlayDisplay() обновляет изображение с учетом новых значений параметров. Данная функция может обновить все изображение оверлея или ограничиться его прямоугольными областями, заданными функцией AddOverlayDirtyRect(). Наконец, функция EnumOverlayZOrders() используется для перебора оверлеев в порядке их Z-координаты (Z-координата определяет, какие оверлеи выводятся поверх других). Возможен перебор как в прямом порядке (от передних оверлеев к задним), так и в обратном (от задних — к передним).

Палитра

Палитра в BMP-файлах хранится в виде списка структур RGBQUAD, где каждый элемент представляет отдельный цвет. Структура RGBQUAD объявляется так:

Палитры

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

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

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

Передача графических данных

Как видно из функции CreateSurface(), передача графических данных BMP-файла на поверхность осуществляется функцией Copy_Bmp_Surface(). Функция Copy_Bmp_Surface() пользуется услугами четырех вспомогательных функций, каждая из которых специализируется на пикселях определенной глубины. Код Copy_Bmp_Surface() выглядит так:

Переключение страниц

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

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

Построить новый кадр во вторичном буфере.

Сохранить область вторичного буфера, где должен находиться курсор.

Нарисовать курсор на вторичном буфере.

Выполнить переключение страниц.

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

Переключение видеорежимов

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

Переменные формата пикселей в классе DirectDrawWin

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

loREDbit

numBLUEbits

Как вы убедитесь при изучении кода для работы с беспалитровыми поверхностями, эти переменные оказываются очень удобными.

Перестановка кресел на «Титанике»

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

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

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

Поддерживаемые устройства

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

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

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

Подготовка инструментов

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

Windows NT или Windows 95

Runtime-файлы DirectX

DirectX SDK

Visual C++ 5.0

Скорее всего, операционная система Windows NT или Windows 95 уже установлена на вашем компьютере. Если вы пользуетесь Windows NT, понадобится версия 4.0 или выше (желательно с установленным Service Pack 3); для Windows 95 подойдет любая версия. Три оставшиеся строки из списка мы рассмотрим немного подробнее.

Подготовка поверхностей

Последняя функция, вызываемая в ActivateDisplayMode() (см. листинг 3.2), — CreateCustomSurfaces(). Эта функция является чисто виртуальной, поэтому классы, производные от DirectDrawWin, должны реализовать ее. Функция CreateCustomSurfaces() создает вспомогательные поверхности, а также инициализирует переменные и структуры данных. В классе BounceWin эта функция выглядит так:

В приложении Bounce используется одна вспомогательная поверхность, содержимое которой определяется одним из двух BMP-файлов: 8- или 24-битным. Функция использует 8-битный файл, если текущий видеорежим является 8-битным, и 24-битный файл — в противном случае. В принципе один и тот же BMP-файл можно использовать в обоих сценариях, но это неразумно. Поскольку 8-битные файлы могут состоять лишь из 256 цветов, не стоит использовать их в режимах High и True Color. В свою очередь 24-битные изображения не пользуются палитрами и могут содержать до 16 миллионов цветов. Генерация 256-цветной палитры для такого изображения становится нетривиальной задачей. Функция CreateCustomSurfaces() определяет глубину пикселей текущего видеорежима с помощью функции DirectDrawWin::GetCurDisplayDepth(). На основании полученного результата выбирается имя BMP-файла.

Затем мы проверяем указатель surf1. Если его значение отлично от нуля, поверхность освобождается, а указатель обнуляется. Это происходит из-за того, что функция CreateCustomSurfaces() может вызываться неоднократно. Функция ActivateDisplayMode() вызывает ее при активизации видеорежима, поэтому приложение, которое за время работы меняет несколько видеорежимов, несколько раз вызовет CreateCustomSurfaces(). Если поверхность создавалась ранее, приведенный код освобождает ее.

Затем мы вызываем функцию CreateSurface(), чтобы создать поверхность и загрузить в нее содержимое BMP-файла. Функция CreateSurface() есть в интерфейсе DirectDrawSurface, но в данном случае используется версия из класса DirectDrawWin. Функция CreateSurface() загружает BMP-файл и создает поверхность, размеры и содержимое которой определяются изображением, хранящимся в заданном BMP-файле. CreateSurface() возвращает указатель на созданную поверхность, если все прошло нормально, и ноль — в противном случае.

Обратите внимание на то, что функция CreateSurface() получает два аргумента. Первый из них представляет собой имя загружаемого BMP-файла. Второй аргумент показывает, нужно ли устанавливать палитру BMP-файла. Для 24-битных BMP-файлов этот аргумент игнорируется.

Полезные хлопоты с палитрами

Не так давно в высокопроизводительных графических приложениях можно было сколько-нибудь приемлемо работать, лишь используя 8-битные режимы. Так как 8-битные режимы являются палитровыми, палитры были неотъемлемой частью жизни; программист был вынужден либо пользоваться ими, либо отказаться от попыток создания высокопроизводительных графических приложений.

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

И все же перед тем, как выбрасывать поддержку 8-битных режимов из своего приложения, подумайте о преимуществах палитровых видеорежимов. 8-битные режимы очень трудно превзойти в области быстродействия. Они используют вдвое меньше памяти по сравнению с режимами High color и вчетверо меньше — по сравнению с True Color. Меньшие затраты означают увеличение свободной видеопамяти, а это в свою очередь ведет к повышению быстродействия.

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

Полноэкранные приложения

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

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

Так как полноэкранные приложения не ограничиваются текущим видеорежимом Windows, проблема с наличием свободной видеопамяти становится менее серьезной. При наличии всего 2 Мбайт видеопамяти можно сэкономить память за счет установки видеорежима с низким разрешением. Если будет обнаружено 4 Мбайт видеопамяти, ваше приложение сможет выбрать более требовательный видеорежим и при этом обеспечить хорошее быстродействие.

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

Получение данных о формате пикселей

Сведения о формате пикселей поверхности можно получить функцией GetPixelFormat() интерфейса DirectDrawSurface, в которой для передачи данных используется структура DDPIXELFORMAT. Функция GetPixelFormat() применяется так:

dwRGBBitCount

dwBBitMask

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

Таблица 5.1. Типичные данные формата для 16-битных пикселей

Рассчитанные значения облегчают операции с пикселями. Стартовый бит показывает, на сколько позиций сдвигаются данные цветовой составляющей, а количество — сколько бит занимает составляющая в двоичной величине.

Таблица 5.2. Типичные данные формата для 16-битных пикселей

Получение данных от мыши

Хлопоты с инициализацией мыши и клавиатуры закончены, теперь можно получать от них данные. Функция DrawScene() (см. листинг 6.6) через указатели mouse и keyboard обращается к обоим устройствам и получает от них данные.

Каждый элемент буфера представлен структурой DIDEVICEOBJECTDATA. Эта структура используется независимо от типа устройства, поэтому ее поля были сделаны универсальными. DirectInput определяет структуру DIDEVICEOBJECTDATA следующим образом:

DIMOFS_X

DIMOFS_BUTTON3

Программа Smear реагирует только на перемещение мыши по осям x и y, поэтому после вызова функции GetDeviceData() поле dwOfs сравнивается с константами DIMOFS_X и DIMOFS_Y.



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

Поля dwTimeStamp и dwSequence содержат информацию о том, когда произошло данное событие. Поле dwTimeStamp определяет время в миллисекундах (о том, как интерпретируется эта величина, можно подробно узнать в описании функции Win32 GetTickCount()). Поле dwSequence определяет порядок наступления событий. События с меньшими номерами наступили раньше, однако несколько событий могут иметь одинаковые порядковые номера. Например, если мышь или рукоять джойстика смещается по диагонали, события для координат x и y будут иметь одинаковые номера.

Вернемся к функции DrawScene(). Цикл ввода извлекает элементы буфера до тех пор, пока буфер не опустеет. Этот цикл выглядит так:

Получение списка драйверов DirectDraw

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

Функция DirectDrawEnumerate() получает два аргумента: указатель на косвенно вызываемую (callback) функцию и указатель на данные, определяемые приложением, которые передаются этой функции при вызове. В нашем случае аргументами являются косвенно вызываемая функция DriverAvailable() и указатель на класс DirectDrawWin (this). Функция DriverAvailable() определяется так:

Сначала указатель на данные, определяемые приложением (p), преобразуется в указатель на класс DirectDrawWin (win). Поскольку функция DriverAvailable() объявлена как статическая (косвенно вызываемые функции обязаны быть статическими), на нее в отличие от обычных функций класса не распространяются правила автоматического доступа; соответственно доступ к переменным и функциям класса приходится осуществлять через указатель win.

DirectDraw вызывает функцию DriverAvailable() один раз для каждого обнаруженного драйвера. При каждом вызове передаются три информационных объекта: GUID, описание и имя. GUID (глобально-уникальный идентификатор) однозначно идентифицирует драйвер. Описание и имя представляют собой строки для неформальной идентификации драйвера. Функция DriverAvailable() сохраняет сведения о каждом драйвере в массиве с именем driver и отслеживает количество драйверов в переменной totaldrivers. Наконец, функция DriverAvailable() возвращает DDNUMRET_OK, показывая, что перечисление драйверов должно продолжаться. При получении кода возврата DDENUMRET_CANCEL DirectDraw прекращает перечисление драйверов.

Если была установлена библиотека DirectX и в системе присутствует видеоустройство, поддерживаемое DirectDraw, то будет обнаружен по крайней мере один драйвер DirectDraw. Этот драйвер соответствует первичному видеоустройству (тому, что используется Windows). Его GUID равен нулю, строка описания содержит текст «Primary Display Driver», а строка имени — «display». При перечислении дополнительных драйверов используются нормальные значения GUID. Строки описаний и имен зависят от типов видеоустройств и версий драйверов.

Поток ввода

Поток ввода обладает более узкой специализацией по сравнению с основным потоком. Он должен делать следующее:

обнаруживать ввод от мыши;

обновлять курсор;

синхронизироваться с основным потоком;

обрабатывать сигнал завершения, полученный от основного потока.

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

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

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

Потоки и процессы

Сознаете вы это или нет, но вы уже знакомы с потоками и процессами. Каждый раз при запуске программы создается новый процесс. Процесс обеспечивает программу всем, что ей нужно для работы, включая один поток (thread). Этот стандартный поток (также называемый основным потоком — primary thread) используется для выполнения кода программы. Основной поток типичного процесса начинает работу с точки входа (для Windows-программ это функция WinMain()) и продолжает выполняться в соответствии со всеми циклами, условными операторами и вызовами функций. Основной поток завершается вместе с завершением процесса.

Однако ничто не ограничивает процесс одним потоком. Средства MFC или Win32 позволяют создавать дополнительные потоки, которые обычно используются для выполнения фоновых задач. Эти дополнительные потоки (иногда называемые рабочими потоками) работают независимо от основного потока (а также друг от друга). Каждый поток обладает собственным стеком, но системные ресурсы (такие, как файлы и динамическая память) используются потоками совместно.

Поверхности

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

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

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

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

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

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

особенно начинающие) любят задавать вопросы

Представление данных в видеофайлах

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

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

Кадры видеоролика с полным изображением называются ключевыми кадрами

(key frames). Видеоролик может содержать любое количество ключевых кадров, в зависимости от того, насколько часто и сильно меняется изображение. Ключевые кадры особенно часто появляются при переходах между сценами, эффектах «растворения» и перемещении съемочной камеры. Ключевые кадры чрезвычайно важны при чтении видеоролика; без них промежуточные кадры теряют смысл. Неключевой кадр тоже можно вывести, но изображение, скорее всего, будет нарушено, потому что такой кадр представляет собой лишь изменение предыдущего изображения, а не самостоятельное изображение.

Открытый видеофайл обычно называется потоком. Как мы увидим в следующем разделе, посвященном Video For Windows API, концепция потока тесно интегрирована с Video For Windows.

Прекомпилированные заголовки

Лично я— горячий поклонник прекомпилированных заголовков. Настроить их нетрудно, а компиляция проектов Visual C++ проходит намного быстрее обычного. Если вам придется компилировать большой проект без прекомпилированных заголовков, то к концу компиляции вы успеете забыть, что же именно изменилось в вашей программе.

Одна из разрекламированных особенностей Visual C++, которую я ждал с особым нетерпением, — возможность задания параметров проекта из пользовательских AppWizard. Это позволило бы мне написать AppWizard, который помимо генерации исходных текстов мог бы настраивать конфигурацию новых проектов. Особенно сильно я рассчитывал на настройку и включение прекомпилированных заголовков.

Такая возможность была предусмотрена для стандартного MFC AppWizard из комплекта Visual C++; впрочем, она присутствовала и в предыдущих версиях. После нововведений в Visual C++ 5.0 то же самое могут (теоретически) сделать и разработчики нестандартных AppWizard.

Первая проблема состоит в том, что справка, документирующая эту новую возможность, была написана для Visual Basic и потому оказалась практически бесполезной для программистов на C++ (несомненно, мы имеем дело с побочным эффектом многоязыковой ориентации Developer Studio). Вторая проблема — в том, что (в соответствии с документацией) уровень доступа, необходимый для оптимальной конфигурации прекомпилированных заголовков, вам не предоставляется. Выяснилось, что с проектами можно работать на уровне конфигураций, но не на уровне файлов. До меня доходили слухи, что такая возможность все-таки есть, но она не документирована; однако мои поиски в заголовочных файлах ни к чему не привели.

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

А. Информация для разработчиков

Отладка

Несколько замечаний о VisualC++

Полезные советы

Microsoft и DirectX SDK

Ответы на вопросы

Вот и все - книга подходит к концу. Однако наше внимание было настолько приковано к DirectDraw (и DirectInput), что некоторые важные темы так и не были рассмотрены. Например, в DirectDraw есть несколько досадных недочетов, о которых необходимо знать (если вы еще не успели столкнуться с ними). Свои недостатки есть и у Visual C++. Кроме того, некоторые особенности программного кода на CD-ROM могут представлять для вас интерес. Во время работы над программами я отобрал ряд полезных советов. Наконец, у меня есть несколько общих замечаний, которые не удалось привязать к основному тексту. Все эти темы рассматриваются в приложении.

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

Проблемы

Отладить полноэкранное приложение намного сложнее, чем любое другое, и для этого есть несколько причин. Самая очевидная из них— раз приложение занимает весь экран, вы не сможете изменить точки прерывания, просмотреть код программы или значения переменных. Дело усложняется переключением страниц. Если программа должна вывести проверочное сообщение или отладочное окно, нельзя гарантировать, что оно действительно появится на экране, потому что Windows может вывести информацию во вторичном буфере. И даже если вам повезет и вы сможете увидеть это окно (при использовании буферизации ваши шансы — 50 на 50), вероятно, его все равно не удастся толком разглядеть из-за различий между текущей и системной палитрой.

Следовательно, многие традиционные механизмы и методики отладки не работают для DirectDraw. Интегрированный отладчик Visual C++ практически бесполезен, а пользоваться стандартными отладочными макросами типа ASSERT() или VERIFY() оказывается рискованно.

Проблемы с диалоговыми окнами

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

организовать переключение страниц и управление палитрами, чтобы обеспечить правильное отображение диалоговых окон Windows;

восстанавливать рабочий стол каждый раз, когда потребуется вывести диалоговое окно;

создать нестандартное диалоговое окно и управляющие элементы DirectDraw.

В первом варианте вам придется самостоятельно управлять переключением страниц и палитрами с учетом Windows GDI. GDI не поддерживает DirectDraw, так что независимо от того, какая страница видеопамяти отображается в данный момент, диалоговые окна GDI всегда выводятся на «настоящей» первичной поверхности, или поверхности GDI. В беспалитровых режимах вывод GDI выглядит правильно и без вмешательства с вашей стороны, но в палитровых режимах отсутствие поддержки DirectDraw в GDI дает о себе знать — GDI продолжает выводить диалоговые окна в системной палитре Windows, не подозревая о том, что в данный момент может действовать другая палитра. Решение зависит от требований, предъявляемых приложением к палитре.

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

Пора браться за программирование. Программу AviPlay, как и все остальные программы, рассматриваемые в этой книге, можно найти на CD-ROM.

Программа AviPlay использует Video For Windows для открытия и воспроизведения AVI-файлов на поверхностях DirectDraw. Она позволяет выбрать любой AVI-файл и задать видеорежим для воспроизведения ролика. Диалоговое окно для выбора файла изображено на рис.8.1.

Рис. 8.1. Диалоговое окно для выбора AVI-файла в программе AviPlay

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

Кроме того, программа не пытается управлять частотой вывода кадров; все кадры извлекаются и воспроизводятся с максимальной скоростью. В каждом AVI-файле присутствуют хронометрические данные, которые используются всеми полноценными программами для воспроизведения AVI-файлов.

Еще одна полезная возможность, которая бы пригодилась в программе AviPlay, — поддержка 16- и 24-битных видеорежимов. В представленном варианте всегда применяются 8-битные режимы независимо от глубины пикселей воспроизводимого ролика.

Программа BmpView

На основе полученных знаний мы напишем приложение DirectDraw для просмотра BMP-файлов. Программа BmpView отображает диалоговое окно, в котором пользователь выбирает BMP-файл. Затем она выводит список всех видеорежимов, пригодных для просмотра выбранного изображения. Если выбрать видеорежим и нажать кнопку Display, программа BmpView переходит в заданный режим и отображает содержимое BMP-файла. Если изображение не помещается на экране, его можно прокрутить с помощью клавиш стрелок, Home, End, Page Up и Page Down. Диалоговое окно для выбора файла изображено на рис. 5.7.

Рис. 5.7. Диалоговое окно для выбора файла в программе BmpView

Обратите внимание на то, что в диалоговом окне отображаются размеры выбранного файла, а глубина пикселей определяет, какие видеорежимы могут использоваться для его отображения. На рисунке выбрано 8-битное изображение, поэтому в список включены только 8-битные режимы. Если выбрать 24-битное изображение, то список состоял бы только из беспалитровых режимов.

Наше знакомство с программой BmpView затрагивает следующие вопросы:

загрузка изображений из BMP-файлов;

прямой доступ к памяти поверхности;

прокрутка больших поверхностей;

работа с диалоговыми окнами Windows в DirectDraw.

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

Программа Bumper

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

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