«Графика для Windows средствами DirectDraw»

«Графика для Windows средствами DirectDraw» Стэн Трухильо

Посвящается Стэнли и Велме Коппок (моим дедушке и бабушке по материнской линии), а также Дж. Д. и Марии Трухильо (дедушке и бабушке по отцовской линии). Их общество и поддержка радовали меня в детстве и продолжают радовать сейчас.

Предисловие

Программисты (особенно начинающие) любят задавать вопросы типа: «Скажи, на чем ты пишешь…?» Когда-то этот вопрос выглядел вполне логично.

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

Сегодня стал актуальным другой вопрос: «А чего стоишь ты сам?» Благодаря непрерывной конкуренции современные средства разработчика стали невероятно мощными и качественными, так что среднему программисту вряд ли удастся выжать из них все возможное. Скорее всего, вы спасуете намного раньше, чем ваш инструментарий — если только не узнаете о нем абсолютно все и не доведете свое мастерство программиста до подлинного совершенства.

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

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

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

Джефф Дантеманн

Введение

Засидевшись допоздна над своей предыдущей книгой, «Cutting-Edge Direct3D Programming», я решил ложиться спать. Оказалось, что та же самая мысль пришла в голову здоровенному пауку-каракурту. Что еще хуже, для этого нами была выбрана одна и та же кровать. Мы мирно улеглись, не подозревая о присутствии друг друга (во всяком случае, я ничего не подозревал).

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

И мне, и пауку пришлось пожалеть о встрече. Пауку — потому что он был жестоко раздавлен своей разгневанной и удивленной жертвой. Мне — потому что у врача я оказался лишь через восемь часов после укуса (а серьезные мышечные спазмы начинаются через 2–4 часа). После нескольких посещений местной амбулатории проблема была решена. Этой ночью я так и не спал, и к тому же в течение восьми часов мучался от жуткой боли. В довершение всего перед вводом противоядия меня накачали валиумом. Разумеется, о работе не могло быть и речи.

При первой возможности я позвонил своему редактору, Скотту Палмеру (Scott Palmer). Заплетающимся языком я рассказал, что немного задержусь с очередной главой, потому что меня укусил каракурт. Скотт проявил полное понимание, и мы перенесли срок сдачи материала.

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

Скотт заверил меня, что он никогда не сомневался в моей искренности, а в список включил сразу все оправдания, независимо от того, поверил он или нет. Тем не менее полагаю, его позиция вполне ясна.

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

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

Другими словами, Coriolis отвечает за распространение и продажу книги, однако за содержащийся в ней материал отвечаю я. Следовательно, если у вас возникнут какие-либо вопросы по поводу программ или CD-ROM, не стесняйтесь и пишите мне. Некоторые читатели обращаются в Coriolis, но издательство все равно просто пересылает почту мне. Если вы захотите обратиться ко мне, обязательно укажите, о какой книге идет речь, и постарайтесь сделать свои вопросы и замечания по возможности конкретными. Со мной можно связаться по адресу mailto:stan@rezio.com.

Кроме того, некоторые вопросы встречаются особенно часто. Я собираюсь создать и вести список ЧаВО (часто задаваемых вопросов) на Web-узле этой книги (). Здесь вы найдете ответы на некоторые вопросы, а также исправления ошибок, обновления и, возможно — даже новые демонстрационные программы.

Для чего написана эта книга

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

Эта книга начинается с того, на чем другие книги обычно заканчивались. Мы поговорим об основах DirectDraw, но лишь в общих чертах. Читатель — опытный программист, но незнакомый с DirectDraw — сможет с ходу войти в курс дела. Затем мы перейдем к другим темам, столь же интересным, сколь и полезным.

Цель этой книги — научить вас работать с DirectDraw, а не предоставить некоторую «структурную основу» или нестандартный API, который бы выполнял за вас всю работу. Демонстрационные программы написаны на C++ и используют MFC, но совсем не для того, чтобы скрыть все технические подробности. С++ и MFC — превосходные инструменты, потому что с их помощью любое приложение можно написать несколькими разными способами. Примеры для этой книги были написаны так, чтобы при этом получались структурированные и удобные для чтения проекты, которые наглядно показывают, что и почему происходит в программе.

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

Требования к читателю

Эта книга научит вас почти всему, что можно узнать о DirectDraw. Тем не менее она не учит C, C++, MFC или работе с Developer Studio пакетов семейства Visual — предполагается, что вы уже знакомы с этими темами. С другой стороны, от вас не требуется никаких выдающихся познаний. Например, мы будем использовать MFC, но лишь в объеме, необходимом для написания наших приложений. Следовательно, чтобы читать эту книгу, вовсе не обязательно быть экспертом в MFC.

Программные требования

Для работы с книгой необходимо иметь Windows NT 4.0 или Windows 95. Кроме того, потребуется Visual C++ 5.0 или более поздней версии.

Вам также понадобится собственно DirectX версии 3a или выше (желательно DirectX 5). Учтите, что DirectX распространяется в двух видах: в runtime-варианте и в SDK. Runtime-вариант часто устанавливается программами, использующими DirectX, он также встроен в операционную систему Windows NT 4.0. На CD-ROM этой книги содержатся runtime-компоненты DirectX 5. С другой стороны, пакет DirectX SDK необходим для компиляции программ, написанных для DirectX. Он отсутствует на CD-ROM этой книги, однако его можно бесплатно скачать по адресу: .

Аппаратные требования

Вам потребуется компьютер с процессором Pentium и выше. Под Windows NT необходимо иметь 32 Мбайт RAM, а под Windows 95 — не менее 16 Мбайт. Общий принцип остается прежним — чем больше, тем лучше. Также потребуется дисковод CD-ROM.

Наконец, понадобится видеокарта, поддерживаемая библиотекой DirectDraw (на данный момент DirectDraw поддерживают практически все современные видеокарты).

Пора заняться делом. Начнем с краткого курса DirectDraw.

Глава 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()

• QueryInterface

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

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

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

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

GUID

Чтобы обратиться к объекту с запросом о поддержке некоторого интерфейса, используя функцию 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-объектов. Доступ к каждому объекту осуществляется через один или несколько интерфейсов. Вот их полный список:

• DirectDraw

• DirectDraw2

• DirectDrawSurface

• DirectDrawSurface2

• DirectDrawSurface3

• DirectDrawPalette

• DirectDrawClipper

Мы рассмотрим все интерфейсы вместе с входящими в них функциями. Тем не менее этот раздел не претендует на то, чтобы заменить собой справочное руководство. 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 (в алфавитном порядке):

• Compact()

• CreateClipper()

• CreatePalette()

• CreateSurface()

• DuplicateSurface()

• EnumDisplayModes()

• EnumSurfaces()

• FlipToGDISurface()

• GetAvailableVidMem()

• GetCaps()

• GetDisplayMode()

• GetFourCCCodes()

• GetGDISurface()

• GetMonitorFrequency()

• GetScanLine()

• GetVerticalBlankStatus()

• RestoreDisplayMode()

• SetCooperativeLevel()

• SetDisplayMode()

• WaitForVerticalBlank()

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

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

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

• CreateClipper()

• CreatePalette()

• CreateSurface()

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

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

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

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

Функция GetCaps()

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

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

СОВЕТ

DirectX Viewer

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

Функция SetCooperativeLevel()

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

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

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

• EnumDisplayModes()

• GetDisplayMode()

• RestoreDisplayMode()

• SetDisplayMode()

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

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

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

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

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

• DuplicateSurface()

• EnumSurfaces()

• FlipToGDISurface()

• GetGDISurface()

• GetAvailableVidMem()

• Compact()

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

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

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

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

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

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

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

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

• GetMonitorFrequency()

• GetScanLine()

• GetVerticalBlankStatus()

• WaitForVerticalBlank()

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

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

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

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

Функция GetFourCCCodes()

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

Интерфейсы DirectDrawSurface  

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

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

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

• AddAttachedSurface()

• AddOverlayDirtyRect()

• Blt()

• BltBatch()

• BltFast()

• DeleteAttachedSurface()

• EnumAttachedSurfaces()

• EnumOverlayZOrders

• Flip

• GetAttachedSurface()

• GetBltStatus()

• GetCaps()

• GetClipper()

• GetColorKey()

• GetDC()

• GetDDInterface()

• GetFlipStatus()

• GetOverlayPosition()

• GetPalette()

• GetPixelFormat()

• GetSurfaceDesc()

• IsLost()

• Lock()

• PageLock()

• PageUnlock()

• ReleaseDC()

• Restore()

• SetClipper()

• SetColorKey()

• SetOverlayPosition()

• SetPalette()

• SetSurfaceDesc()

• Unlock()

• UpdateOverlay()

• UpdateOverlayDisplay()

• UpdateOverlayZOrder()

Функции описания поверхностей

Мы начнем с четырех функций, с помощью которых можно получить информацию о самой поверхности:

• GetCaps()

• GetPixelFormat()

• GetSurfaceDesc()

• SetSurfaceDesc()

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

Функция GetPixelFormat() особенно важна при работе с поверхностями форматов High и True Color, поскольку формат пикселей может зависеть от видеокарты. Функция возвращает маски, которые определяют способ хранения отдельных цветовых составляющих.

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

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

Функции блиттинга

Интерфейс DirectDrawSurface поддерживает три функции, предназначенные для выполнения блиттинга:

• Blt()

• BltBatch()

• BltFast()

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

Функция BltBatch() не реализована в DirectX 5 (ее можно вызвать, но при этом ничего не произойдет). После реализации эта функция будет выполнять сразу несколько операций блиттинга, по возможности одновременно.

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

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

Функция Flip()

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

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

Функции определения состояния поверхностей

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

• GetBltStatus()

• GetFlipStatus()

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

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

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

Интерфейс DirectDraw содержит две функции для назначения и просмотра цветового ключа (или интервала цветовых ключей) поверхности:

• GetColorKey()

• SetColorKey()

По умолчанию поверхность не имеет цветового ключа. Чаще всего цветовой ключ представляет собой один цвет, однако на некоторых видеокартах возможна работа с интервалами цветовых ключей. Цветовые ключи и их интервалы описываются структурой DDCOLORKEY. Указатели на эту структуру передаются функциям GetColorKey() и SetColorKey() в качестве аргументов. Функции GetColorKey() и SetColorKey() используются при частичном копировании поверхностей, а также при выполнении операций с цветовыми ключами приемника.

Функции Lock() и Unlock()

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

• Unlock()

• Lock()

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

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

Заблокированную поверхность невозможно заблокировать снова. Попытка вызова функции Lock() для уже заблокированной поверхности закончится неудачей.

Функции GetDC() и ReleaseDC()

Прямой доступ к памяти поверхности — замечательная возможность, но иногда бывает удобнее рассматривать поверхность как обычное графическое устройство Windows. Для этой цели в интерфейсе DirectDrawSurface предусмотрены две функции:

• GetDC()

• ReleaseDC()

Функция GetDC() предоставляет в ваше распоряжение DC (контекст устройства, Device Context), через который можно осуществлять вывод на поверхность стандартными функциями Win32. Например, передавая его функции Win32 TextOut(), можно вывести на поверхность текст. Функция ReleaseDC() должна быть вызвана сразу же после завершения работы с DC.

Как и в случае с Lock() и Unlock(), функцию ReleaseDC() необходимо вызывать после GetDC() как можно быстрее. Это связано с тем, что внутри функции GetDC() вызывается Lock(), а внутри ReleaseDC() - Unlock().

Функции PageLock() и PageUnlock()

Перейдем к двум функциям, внешне похожим на Lock() и Unlock():

• PageLock()

• PageUnlock()

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

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

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

Следует помнить, что частое использование PageLock() приведет к замедлению работы Windows из-за сокращения общего объема переносимой памяти. Когда именно это произойдет, зависит от объема памяти, для которой запрещен перенос на диск, и общего объема системной памяти.

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

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

Функции PageLock() и PageUnlock() не влияют на поверхности, находящиеся в видеопамяти.

Функции IsLost() и Restore()

Две следующие функции предназначены для работы с поверхностями в видеопамяти:

• IsLost()

• Restore()

Рассмотрим следующую ситуацию: ваше приложение начинает работу. Вы размещаете как можно больше поверхностей в видеопамяти, а все остальные — в системной памяти. В течение некоторого времени приложение работает, но затем пользователь запускает другое приложение или переключается на него. Другое приложение может быть чем угодно — скажем, стандартной Windows-программой (например, Windows Explorer или Notepad). Оно также может оказаться другим приложением, которое тоже работает с DirectDraw и стремится разместить как можно больше поверхностей в видеопамяти. Если DirectDraw откажется выделить новому приложению видеопамять, оно будет работать плохо (а то и вообще не будет). Возможна и обратная ситуация — видеопамять окажется недоступной для вашего приложения.

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

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

При этом существует одна загвоздка. Функция Restore() восстанавливает лишь память, закрепленную за поверхностью, но не ее содержимое. Следовательно, после восстановления поверхности ваше приложение само должно восстановить ее содержимое.

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

Функция GetDDInterface()

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

Функции присоединения поверхностей

Интерфейс DirectDrawSurface содержит четыре функции для управления взаимосвязанными поверхностями:

• AddAttachedSurface()

• DeleteAttachedSurface()

• EnumAttachedSurface()

• GetAttachedSurface()

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

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

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

• AddOverlayDirtyRect()

• EnumOverlayZOrder()

• GetOverlayPosition()

• SetOverlayPosition()

• UpdateOverlay()

• UpdateOverlayDisplay()

• UpdateOverlayZOrder()

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

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

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

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

• GetClipper()

• SetClipper()

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

Функции палитры

Палитры, как и объекты отсечения, можно присоединять к поверхностям. Для этой цели в интерфейсе DirectDrawSurface предусмотрены две функции:

• GetPalette()

• SetPalette()

Функция SetPalette() присоединяет к поверхности экземпляр интерфейса DirectDrawPalette (о нем речь пойдет ниже). Функция GetPalette() применяется для получения указателя на палитру, присоединенную ранее.

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

Интерфейс DirectDrawPalette  

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

Экземпляры интерфейса DirectDrawPalette создаются функцией CreatePalette() интерфейса DirectDraw. Функция CreatePalette() получает набор флагов, определяющих тип палитры.

Интерфейс DirectDrawPalette содержит всего три функции:

• GetCaps()

• GetEntries()

• SetEntries()

Функция GetCaps() определяет возможности палитры. В числе получаемых сведений — количество элементов палитры, поддержка палитрой вертикальной синхронизации и (в случае 8-битной палитры) возможность заполнения всех 256 элементов.

Для заполнения палитры используется функция SetEntries(). Содержимое палитры чаще всего берется из файла. Тем не менее значения элементов палитры можно рассчитать и занести в палитру во время выполнения программы. Функция GetEntries() возвращает значения элементов, ранее занесенных в палитру.

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

Интерфейс DirectDrawClipper  

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

Экземпляры интерфейса DirectDrawClipper создаются функцией CreateClipper() интерфейса DirectDraw. Интерфейс DirectDrawClipper содержит следующие функции:

• SetHWnd()

• GetHWnd()

• IsClipListChanged()

• SetClipList()

• GetClipList()

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

Отсечение для рабочего стола активизируется функцией SetHWnd(). Функция SetHWnd() присоединяет объект отсечения к логическому номеру (handle) окна. В результате инициируется взаимодействие Windows с объектом отсечения. Объект отсечения получает уведомления обо всех изменениях окон на рабочем столе и действует соответствующим образом. Функция GetHWnd() определяет, к какому логическому номеру окна присоединен заданный объект отсечения (и присоединен ли он вообще). Функция IsClipListChanged() определяет, был ли внутренний список отсечений изменен вследствие изменений на рабочем столе.

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

После того как экземпляр DirectDrawClipper будет присоединен к поверхности, происходит автоматическое отсечение операций блиттинга, выполняемых функциями Blt(), BltBatch() и UpdateOverlay(). Обратите внимание на то, что в список не входит функция BltFast(). Для нее отсечение не поддерживается. 

Дополнительные интерфейсы DirectDraw  

Строго говоря, DirectDraw содержит еще три интерфейса, не рассмотренных нами:

• DDVideoPortContainer

• DirectDrawColorControl

• DirectDrawVideoPort

Эти интерфейсы, появившиеся в DirectX 5, предназначены для низкоуровневого управления видеопортами. Точнее, они предоставляют средства для потоковой пересылки «живого видео» на поверхности DirectDraw. Хотя с их помощью можно организовать в приложениях DirectDraw поддержку работы с видео, это не рекомендуется, за исключением случаев, когда высокоуровневые видео-API не отвечают вашим потребностям. В книге эти интерфейсы не рассматриваются.

Структуры DirectDraw 

После рассмотрения всех интерфейсов и функций DirectDraw мы переходим к структурам данных. Всего в DirectDraw определено восемь структур:

• DDBLTFX

• DDCAPS

• 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

• Runtime-файлы DirectX

• DirectX SDK

• Visual C++ 5.0

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

Runtime-файлы DirectX 

DirectX делится на две части: runtime-часть и SDK. Для разработки приложений необходимы обе половины, а для запуска программ DirectX достаточно лишь runtime-файлов.

Runtime-часть DirectX встроена в Windows NT версии 4.0 и выше. В Windows 95 этих файлов нет, но их можно легко найти и установить. К сожалению, в Windows NT версий ниже 4.0 программы, использующие DirectX, работать не будут.

Runtime-часть DirectX поставляется вместе со многими приложениями DirectX. Она также имеется на CD-ROM, прилагаемом к этой книге. Распространяемые runtime-файлы DirectX предназначены только для Windows 95, не пытайтесь устанавливать их для Windows NT.

Существует несколько способов узнать, установлена ли runtime-часть DirectX в вашей Windows 95. Во-первых, можно попытаться запустить любую демонстрационную программу, прилагаемую к этой книге или к DirectX SDK. Если программы работают, значит, runtime-часть установлена. Во-вторых, можно открыть панель управления и выбрать значок Add/Remove Programs. Если в открывшемся списке присутствует строка DirectX Drivers, значит, runtime-часть установлена. (Последний способ относится только к Windows 95. Хотя в Windows NT имеется встроенная поддержка DirectX, строка DirectX Drivers в диалоговом окне Add/Remove Programs не выводится). 

СОВЕТ

Новая возможность DirectX 5

Начиная с DirectX 5, значок DirectX помещается на панель управления. Это мини-приложение обеспечивает более совершенные возможности для просмотра и изменения настроек DirectX, чем в предыдущих версиях. 

Необходимо также проверить версию имеющейся у вас runtime-части. Всего существуют четыре версии библиотеки: 1, 2, 3 и 5 (версии 4 не было). В каждой версии используется своя runtime-часть. Поскольку работа DirectX основана на спецификации COM с ее мощной поддержкой совместимости с предыдущими версиями, новые версии runtime-частей DirectX должны нормально работать со старыми приложениями DirectX. Чтобы узнать, какая версия библиотеки установлена на вашем компьютере, вызовите диалоговое окно Add/Remove Programs, выделите строку DirectX Drivers и нажмите кнопку Add/Remove — появляется список всех установленных компонентов. Компоненты с номерами версий, начинающимися с 4.02, принадлежат DirectX 1. Номера версий, начинающиеся с 4.03, относятся к DirectX 2, с 4.04 — DirectX 3, и 4.05 — DirectX 5. На прилагаемом к книге CD-ROM содержится runtime-часть от DirectX 5. 

DirectX SDK 

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

Найти DirectX SDK несколько сложнее, чем runtime-часть библиотеки. Этот пакет не входит в поставку Windows NT или Windows 95; его нет и на CD-ROM, прилагаемом к книге. Существуют три способа раздобыть SDK:

• Купить Visual C++ 5.0 (в комплект которого входит DirectX 3 SDK).

• Посетить на Web-узле Microsoft страницу для перекачки DirectX.

• Подписаться на MSDN (Microsoft Development Network).

Если у вас есть Visual C++, то есть и SDK. Хотя это не самая последняя версия, ее вполне хватит для большинства материалов из этой книги.

SDK также можно получить на Web-узле Microsoft (адрес есть в предисловии). Объем пересылки оказывается довольно большим (из-за программ-примеров), поэтому приготовьтесь посвятить этому занятию целую ночь, особенно при модемном соединении.

Третий способ вполне хорош, однако кое-кто считает нелогичным платить Microsoft за право разработки приложений, отчасти способствующих продвижению их операционных систем. SDK входит в MSDN уровня 2 и выше. 

Visual C++ 

После установки SDK необходимо сообщить Visual C++ о его местонахождении. По умолчанию SDK инсталлируется в каталог с именем dxsdk/sdk. Заголовочные файлы помещаются в каталог dxsdk/sdk/inc, а библиотечные — в каталог dxsdk/sdk/lib.

Существуют два способа уведомить Visual C++ о местонахождении SDK. Вы можете либо указывать полный файловый путь при использовании файлов, либо включить нужные каталоги в путь поиска Visual C++. Желательно использовать второй метод, для чего применяется диалоговое окно, вызываемое командой Tools | Options | Directories. На рис. 1.1 показано, как выглядит это диалоговое окно после добавления пути к каталогу с заголовочными файлами. 

Рис. 1.1. Диалоговое окно Visual C++ с перечнем каталогов 

Вам также придется включить в список каталог dxsdk/sdk/lib. Это делается практически так же, как и с каталогом dxsdk/sdk/inc.

На рисунке каталог DirectX был с помощью кнопок ­ и Ї помещен в начало списка, над стандартными каталогами Visual C++. Это имеет значение, если от версии DirectX SDK, входящей в Visual C++, вы перейдете к более свежей. В противном случае будет использоваться старая версия (Visual C++ просматривает каталоги из списка сверху вниз).

После выполнения всех описанных действий вы сможете компилировать программы DirectX. Тем не менее осталась еще одна потенциальная проблема. Чтобы в DirectX 2 SDK нормально проходила компоновка программ, вызывающих функцию QueryInterface() для GUID интерфейсов DirectX, необходимо определить символическую константу INITGUID. Этот символ должен быть определен в одном и только одном исходном файле, и притом до самой первой директивы #include, как показано в следующем фрагменте:

#define INITGUID

#include <ddraw.h>

// ... остальные директивы include ...

В DirectX 3 и выше этот вариант тоже работает, однако появляется и более элегантное решение. Вместо того чтобы определять символ INITGUID, включите в проект файл dxguid.lib (в диалоговом окне, вызываемом командой Build | Settings). 

Windows NT и Windows 95 

Эта книга посвящена разработке приложений DirectDraw для Windows NT и Windows 95. Приступая к работе над демонстрационными программами, я заранее приготовился к раздражающим мелким отличиям и проявлениям несовместимости. Признаюсь, я был приятно удивлен.

И все же отличия существуют, особенно в части видеорежимов. Во-первых, Windows NT не поддерживает видеорежимы семейства Mode X. Независимо от того, поддерживаются ли такие видеорежимы установленной видеокартой, функция EnumDisplayModes() не сообщает о них, а функция SetDisplayMode() не активизирует их.

Во-вторых, Windows 95 позволяет задавать параметры монитора, а Windows NT — нет. В Windows 95 список видеорежимов, обнаруженных DirectDraw, учитывает возможности как видеокарты, так и монитора. Если режим поддерживается только видеокартой, но не монитором, DirectDraw не включает его в список. Однако в Windows NT параметры монитора не задаются; следовательно, DirectDraw выведет список всех видеорежимов, поддерживаемых видеокартой, независимо от того, реализуются ли они установленным монитором.

Следовательно, к переключению режимов в приложениях DirectDraw следует подходить с осторожностью. В коммерческих приложениях должен присутствовать механизм страховки, который бы позволял проверить видеорежим перед тем, как переходить в него. Подобный механизм используется при выборе видеорежима рабочего стола и в Windows NT, и в Windows 95. Когда вы приказываете Windows сменить видеорежим, новый режим активизируется на 15 секунд, после чего восстанавливается предыдущий. Затем диалоговое окно спрашивает, правильно ли система работала с новыми параметрами.

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

Заключение  

Наш интенсивный краткий курс DirectDraw подходит к концу. В главе 2 мы поговорим о проектировании и оптимизации приложений, а также о том, что ждет DirectDraw в ближайшем будущем.

Глава 2. Проблемы быстродействия                 

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

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

Не стоит полагать, что каждый пользователь, знакомясь с новой программой, говорит себе: «Пусть эта штуковина работает побыстрее, а не то…» Быстродействие программы чаще оценивается на подсознательном уровне. Работа с быстрой программой, мгновенно реагирующей на все ваши желания, доставляет радость. Хорошее быстродействие вселяет в пользователя уверенность и желание работать дальше. Медленные программы лишь испытывают наше терпение. Каждый, кому приходится работать с ними, мечтают поскорее закончить свои мучения. Пользователи предпочитают, чтобы любая программа (текстовый или графический редактор, игра или любое другое приложение) быстро и адекватно реагировала на их действия.

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

Традиционная оптимизация

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

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

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

Действительно ли C++ медленнее C?

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

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

C++ был создан для того, чтобы обогатить существующий язык C конкретными функциональными возможностями и при этом воспользоваться преимуществами его скорости. Добавлений было несколько, но основным усовершенствованием стало появление объектов, или классов. Более того, первоначально C++ назывался C with classes.

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

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

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

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

Программы в этой книге написаны на C++. Обратите внимание на умеренное использование классов. Например, вполне логично использовать класс для представления окна, потому что в MFC входит заранее написанный и протестированный оконный класс. Тем не менее способ применения этого класса более характерен для «просто C».

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

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

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

Аппаратная часть быстрее программной

Если вы уже видели хорошее приложение DirectDraw за работой, то уже знаете это. Приложение, которое работает в режиме 640×480×16 и при этом обеспечивает вывод 60 кадров в секунду, было бы невозможно написать без аппаратного ускорения. Так как DirectDraw автоматически использует все возможности для аппаратного ускорения, вам даже не придется беспокоиться на этот счет.

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

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

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

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

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

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

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

FPS — еще не все

В наши дни часто приходится слышать о частоте вывода кадров, или FPS (Frames Per Second, количество кадров в секунду). Этот показатель стал мерой для сравнения графических Windows-приложений. Конечно, DirectDraw позволяет создавать приложения с высоким FPS, однако не стоит переоценивать важность этой характеристики.

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

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

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

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

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

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

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

Долой аппаратную зависимость!

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

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

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

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

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

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

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

Будущее DirectX

Сейчас можно сказать, что разработка приложений на базе DirectX оказалась сложнее, чем хотелось бы. Создание полноценных, переносимых приложений DirectX осложняется целым рядом проблем.

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

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

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

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

Некоторые недостатки должны исчезнуть в ближайшем будущем, после интеграции DirectX в Windows. Будущие версии Windows 95, подобно Windows NT 4.0, будут содержать встроенную runtime-часть DirectX и драйверы устройств. Несомненно, дальнейшее развитие DirectX облегчит жизнь и пользователям, и разработчикам.

Заключение

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

Глава 3. За кулисами DirectDraw

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

DirectDraw AppWizard

Если вы работали с Visual C++, то вам почти наверняка приходилось пользоваться AppWizard. AppWizard представляет собой специальное приложение, работающее в среде Visual C++. По вашим указаниям он генерирует целый проект вместе со всеми исходными текстами. Хотя сам термин подразумевает, что AppWizard генерируют только приложения, некоторые из них создают библиотеки, управляющие элементы OLE и даже другие AppWizard. Важно понять, что AppWizard позволяет быстро и легко заложить основу для работы над проектом. Несколько AppWizard поставляются вместе с Visual C++, самый известный из них предназначен для создания MFC-приложений.

Наш нестандартный DirectDraw AppWizard создает приложения DirectDraw. Для установки DirectDraw AppWizard можно воспользоваться инсталляционной программой с CD-ROM или просто скопировать с диска файл AppWizard (с расширением AWX) в каталог с шаблонами Visual C++.

Создание приложения Bounce

В Visual C++ Developer Studio вызовите DirectDraw AppWizard. Для этого воспользуйтесь командой File | New, затем выберите Project Workspace — откроется диалоговое окно, в левой части которого перечислены все возможные AppWizard. На рис. 3.1 изображено это окно с выбранным DirectDraw AppWizard.

Рис. 3.1. Диалоговое окно New Project Workspace

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

После того как вы выберете DirectDraw AppWizard, введете имя проекта и нажмете кнопку Create, на экране появится первое диалоговое окно AppWizard (см. рис. 3.2).

Рис. 3.2. Диалоговое окно с заставкой DirectDraw AppWizard

Это окно в основном декоративное, но по ряду элементов оно похоже на остальные окна AppWizard. Например, в каждом окне имеются четыре кнопки, изображенные на рис. 3.2. Кнопки Back и Next позволяют перейти к следующему или вернуться к предыдущему окну. При нажатии кнопки Finish появляется диалоговое окно подтверждения, в котором можно просмотреть принятые вами решения. Кнопка Cancel возвращает вас в среду Visual C++. Нажмите кнопку Next, чтобы перейти к следующему окну.

Во втором окне DirectDraw AppWizard предлагается выбрать тип создаваемого приложения: полноэкранное или оконное. По умолчанию установлен переключатель Full-screen (для полноэкранного приложения). Наше изучение начнется именно с полноэкранных приложений, поэтому оставьте тип, выбранный по умолчанию. Второе окно AppWizard изображено на рис. 3.3.

Рис. 3.3. Диалоговое окно Application Type

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

Рис. 3.4. Диалоговое окно Initial Settings

По умолчанию выбирается режим 640×80×6. Оставьте значения, принятые по умолчанию, и нажмите кнопку Next.

В четвертом окне предлагается выбрать содержимое приложения — None или Bitmap. При установке переключателя None генерируемое приложение не делает абсолютно ничего, а при установке Bitmap оно выполняет анимацию растрового изображения. Диалоговое окно Contents изображено на рис. 3.5. По умолчанию устанавливается переключатель Bitmap; именно этот вариант будет использован в приложении Bounce.

Рис. 3.5. Диалоговое окно Contents

В пятом и шестом окнах диалога можно переопределить имена классов C++, по умолчанию выбираемые для приложения. Имена классов отображаются в двух текстовых полях; оставьте их без изменений. Диалоговое окно Class Names изображено на рис. 3.6.

Рис. 3.6. Диалоговое окно Class Names

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

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

Рис. 3.7. Диалоговое окно подтверждения

Структура приложения

Перед тем как рассматривать структуру проекта Bounce, мы немного поговорим об иерархии классов, использованных для его построения. Так вам будет проще понять код этого приложения, а так как остальные программы на CD-ROM устроены аналогично — то и код всех остальных программ из этой книги.

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

В реализации программы 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.

Структура приложения

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

Итак, классы DirectDrawWin и DirectDrawApp образуют структурную основу приложения и реализуют поддержку его работы. «Структурная основа» означает, что, хотя всю главную работу придется выполнять вам, эти классы решают, когда и как это должно происходить. Например, класс DirectDrawWin позволяет выбрать исходный видеорежим. Для этого класс вызывает написанную вами функцию, которая просматривает список доступных видеорежимов и выбирает один из них. Эта функция вызывается классом DirectDrawWin в нужный момент.

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

Тем не менее, если вы собираетесь действительно глубоко изучить DirectDraw, нельзя, чтобы кто-то выполнял всю работу за вас. По этой причине код структурной основы включается в каждый проект; не существует центральной библиотеки классов, используемой во всех программах. Каждый проект, находящийся на CD-ROM или сгенерированный AppWizard, является законченным и вполне самостоятельным; он не зависит ни от чего, кроме MFC и DirectX. Вы сможете модифицировать, дополнять или удалять фрагменты структурного кода так, как сочтете нужным.

Специализированные классы

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

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

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

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

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

• Восстанавливать потерянные поверхности. Класс DirectDrawWin автоматически обнаруживает потерю поверхности и в должный момент предоставляет производным классам возможность ее восстановления. Первичная поверхность вместе со вторичным буфером восстанавливается классом DirectDrawWin.

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

Инициализация

Перед тем как начинать работу, необходимо создать экземпляры всех основных классов приложения. В нашем случае это будут классы BounceWin и BounceApp. Объект приложения создается способом, традиционным для MFC, то есть объявлением глобального экземпляра:

BounceApp theapp;

Класс BounceApp наследует свои функциональные возможности от DirectDrawApp, и больше ему почти ничего не требуется. Есть всего одно исключение: класс BounceApp отвечает за создание объекта BounceWin. Это происходит в функции InitInstance(), вызываемой MFC при запуске приложения. Функция InitInstance() выглядит так:

BOOL BounceApp::InitInstance() {

 BounceWin* win=new BounceWin;

 if (!win->Create("High Performance Bounce Demo", IDI_ICON)) {

  AfxMessageBox("Failed to create window");

  return FALSE;

 }

 m_pMainWnd=win;

 return DirectDrawApp::InitInstance();

}

Функция InitInstance() создает экземпляр класса BounceWin и вызывает функцию BounceWin::Create(). При вызове Create() необходимо передать два аргумента: строку с названием окна и идентификатор ресурса значка. Хотя название окна не отображается во время работы приложения (потому что приложение занимает весь экран и не имеет строки заголовка), оно будет выводиться в списке задач, а также на панели задач при сворачивании приложения. Если вызов Create() закончится неудачей, то функция InitInstance() возвращает FALSE. По этому признаку MFC узнает о том, что приложение следует аварийно завершить.

Затем переменная m_pMainWnd инициализируется указателем на созданный объект окна. Эта переменная принадлежит классу CWinApp; инициализируя ее, вы сообщаете классу CWinApp о том, каким объектом окна он будет управлять. Если m_pMainWnd не будет присвоен указатель на окно, MFC завершает приложение с ошибкой.

Наконец, мы вызываем функцию DirectDrawApp:InitInstance() и используем полученное от нее значение в качестве результата функции BounceApp::InitInstance(). Функция InitInstance() класса DirectDrawApp выглядит так:

BOOL DirectDrawApp::InitInstance() {

 ASSERT(m_pMainWnd);

 m_pMainWnd->ShowWindow(SW_SHOWNORMAL);

 m_pMainWnd->UpdateWindow();

 ShowCursor(FALSE);

 return TRUE;

}

Я уже упоминал о том, что MFC требует задать значение переменной m_pMainWnd, но поскольку значение m_pMainWnd используется в этой функции, проверку можно выполнить и самостоятельно. Макрос MFC ASSERT() проверяет значение переменной m_pMainWnd. Если указатель равен нулю, приложение завершается с ошибкой. Если он отличен от нуля, мы вызываем две функции созданного окна: ShowWindow() и UpdateWindow(). Эти функции отображают окно на экране. Наконец, функция ShowCursor() отключает курсор мыши.

Создание и отображение окна завершает процесс инициализации классов DirectDrawApp и BounceApp. Теперь давайте посмотрим, как этот процесс отражается на классах DirectDrawWin и BounceWin.

Как мы уже знаем, функция Create() вызывается из функции BounceApp:: InitInstance(). Она не реализуется классом BounceWin, а наследуется от DirectDrawWin. Функция Create() выглядит так:

BOOL DirectDrawWin::Create(const CString& title,int icon) {

 CString sClassName;

 sClassName = AfxRegisterWndClass(CS_HREDRAW | CS_VREDRAW,   LoadCursor(0, IDC_ARROW), (HBRUSH)(COLOR_WINDOW + 1),   LoadIcon(AfxGetInstanceHandle(), MAKEINTRESOURCE(icon)));

 return CWnd::CreateEx(WS_EX_TOPMOST, sClassName, title, WS_POPUP, 0, 0, 100, 100, 0, 0);

}

Сначала функция Create() регистрирует класс окна с помощью функции AfxRegisterWndClass(). Затем она вызывает функцию CreateEx(), в которой и происходит фактическое создание окна.

Обратите внимание на то, что создаваемое окно имеет размеры 100x100 (седьмой и восьмой аргументы CreateEx()). Такой размер выбран произвольно. DirectDraw при подключении окна автоматически изменяет его размер так, чтобы оно занимало весь экран. Также обратите внимание на флаг WS_EX_TOPMOST: окно полноэкранного приложения DirectDraw должно выводиться поверх остальных окон.

Атрибут верхнего окна, а также занятие им всего экрана необходимы для того, чтобы механизм GDI не смог ничего вывести на экран. GDI ничего не знает о DirectDraw, поэтому наше окно «обманывает» GDI на то время, пока весь экран находится под управлением DirectDraw. Вообще говоря, вывод средствами GDI может происходить и в полноэкранном режиме, но обычно это не рекомендуется, потому что вывод GDI может попасть на невидимую поверхность. Эта тема более подробно рассматривается в главе 5.

Инициализация DirectDraw

Фактическое создание окна (вызов функции CreateEx()) заставляет Windows послать нашему приложению сообщение WM_CREATE. Класс DirectDrawWin перехватывает это сообщение в обработчике OnCreate(), созданном ClassWizard (см. листинг 3.1).

Листинг 3.1. Функция DirectDrawWin::OnCreate()

int DirectDrawWin::OnCreate(LPCREATESTRUCT) {

 DirectDrawEnumerate(DriverAvailable, this);

 if (totaldrivers==0) {

  AfxMessageBox("No DirectDraw drivers detected");

  return -1;

 }

 int driverindex=SelectDriver();

 if (driverindex<0) {

  TRACE("No DirectDraw driver selected\n");

  return -1;

 } else if (driverindex>totaldrivers-1) {

  AfxMessageBox("Invalid DirectDraw driver selected\n");

  return -1;

 }

 LPDIRECTDRAW ddraw1;

 DirectDrawCreate(driver[driverindex].guid, &ddraw1, 0);

 HRESULT r;

 r=ddraw1->QueryInterface(IID_IDirectDraw2, (void**)&ddraw2);

 if (r!=S_OK) {

  AfxMessageBox("DirectDraw2 interface not supported");

  return -1;

 }

 ddraw1->Release(), ddraw1=0;

 ddraw2->SetCooperativeLevel(GetSafeHwnd(), DDSCL_EXCLUSIVE | DDSCL_FULLSCREEN | DDSCL_ALLOWMODEX);

 ddraw2->EnumDisplayModes(0, 0, this, DisplayModeAvailable);

 qsort(displaymode, totaldisplaymodes, sizeof(DisplayModeInfo),   CompareModes);

 int initmode=SelectInitialDisplayMode();

 if (ActivateDisplayMode(initmode)==FALSE) return -1;

 return 0;

}

Вся инициализация DirectDraw выполняется в функции OnCreate() (при поддержке нескольких вспомогательных функций). Процесс инициализации состоит из семи этапов:

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

• Выбор драйвера DirectDraw.

• Инициализация DirectDraw с использованием выбранного драйвера.

• Получение списка поддерживаемых видеорежимов.

• Выбор исходного видеорежима.

• Активизация выбранного видеорежима.

• Создание поверхностей приложения.

Все эти этапы рассматриваются в последующих разделах.

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

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

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

BOOL WINAPI DirectDrawWin::DriverAvailable(LPGUID guid, LPSTR desc, LPSTR name, LPVOID p) {

 DirectDrawWin* win=(DirectDrawWin*)p;

 if (win->totaldrivers >= MAXDRIVERS) return DDENUMRET_CANCEL;

 DriverInfo& info=win->driver[win->totaldrivers];

 if (guid)  {

  info.guid=(GUID*)new BYTE[sizeof(GUID)];

  memcpy(info.guid, guid, sizeof(GUID));

 } else info.guid=0;

 info.desc=strdup(desc);

 info.name=strdup(name);

 win->totaldrivers++;

 return DDENUMRET_OK;

}

Сначала указатель на данные, определяемые приложением (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. Строки описаний и имен зависят от типов видеоустройств и версий драйверов.

Выбор драйвера

После того как все драйверы DirectDraw будут перечислены, функция OnCreate() выбирает один из них. Выбор драйвера по умолчанию может быть переопределен в производных классах с помощью виртуальной функции SelectDriver(). Возвращаясь к листингу 3.1, мы видим, что величина, возвращаемая функцией SelectDriver(), используется в качестве индекса массива driver (причем значения индекса начинаются с нуля). Индекс показывает, какой GUID (и, следовательно, драйвер) должен использоваться для инициализации DirectDraw. Версия SelectDriver() из класса DirectDrawWin выглядит так:

virtual int SelectDriver() {

 return 0;

}

По умолчанию SelectDriver() возвращает 0, тем самым показывая, что должно использоваться первичное видеоустройство. Чтобы изменить ее поведение, следует переопределить SelectDriver() в классе, производном от DirectDrawWin. В нашем примере класс BounceWin переопределяет SelectDriver() так, чтобы в случае обнаружения нескольких драйверов выводилось меню:

int bounceWin::SelectDriver() {

 int numdrivers=GetNumDrivers(); 

 if (numdrivers==1) return 0;

 CArray <CString, CString>drivers;

 for (int i=0;i<numdrivers;i++) {

  LPSTR desc, name;

  GetDriverInfo(i, 0, &desc, &name);

  drivers.Add(desc);

 }

 DriverDialog dialog;

 dialog.SetContents(&drivers);

 if (dialog.DoModal()!=IDOK) return -1;

 return dialog.GetSelection();

}

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

Если в системе доступно несколько драйверов, функция SelectDriver() создает меню, состоящее из строк с описаниями драйверов. Класс DriverDialog (простой класс диалогового окна, сгенерированный ClassWizard) выводит диалоговое окно, в котором пользователь может выбрать нужный драйвер. На рис. 3.9 изображено такое окно с двумя строками: первичным драйвером и драйвером DirectX 2 для видеокарты Orchid Righteous 3D.

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

Инициализация DirectDraw

Третья задача, выполняемая функцией OnCreate(), — инициализация DirectDraw. Я снова привожу соответствующий фрагмент листинга 3.1:

LPDIRECTDRAW ddraw1;

DirectDrawCreate(driver[driverindex].guid, &ddraw1, 0);

HRESULT r;

r=ddraw1->QueryInterface(IID_IDirectDraw2, (void**)&ddraw2);

if (r!=S_OK) {

 AfxMessageBox("DirectDraw2 interface not supported");

 return -1;

}

ddraw1->Release(), ddraw1=0;

ddraw2->SetCooperativeLevel(GetSafeHwnd(), DDSCL_EXCLUSIVE | DDSCL_FULLSCREEN | DDSCL_ALLOWMODEX);

Сначала мы объявляем ddraw1, указатель на интерфейс DirectDraw. Это локальный и, следовательно, временный указатель. Класс DirectDrawWin объявляет ddraw2, указатель на интерфейс DirectDraw2, однако мы не сможем инициализировать его без интерфейса DirectDraw. Функция DirectDrawCreate() инициализирует указатель ddraw1. Первый аргумент является указателем на GUID выбранного драйвера. Адрес указателя ddraw1 передается в качестве второго аргумента. Последний аргумент DirectDrawCreate() должен быть равен 0.

Рис. 3.9. Диалоговое окно для выбора драйвера

После того как интерфейс DirectDraw будет инициализирован, им можно воспользоваться для получения указателя на интерфейс DirectDraw2. Для этого следует вызвать функцию QueryInterface() и передать ей GUID интерфейса DirectDraw2, определенный под именем IID_IDirectDraw2. Если вызов QueryInterface() заканчивается неудачно, программа выводит диалоговое окно и завершает работу. Фактически мы требуем присутствия библиотеки DirectX версии 2 и выше (потому что интерфейс DirectDraw2 впервые появился в DirectX 2). Если вызов QueryInterface() окажется успешным, указатель ddraw1 освобождается. Попеременный вызов функций интерфейсов DirectDraw и DirectDraw2 не рекомендуется, поэтому освобождение указателя на интерфейс DirectDraw гарантирует, что в оставшейся части кода будет использоваться только интерфейс DirectDraw2.

Затем мы вызываем функцию SetCooperativeLevel() и в качестве аргументов передаем ей логический номер нашего окна и три флага. По логическому номеру организуется взаимодействие окна с DirectDraw. При вызове SetCooperativeLevel() использованы три флага: DDSCL_EXCLUSIVE, DDSCL_FULLSCREEN и DDSCL_ALLOWMODEX. Флаги монопольного и полноэкранного режима обычно используются вместе для получения максимальных полномочий по управлению видеоустройством. Последний флаг означает, что все поддерживаемые видеорежимы Mode X должны быть доступны для выбора в программе. В Windows NT этот флаг игнорируется.

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

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

HRESULT WINAPI DirectDrawWin::DisplayModeAvailable(LPDDSURFACEDESC desc, LPVOID p) {

 DirectDrawWin* win=(DirectDrawWin*)p;

 int& count=win->totaldisplaymodes;

 if (count==MAXDISPLAYMODES) return DDENUMRET_CANCEL;

 win->displaymode[count].width = desc->dwWidth;

 win->displaymode[count].height = desc->dwHeight;

 win->displaymode[count].depth = desc->ddpfPixelFormat.dwRGBBitCount;

 count++;

 return DDENUMRET_OK;

}

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

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

Выбор видеорежима

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

virtual int SelectInitialDisplayMode() = 0;

В C++ чисто виртуальные функции обязательно должны переопределяться, в противном случае класс не будет компилироваться. Однако со стороны DirectDrawWin было бы нечестно требовать от производного класса выбора исходного видеорежима, не предоставляя ему средств для просмотра возможных вариантов (переменные класса, в которых хранятся сведения о видеорежимах, являются закрытыми (private)). Для этой цели в классе DirectDrawWin предусмотрены функции GetNumDisplayModes() и GetDisplayModeDimensions(). В версии SelectInitialDisplayMode() класса BounceWin эти функции используются для выбора исходного режима:

int BounceWin::SelectInitialDisplayMode() {

 int i, nummodes=GetNumDisplayModes();

 DWORD w,h,d;

 for (i=0;i<nummodes;i++) {

  GetDisplayModeDimensions(i, w, h, d);

  if (w==desiredwidth && h==desiredheight && d==desireddepth) return i;

 }

 for (i=0;i>nummodes;i++)  {

  GetDisplayModeDimensions(i, w, h, d);

  if (d==desireddepth) return i;

 }

 return 0;

}

Функция сначала определяет количество режимов функцией GetNumDisplayModes(), а затем в цикле пытается найти видеорежим с заданным разрешением и глубиной пикселей. Атрибуты каждого видеорежима извлекаются функцией GetDisplayModeDimensions(); если совпадение будет найдено, возвращается индекс видеорежима. В противном случае другой цикл ищет любой видеорежим с заданной глубиной пикселей. Поскольку цикл начинается с начала массива displaymode, с большей вероятностью будут выбираться режимы низкого разрешения. Если не найдено ни одного видеорежима с заданной глубиной пикселей, возвращается значение 0 — оно говорит о том, что следует использовать видеорежим с минимальным разрешением. Код возврата –1 сообщает DirectDrawWin о том, что ни один приемлемый видеорежим так и не был найден и работу приложения следует завершить.

Активизация видеорежима

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

Листинг 3.2. Функция ActivateDisplayMode()

BOOL DirectDrawWin::ActivateDisplayMode(int mode) {

 if (mode<0 || mode>=totaldisplaymodes) return FALSE;

 DWORD width = displaymode[mode].width;

 DWORD height = displaymode[mode].height;

 DWORD depth = displaymode[mode].depth;

 displayrect.left=0;

 displayrect.top=0;

 displayrect.right=width;

 displayrect.bottom=height;

 displaydepth=depth;

 ddraw2->SetDisplayMode(width, height, depth, rate, 0);

 curdisplaymode = mode;

 TRACE("------------------- %dx%dx%d (%dhz) ---------------\n",   width, height, depth, rate);

 if (CreateFlippingSurfaces()==FALSE) {

  FatalError("CreateFlippingSurfaces() failed");

  return FALSE;

 }

 StorePixelFormatData();

 if (CreateCustomSurfaces()==FALSE) {

  FatalError("CreateCustomSurfaces() failed");

  return FALSE;

 }

 return TRUE;

}

Нужный видеорежим определяется параметром mode, который сначала проверяется на правильность. Затем его ширина, высота и глубина извлекаются из массива displaymode и заносятся в переменные displayrect и displaydepth. Доступ к этим переменным в производных классах осуществляется с помощью функций GetDisplayRect() и GetDisplayDepth().

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

Перед тем как рассматривать оставшуюся часть функции, следует сделать одно важное замечание. До сих пор, если функция заканчивалась неудачей и требовалось вывести сообщение, можно было использовать функцию MFC AfxMessageBox(). Пока видеорежим не изменялся, все было нормально, но после изменения видеорежима для вывода сообщений и завершения программы применяется функция FatalError(). Эта функция класса DirectDrawWin восстанавливает видеорежим Windows, выводит окно сообщения и завершает программу.

Создание поверхностей

Остается лишь создать поверхности, используемые в приложении. После вызова SetDisplayMode() функция ActivateDisplayMode() вызывает еще три функции: CreateFlippingSurfaces(), StorePixelFormatData() и CreateCustomSurfaces(). Функция CreateFlippingSurfaces() создает первичную поверхность с возможностью переключения страниц. Функция StorePixelFormatData() используется для чтения и записи сведений о формате пикселей в данном видеорежиме. Эта информация может пригодиться при работе с видеорежимами High и True Color. Функция CreateCustomSurfaces() отвечает за создание и инициализацию вспомогательных поверхностей, специфических для данного приложения. Начнем с функции CreateFlippingSurfaces():

BOOL DirectDrawWin::CreateFlippingSurfaces() {

 if (primsurf) primsurf->Release(), primsurf=0;

 DDSURFACEDESC desc;

 ZeroMemory(&desc, sizeof(desc));

 desc.dwSize = sizeof(desc);

 desc.dwFlags = DDSD_CAPS | DDSD_BACKBUFFERCOUNT;

 desc.ddsCaps.dwCaps =  DDSCAPS_PRIMARYSURFACE | DDSCAPS_FLIP | DDSCAPS_COMPLEX;

 desc.dwBackBufferCount = 1;

 HRESULT r=ddraw2->CreateSurface(&desc, &primsurf, 0);

 if (r!=DD_OK) return FALSE;

 DDSCAPS surfcaps;

 surfcaps.dwCaps = DDSCAPS_BACKBUFFER;

 r=primsurf->GetAttachedSurface(&surfcaps, &backsurf);

 if (r!=DD_OK) return FALSE;

 return TRUE;

}

Функция CreateFlippingSurfaces() вызывается при каждой инициализации нового видеорежима, поэтому ее работа начинается с освобождения ранее созданных поверхностей функцией Release(). Затем она объявляет и инициализирует экземпляр структуры DDSURFACEDESC. Эта структура описывает тип создаваемой поверхности. В соответствии с требованиями DirectDraw необходимо установить флаги для всех инициализируемых полей. В нашем случае флаги DDSD_CAPS и DDSD_BACKBUFFERCOUNT говорят о том, что мы задаем возможности поверхности (поле dwCaps) и количество вторичных буферов (поле dwBackCount). В поле dwCaps устанавливаются три флага:

• DDSCAPS_PRIMARYSURFACE

• DDSCAPS_FLIP

• DDSCAPS_COMPLEX

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

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

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

Новая поверхность создается вызовом функции CreateSurface() интерфейса DirectDraw. Первым аргументом является указатель на структуру desc, а вторым - указатель на переменную DirectDrawWin::primsurf. Эта переменная объявлена защищенной (protected), поэтому мы можем использовать ее для доступа к первичной поверхности в своих программах. Третий аргумент функции CreateSurface() должен быть равен 0.

Вызов CreateSurface() создает две поверхности: первичную поверхность и вторичный буфер. Позднее указатель на вторичный буфер понадобится нам для подготовки кадров. Чтобы получить этот указатель, следует вызвать функцию GetAttachedSurface() интерфейса DirectDrawSurface и передать ей структуру DDSCAPS с описанием типа интересующей нас присоединенной поверхности. Задавая флаг DDSCAPS_BACKBUFFER, мы вызываем функцию GetAttachedSurface(), которая инициализирует переменную backsurf. Она, как и переменная primsurf, объявлена защищенной, поэтому классы, производные от DirectDrawWin, могут легко обратиться к вторичному буферу.

После того как указатели primsurf и backsurf будут инициализированы, ActivateDisplayMode() вызывает функцию StorePixelFormatData(). Эта функция с помощью функции GetPixelFormat() интерфейса DirectDrawSurface получает информацию о формате хранения цветовых RGB-составляющих для отдельных пикселей. Формат пикселей зависит от видеокарты, а иногда даже от видеорежима, так что эти сведения оказываются полезными при прямых манипуляциях с поверхностями. Функция StorePixelFormatdata() выглядит так:

BOOL DirectDrawWin::StorePixelFormatData() {

 DDPIXELFORMAT format;

 ZeroMemory(&format, sizeof(format));

 format.dwSize=sizeof(format);

 if (backsurf->GetPixelFormat(&format)!=DD_OK)  {

  return FALSE;

 }

 loREDbit = LowBitPos(format.dwRBitMask);

 WORD hiREDbit = HighBitPos(format.dwRBitMask);

 numREDbits=(WORD)(hiREDbit-loREDbit+1);

 loGREENbit = LowBitPos(format.dwGBitMask);

 WORD hiGREENbit = HighBitPos(format.dwGBitMask);

 numGREENbits=(WORD)(hiGREENbit-loGREENbit+1);

 loBLUEbit = LowBitPos(format.dwBBitMask);

 WORD hiBLUEbit = HighBitPos(format.dwBBitMask);

 numBLUEbits=(WORD)(hiBLUEbit-loBLUEbit+1);

 return TRUE;

}

Структура DDPIXELFORMAT используется в функции GetPixelFormat() для получения масок, показывающих, какие биты в каждом пикселе заняты красной, зеленой и синей цветовыми составляющими. Маски точно описывают формат пикселя, но на практике работать с ними оказывается не очень удобно. Вместо того чтобы просто сохранить полученные маски, мы на основании каждой из них инициализируем два целых числа. Первое число равно позиции младшего бита цветовой составляющей, а второе — количеству бит, необходимых для ее представления. Для поверхностей True color (24- и 32-битных) цветовые составляющие всегда представляются 8 битами, но для поверхностей High color (16-битных) это число изменяется (обычно 5, но иногда 6 для зеленой составляющей).

Класс DirectDrawWin содержит шесть переменных для описания формата пикселей: loREDbit, numREDbits, loGREENbit, numGREENbits, loBLUEbit и numBLUEbits. Они используются некоторыми функциями DirectDrawWin, однако эти переменные объявлены как защищенные (protected), поэтому к ним можно обращаться и из классов, производных от DirectDrawWin. Эти переменные будут рассмотрены в главе 5.

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

Но сначала давайте подведем итоги. Приложение состоит из двух объектов, BounceWin и BounceApp. Объект BounceApp отвечает за создание объекта BounceWin, а BounceWin в свою очередь инициализирует DirectDraw. Сначала он обнаруживает все имеющиеся драйверы DirectDraw, выбирает один из них и использует его для создания экземпляра интерфейса DirectDraw2. Затем он обнаруживает видеорежимы, поддерживаемые инициализированным драйвером, выбирает один из режимов и активизирует его. Далее создается первичная поверхность с возможностью переключения страниц (и вторичным буфером) и, наконец, анализируется формат пикселей для активизированного видеорежима.

Приложение почти готово к работе, но пока у него нет графических данных. Мы подходим к следующему этапу.

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

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

BOOL BounceWin::CreateCustomSurfaces() {

 CString filename;

 if (GetCurDisplayDepth()==8) filename="tri08.bmp";

 else   filename="tri24.bmp";

 if (surf1) surf1->Release(), surf1=0;

 surf1=CreateSurface(filename, TRUE);

 if (surf1==0) {

  FatalError("failed to load BMP");

  return FALSE;

 }

 return TRUE;

}

В приложении 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-файлов этот аргумент игнорируется.

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

Наше приложение Bounce является очень простым, поэтому функция CreateCustom Surfaces() делает не так уж много. Реальное приложение может создавать десятки и даже сотни поверхностей. Класс DirectDrawWin содержит несколько служебных функций, которые могут пригодиться при работе с поверхностями, поэтому мы ненадолго отвлечемся от приложения Bounce и рассмотрим эти функции:

LPDIRECTDRAWSURFACE CreateSurface(LPCTSTR filename, BOOL  installpalette=FALSE);

LPDIRECTDRAWSURFACE CreateSurface(DWORD w, DWORD h);

BOOL LoadSurface(LPDIRECTDRAWSURFACE surf, LPCTSTR filename);

BOOL ClearSurface(LPDIRECTDRAWSURFACE surf, DWORD clr, RECT* rect=0);

BOOL ClearSurface(LPDIRECTDRAWSURFACE surf, DWORD r, DWORD g,  DWORD b, RECT* rect=0);

BOOL GetSurfaceDimensions(LPDIRECTDRAWSURFACE surf,  DWORD& w, DWORD& h);

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

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

LPDIRECTDRAWSURFACE DirectDrawWin::CreateSurface(DWORD w, DWORD h) {

 DWORD bytes=w*h*(displaydepth/8);

 DDSURFACEDESC desc;

 ZeroMemory(&desc, sizeof(desc));

 desc.dwSize = sizeof(desc);

 desc.dwFlags = DDSD_WIDTH | DDSD_HEIGHT | DDSD_CAPS;

 desc.dwWidth = w;

 desc.dwHeight = h;

 desc.ddsCaps.dwCaps = DDSCAPS_OFFSCREENPLAIN |   DDSCAPS_VIDEOMEMORY;

 LPDIRECTDRAWSURFACE surf;

 HRESULT r=ddraw2->CreateSurface(&desc, &surf, 0);

 if (r==DD_OK) {

  TRACE("CreateSurface(%d,%d) created in video memory \n", w, h);

  return surf;

 }

 desc.ddsCaps.dwCaps = DDSCAPS_OFFSCREENPLAIN | DDSCAPS_SYSTEMMEMORY;

 r=ddraw2->CreateSurface(&desc, &surf, 0);

 if (r==DD_OK) {

  TRACE("CreateSurface(%d,%d) allocated in system memory \n", w, h);

  return surf;

 }

 TRACE("CreateSurface(%d,%d) failed\n", w, h);

 return 0;

}

Функция CreateSurface() с помощью структуры DDSURFACEDESC описывает поверхность, размеры которой равны передаваемым параметрам w и h. Поле dwFlags показывает, какие поля структуры будут инициализироваться. Поля dwWidth и dwHeight определяют размеры поверхности, а поле dwCaps — ее возможности. Обратите внимание на флаг DDSCAPS_VIDEOMEMORY, согласно которому создаваемая поверхность должна находиться в видеопамяти.

Затем мы вызываем функцию DirectDraw CreateSurface(). В качестве первого аргумента передается указатель на структуру с описанием поверхности; если вызов окажется успешным, указатель surf будет ссылаться на созданную поверхность.

При успешном создании поверхности макрос MFC TRACE() выводит отладочное сообщение, а вы получаете указатель surf. Тем не менее раз мы явно указали, что поверхность должна находиться в видеопамяти, при нехватке последней вызов CreateSurface() может закончиться неудачно. В этом случае мы изменяем поле dwCaps, заносим в него флаг DDSCAPS_SYSTEMMEMORY и снова вызываем функцию CreateSurface(). Скорее всего, вторая попытка окажется успешной; если и на этот раз поверхность не будет создана, функция возвратит 0.

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

Функции ClearSurface() могут использоваться для частичного заполнения поверхностей. Первая версия ClearSurface() заполняет поверхность величиной, передаваемой в качестве второго параметра. Необязательный аргумент rect определяет заполняемую прямоугольную область (если он не задан, заполняется вся поверхность). Вторая версия ClearSurface() получает в качестве аргументов RGB-составляющие и на их основании вычисляет значение, присваиваемое каждому пикселю поверхности. Из-за дополнительной работы, затрачиваемой на интерпретацию цветов, вторая версия работает медленнее первой. Первая функция ClearSurface() реализована так:

BOOL DirectDrawWin::ClearSurface(LPDIRECTDRAWSURFACE surf,    DWORD clr, RECT* rect) {

 if (surf==0) return FALSE;

 DDBLTFX bltfx;

 ZeroMemory(&bltfx, sizeof(bltfx));

 bltfx.dwSize = sizeof(bltfx);

 bltfx.dwFillColor = clr;

 HRESULT r;

 r=surf->Blt(rect, 0, 0, DDBLT_COLORFILL | DDBLT_WAIT, &bltfx);

 return r==DD_OK;

}

Функция ClearSurface() получает три аргумента: указатель на заполняемую поверхность; величину, присваиваемую каждому пикселю; и необязательную структуру RECT, которая определяет заполняемую область поверхности.

После проверки указателя мы подготавливаем экземпляр структуры DDBLTFX. Полю dwFillColor присваивается величина, используемая для заполнения, а сама операция осуществляется функцией Blt() интерфейса DirectDrawSurface. Флаг DDBLT_COLORFILL сообщает Blt() о том, что вместо блиттинга выполняется цветовое заполнение.

Получившаяся функция удобна, но ей не хватает универсальности. Дело в том, что величина, применяемая для заполнения поверхности, может иметь различный смысл. Например, для палитровых поверхностей она представляет собой индекс в палитре. Без предварительной проверки палитры невозможно предсказать, какой цвет будет использоваться для заполнения. Аналогичные проблемы возникают и для беспалитровых поверхностей, поскольку конкретное значение пикселя зависит от глубины и формата пикселей. Форматы пикселей особенно часто различаются в режимах High Color, поэтому заполнение поверхности конкретным цветом превращается в нетривиальную задачу.

Вторая версия ClearSurface() получает в качестве аргументов RGB-составляющие и рассчитывает по ним конкретную величину, присваиваемую пикселям поверхности. В таком варианте функция становится более универсальной, но и работает медленнее; быстродействие особенно сильно снижается для палитровых поверхностей, потому что нужный цвет приходится искать в палитре. Код этой функции будет рассмотрен в главе 5.

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

BOOL DirectDrawWin::GetSurfaceDimensions(LPDIRECTDRAWSURFACE surf, DWORD& w, DWORD& h) {

 if (surf==0) return FALSE;

 DDSURFACEDESC desc;

 ZeroMemory(&desc, sizeof(desc));

 desc.dwSize=sizeof(desc);

 desc.dwFlags=DDSD_WIDTH | DDSD_HEIGHT;

 if (surf->GetSurfaceDesc(&desc)!=DD_OK) return FALSE;

 w=desc.dwWidth;

 h=desc.dwHeight;

 return TRUE;

}

После проверки указателя мы подготавливаем экземпляр структуры DDSURFACEDESC. Нас интересуют ширина и высота поверхности, поэтому в поле dwFlags заносятся флаги DDSD_WIDTH и DDSD_HEIGHT.

Затем мы вызываем функцию GetSurfaceDesc() интерфейса DirectDrawSurface и передаем ей указатель на структуру с описанием поверхности. Функция GetSurfaceDesc() сохраняет размеры поверхности в полях dwWidth и dwHeight. Они присваиваются переданным по ссылке переменным w и h типа DWORD, после чего функция завершается.

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

Графический вывод

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

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

BOOL DirectDrawApp::OnIdle(LONG) {

 if (ddwin->PreDrawScene()) ddwin->DrawScene();

 return TRUE;

}

Функция OnIdle() вызывает функцию DirectDrawWin::PreDrawScene() и в зависимости от полученного результата вызывает функцию DrawScene(). Функция OnIdle() всегда возвращает TRUE, потому что при возврате FALSE MFC перестает ее вызывать. Функция PreDrawScene() реализована так:

BOOL DirectDrawWin::PreDrawScene() {

 if (window_active && primsurf->IsLost()) {

  HRESULT r;

  r=primsurf->Restore();

  if (r!=DD_OK) TRACE("can't restore primsurf\n");

  r=backsurf->Restore();

  if (r!=DD_OK) TRACE("can't restore backsurf\n");

  RestoreSurfaces();

 }

 return window_active;

}

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

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

Так как функция OnIdle() вызывает DrawScene() лишь после проверки результата PreDrawScene(), DrawScene() будет вызвана лишь в том случае, если приложение активно, а первичная и вторичная поверхности не были потеряны.

Функция DrawScene()

Классы, производные от DirectDrawWin, реализуют функцию DrawScene(), в которой происходит обновление экрана. Версия DrawScene() из класса BounceWin выглядит так:

void BounceWin::DrawScene() {

 CRect limitrect=GetDisplayRect();

 x+=xinc;

 y+=yinc;

 if (x<-160 || x>limitrect.right-160) {

  xinc=-xinc;

  x+=xinc;

 }

 if (y<-100 || y>limitrect.bottom-120) {

  yinc=-yinc;

  y+=yinc;

 }

 ClearSurface(backsurf, 0);

 BltSurface(backsurf, surf1, x, y);

 primsurf->Flip(0, DDFLIP_WAIT);

}

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

Затем мы вызываем функцию ClearSurface() и передаем ей два аргумента: указатель backsurf и 0. Это приводит к тому, что вторичный буфер заполняется черным цветом. Хотя я упоминал о том, что использование ClearSurface() иногда осложняется различными форматами пикселей, заполнение поверхностей черным работает надежно. Для палитровых поверхностей 0 означает черный цвет, потому что по умолчанию он стоит в палитре на первом месте; для беспалитровых поверхностей 0 всегда соответствует черному цвету.

Функция DrawScene() использует функцию DirectDrawWin::BltSurface() для копирования поверхности surf1 на поверхность backsurf. Два последних аргумента BltSurface() определяют точку поверхности-приемника, куда должно быть скопировано содержимое источника. Для выполнения этой операции можно было бы воспользоваться функцией Blt() или BltFast() интерфейса DirectDrawSurface, но мы не делаем этого из-за возможного отсечения. Обратите внимание - код, определяющий положение растра, позволяет источнику выйти за пределы приемника, в результате чего может потребоваться отсечение. Мы не можем воспользоваться функцией Blt(), потому что тогда потребовалось бы присоединить к приемнику объект DirectDrawClipper, чего мы не делаем. Функция BltFast() тоже не подходит, потому что она вообще не поддерживает отсечения. Функция BltSurface() автоматически выполняет отсечение, а функции Blt() и BltFast() вызываются внутри нее.

Но перед тем, как переходить к функции BltSurface(), мы закончим рассмотрение функции DrawScene(). Она завершается вызовом функции Flip(). При этом происходит переключение страниц, и подготовленный нами кадр отображается на экране. Функция Flip() получает два аргумента: указатель на поверхность и переменную типа DWORD, предназначенную для установки флагов. Указатель на поверхность необходим лишь в нестандартных ситуациях, когда в переключении поверхностей участвует несколько вторичных буферов. Второй аргумент обычно содержит флаг DDFLIP_WAIT, показывающий, что возврат из функции должен происходить только после того, как переключение страниц завершится.

Функция BltSurface()

Функция BltSurface() класса DirectDrawWin оказывается более гибкой и удобной по сравнению с функциями DirectDrawSurface::Blt() и BltFast(). Мы уже видели, как BltSurface() используется внутри функции BounceWin::DrawScene(), а сейчас рассмотрим саму функцию.

Функция BltSurface() требует передачи четырех аргументов, а пятый аргумент необязателен. Первые два аргумента представляют собой указатели на поверхности — источник и приемник. Следующие два аргумента — координаты x и y, определяющие положение копируемой области на приемнике. По умолчанию блиттинг выполняется без цветовых ключей, однако их можно активизировать с помощью необязательного пятого параметра. Код функции BltSurface() приведен в листинге 3.3.

Листинг 3.3. Функция BltSurface()

BOOL DirectDrawWin::BltSurface(LPDIRECTDRAWSURFACE destsurf, LPDIRECTDRAWSURFACE srcsurf, int x, int y, BOOL srccolorkey) {

 if (destsurf==0 || srcsurf==0) return FALSE;

 BOOL use_fastblt=TRUE;

 DDSURFACEDESC destsurfdesc;

 ZeroMemory(&destsurfdesc, sizeof(destsurfdesc));

 destsurfdesc.dwSize = sizeof(destsurfdesc);

 destsurf->GetSurfaceDesc(&destsurfdesc);

 CRect destrect;

 destrect.left=0;

 destrect.top=0;

 destrect.right=destsurfdesc.dwWidth;

 destrect.bottom=destsurfdesc.dwHeight;

 DDSURFACEDESC srcsurfdesc;

 ZeroMemory(&srcsurfdesc, sizeof(srcsurfdesc));

 srcsurfdesc.dwSize = sizeof(srcsurfdesc);

 srcsurf->GetSurfaceDesc(&srcsurfdesc);

 CRect srcrect;

 srcrect.left=0;

 srcrect.top=0;

 srcrect.right=srcsurfdesc.dwWidth;

 srcrect.bottom=srcsurfdesc.dwHeight;

 // Проверить, нужно ли что-нибудь делать...

 if (x+srcrect.left>=destrect.right) return FALSE;

 if (y+srcrect.top>=destrect.bottom) return FALSE;

 if (x+srcrect.right<=destrect.left) return FALSE;

 if (y+srcrect.bottom<=destrect.top) return FALSE;

 // При необходимости выполнить отсечение

 // для прямоугольной области источника

 if (x+srcrect.right>destrect.right) srcrect.right-=x+srcrect.right-destrect.right;

 if (y+srcrect.bottom>destrect.bottom) srcrect.bottom-=y+srcrect.bottom-destrect.bottom;

 CRect dr;

 if (x<0) {

  srcrect.left=-x;

  x=0;

  dr.left=x;

  dr.top=y;

  dr.right=x+srcrect.Width();

  dr.bottom=y+srcrect.Height();

  use_fastblt=FALSE;

 }

 if (y<0) {

  srcrect.top=-y;

  y=0;

  dr.left=x;

  dr.top=y;

  dr.right=x+srcrect.Width();

  dr.bottom=y+srcrect.Height();

  use_fastblt=FALSE;

 }

 DWORD flags;

 if (use_fastblt) {

  flags=DDBLTFAST_WAIT;

  if (srccolorkey) flags |= DDBLTFAST_SRCCOLORKEY;

  destsurf->BltFast(x, y, srcsurf, &srcrect, flags);

 } else {

  flags=DDBLT_WAIT;

  if (srccolorkey) flags |= DDBLT_KEYSRC;

  destsurf->Blt(&dr, srcsurf, &srcrect, flags, 0);

 }

 return TRUE;

}

Сначала функция BltSurface() проверяет указатели на поверхности. Если хотя бы один из них равен нулю, функция возвращает FALSE, тем самым сообщая о неудаче. Если проверка прошла успешно, два объекта CRect инициализируются в соответствии с размерами поверхностей, полученными с помощью функции DirectDrawSurface::GetSurfaceDesc().

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

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

Если отсечение выполняется по правому или нижнему краю источника, функция BltFast() справится с задачей и обрежет выступающую часть копируемой области. Если же отсечение происходит по верхнему или левому краю, приходится работать с функцией Blt(), потому что BltFast() не позволяет задать прямоугольную область приемника. После выполнения блиттинга BltSurface() возвращает TRUE как признак успешного завершения.

Восстановление поверхностей

Наше приложение благополучно инициализируется и выводит графические данные. Теперь необходимо справиться с возможной потерей поверхностей. При рассмотрении функции DirectDrawWin::PreDrawScene мы видели, что DirectDrawWin вызывает виртуальную функцию RestoreSurfaces(), чтобы производный класс получил возможность восстановить потерянные поверхности. Функция RestoreSurfaces() отвечает за восстановление как потерянной памяти поверхности, так и ее содержимого. Функция BounceWin::RestoreSurfaces() выглядит так:

void BounceWin::RestoreSurfaces() {

 if (surf1->IsLost()==FALSE) return;

 CString filename;

 if (GetCurDisplayDepth()==8) filename="tri08.bmp";

 else filename="tri24.bmp";

 surf1->Restore();

 LoadSurface(surf1, filename);

}

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

Завершение

Как бы ни была хороша программа Bounce, рано или поздно вам захочется убрать ее с экрана. Нажатие клавиши Escape завершает работу программы. Это происходит в обработчике OnKeyDown():

void bounceWin::OnKeyDown(UINT nChar, UINT nRepCnt, UINT nFlags) {

 if (nChar==VK_ESCAPE) PostMessage(WM_CLOSE);

 DirectDrawWin::OnKeyDown(nChar, nRepCnt, nFlags);

}

Приложение завершает работу, отправляя сообщение WM_CLOSE. В нашем приложении на это сообщение реагирует и класс окна, и класс приложения. Класс окна отвечает сообщением WM_DESTROY, для которого в DirectDrawWin предусмотрен обработчик OnDestroy(). Класс DirectDrawWin в данном обработчике освобождает объекты DirectDraw и всю память, занимаемую приложением. Функция OnDestroy() выглядит так:

void DirectDrawWin::OnDestroy() {

 if (primsurf) primsurf->Release(), primsurf=0;

  if (palette) palette->Release(), palette=0;

  if (ddraw2) ddraw2->Release(), ddraw2=0;

  for (int i=0;i<totaldrivers;i++) {

   if (driver[i].guid) delete[] driver[i].guid;

   free(driver[i].desc);

   free(driver[i].name);

  }

 }

}

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

Класс приложения обрабатывает завершение в функции ExitInstance(), в которой удаляется класс окна:

int DirectDrawApp::ExitInstance() {

 delete ddwin;

 return CWinApp::ExitInstance();

}

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

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

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

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

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

Структура приложения

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

Инициализация

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

int DirectDrawWin::OnCreate(LPCREATESTRUCT) {

 LPDIRECTDRAW ddraw1;

 DirectDrawCreate(0, &ddraw1, 0);

 ddraw1->QueryInterface(IID_IDirectDraw2, (void**)&ddraw2);  ddraw1->Release(), ddraw1=0;  ddraw2->SetCooperativeLevel(GetSafeHwnd(), DDSCL_NORMAL);

 DetectDisplayMode();

 if (CreateFlippingSurfaces()==FALSE) {

  AfxMessageBox("CreateFlippingSurfaces() failed");

  return FALSE;

 }

 if (CreateCustomSurfaces()==FALSE) {

  AfxMessageBox("CreateCustomSurfaces() failed");

  return FALSE;

 }

 return 0;

}

Сначала указатель на интерфейс DirectDraw(ddraw1) инициализируется функцией DirectDrawCreate(). Указатель ddraw1, как и в полноэкранной версии, используется только для получения указателя на интерфейс DirectDraw2, после чего освобождается.

Затем функция OnCreate() вызывает функцию SetCooperativeLevel(). В полноэкранном приложении уровень кооперации определялся тремя флагами: DDSCL_EXCLUSIVE, DDSCL_FULLSCREEN и DDSCL_ALLOWMODEX. В данном случае используется только флаг DDSCL_NORMAL.

Функция DetectDisplayMode() инициализирует некоторые переменные класса DirectDrawWin. Она выглядит так:

BOOL DirectDrawWin::DetectDisplayMode() {

 DDSURFACEDESC desc;

 ZeroMemory(&desc, sizeof(desc));

 desc.dwSize=sizeof(desc);

 if (ddraw2->GetDisplayMode(&desc)!=DD_OK) {

  TRACE("GetDisplayMode() failed\n");

  return FALSE;

 }

 displayrect.left=0;

 displayrect.top=0;

 displayrect.right=desc.dwWidth;

 displayrect.bottom=desc.dwHeight;

 displaydepth=desc.ddpfPixelFormat.dwRGBBitCount;

 return TRUE;

}

Функция DetectDisplayMode() с помощью функции GetDisplayMode() интерфейса DirectDraw получает информацию о текущем видеорежиме Windows. Говоря точнее, разрешение экрана и глубина пикселей текущего видеорежима сохраняются в переменных displayrect и displaydepth.

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

Листинг 3.4. Функция CreateFlippingSurfaces() в оконном приложении

BOOL DirectDrawWin::CreateFlippingSurfaces() {

 HRESULT r;

 DDSURFACEDESC desc;

 desc.dwSize = sizeof(desc);

 desc.dwFlags = DDSD_CAPS;

 desc.ddsCaps.dwCaps = DDSCAPS_PRIMARYSURFACE;

 r=ddraw2->CreateSurface(&desc, &primsurf, 0);

 if (r!=DD_OK) {

  TRACE("FAILED to create 'primsurf'\n");

  return FALSE;

 }

 r=ddraw2->CreateClipper(0, &clipper, 0);

 if (r!=DD_OK) {

  TRACE("CreateClipper() failed\n");

  return FALSE;

 }

 r=clipper->SetHWnd(0, GetSafeHwnd());

 if (r!=DD_OK) {

  TRACE("SetHWnd() failed\n");

  return FALSE;

 }

 r=primsurf->SetClipper(clipper);

 if (r!=DD_OK) {

  TRACE("SetClipper() failed\n");

  return FALSE;

 }

 ZeroMemory(&desc, sizeof(desc));

 desc.dwSize = sizeof(desc);

 desc.dwFlags = DDSD_WIDTH | DDSD_HEIGHT | DDSD_CAPS;

 desc.dwWidth = displayrect.Width();

 desc.dwHeight = displayrect.Height();

 desc.ddsCaps.dwCaps = DDSCAPS_OFFSCREENPLAIN | DDSCAPS_VIDEOMEMORY;

 r=ddraw2->CreateSurface(&desc, &backsurf, 0);

 if (r!=DD_OK) {

  TRACE("failed to create 'backsurf' in video\n");

  videobacksurf=FALSE;

 } else {

  TRACE("Created backsurf in video\n");

  videobacksurf=TRUE;

 }

 return TRUE;

}

Сначала мы создаем первичную поверхность. В полноэкранном варианте код выглядит по-другому, потому что здесь создается обычная, несоставная первичная поверхность. В структуре DDSURFACEDESC мы описываем первичную поверхность, используя только флаг DDSCAPS_PRIMARYSURFACE. Затем описанная поверхность создается функцией CreateSurface() интерфейса DirectDraw.

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

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

Далее объект отсечения присоединяется к первичной поверхности приложения функцией SetClipper() интерфейса DirectDrawSurface. После такого присоединения можно осуществлять блиттинг на первичную поверхность с помощью функции Blt() интерфейса DirectDrawSurface. Использовать функцию BltFast() нельзя, потому что она не поддерживает отсечения.

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

Функция CreateFlippingSurfaces() пытается создать «идеальный» вторичный буфер, для чего используются флаг DDSCAPS_VIDEOMEMORY и функция CreateSurface(). Если вызов заканчивается успешно, флаг videobacksurf получает значение TRUE, а функция завершает работу. В противном случае вторичный буфер не создается, а флагу videobacksurf присваивается значение FALSE.

В том варианте вторичный буфер создается приложением в системной памяти позднее, в обработчике OnSize(). Функция OnSize() вызывается при изменении размеров окна приложения. Создавая вторичный буфер по размерам клиентской области окна, мы экономим память. Функция OnSize() выглядит так:

void DirectDrawWin::OnSize(UINT nType, int cx, int cy) {

 CWnd::OnSize(nType, cx, cy);

 CFrameWnd::GetClientRect(&clientrect);

 CFrameWnd::ClientToScreen(&clientrect);

 if (videobacksurf) return;

 DDSURFACEDESC desc;

 ZeroMemory(&desc, sizeof(desc));

 desc.dwSize = sizeof(desc);

 desc.dwFlags = DDSD_WIDTH | DDSD_HEIGHT | DDSD_CAPS;

 desc.dwWidth = clientrect.Width();

 desc.dwHeight = clientrect.Height();

 desc.ddsCaps.dwCaps = DDSCAPS_OFFSCREENPLAIN | DDSCAPS_SYSTEMMEMORY;

 if (backsurf) backsurf->Release(), backsurf=0;

 HRESULT r=ddraw2->CreateSurface(&desc, &backsurf, 0);

 if (r!=DD_OK)  {

  TRACE("failed to create 'backsurf'\n");

  return;

 } else TRACE("backsurf w=%d h=%d\n", clientrect.Width(), clientrect.Height());

}

Инициализация приложения завершается вызовом функций StorePixelFormatData() и CreateCustomSurfaces(), происходящим в обработчике OnCreate(). Обе функции ведут себя точно так же, как и в полноэкранном приложении.

Графический вывод

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

void BounceWin::DrawScene() {

 ClearSurface(backsurf, 0);

 CRect client=GetClientRect();

 int width=client.Width();

 int height=client.Height();

 x+=xinc;

 y+=yinc;

 if (x<-160 || x>width-160) {

  xinc=-xinc;

  x+=xinc;

 }

 if (y<-100 || y>height-100) {

  yinc=-yinc;

  y+=yinc;

 }

 BltSurface(backsurf, surf1, x, y);

 int offsetx=client.left;

 int offsety=client.top;

 RECT srect;

 srect.left=0;

 srect.top=0;

 srect.right=client.Width();

 srect.bottom=client.Height();

 RECT drect;

 drect.left=offsetx;

 drect.top=offsety;

 drect.right=offsetx+client.Width();

 drect.bottom=offsety+client.Height();

 primsurf->Blt(&drect, backsurf, &srect, DDBLT_WAIT, 0);

}

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

Вторая блит-операция копирует содержимое вторичного буфера на первичную поверхность. На этот раз используется функция Blt(), поскольку к первичной поверхности присоединен объект отсечения. Структуры srect и drect типа RECT определяют области источника и приемника, участвующие в блиттинге. Заметьте, что при вычислении области приемника используются переменные offsetx и offsety, в которых хранятся координаты клиентской области окна. Если убрать эти смещения из структуры drect, программа всегда будет выводить изображение в левом верхнем углу экрана независимо от расположения окна.

Заключение

В этой главе мы изучили почти весь код, сгенерированный AppWizard. Рассмотренное нами базовое приложение нетрудно изменить, поэтому попробуйте немного поэкспериментировать. Например, попытайтесь добавить в программу Bounce дополнительные поверхности или замените вызовы BltSurface() на BltFast() и посмотрите, что получится.

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

Глава 4. Видеорежимы и частота смены кадров

В главе 1 я упоминал функции EnumDisplayModes() и SetDisplayMode() интерфейса DirectDraw и говорил о том, что они применяются для обнаружения и активизации видеорежимов. Здесь эти функции будут применены на практике. Сначала мы познакомимся с общими принципами переключения видеорежимов, а затем рассмотрим две демонстрационных программы: Switch и SuperSwitch. Программа Switch выводит меню с обнаруженными видеорежимами и позволяет последовательно активизировать каждый из них. Программа SuperSwitch в дополнение к этому позволяет выбрать частоту смены кадров для каждого видеорежима.

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

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

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

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

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

Функция SetDisplayMode()

Существуют две версии функции SetDisplayMode(). Первая из них принадлежит интерфейсу DirectDraw и вызывается с тремя аргументами. Вторая версия принадлежит интерфейсу DirectDraw2 и вызывается с пятью аргументами. Прототип первой функции выглядит так:

HRESULT SetDisplayMode(DWORD width, DWORD height, DWORD depth);

СОВЕТ

Для любознательных читателей

Заглянув в заголовочный файл DirectDraw (ddraw.h), вы не найдете в нем этого прототипа. Это объясняется тем, что все функции DirectDraw описываются на IDL (языке определения интерфейсов) спецификации COM. На IDL функция SetDisplayMode() выглядит так:

STDMETHOD(SetDisplayMode)(THIS_ DWORD, DWORD, DWORD) PURE;

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

Функция SetDisplayMode(), как и большинство функций DirectX API, возвращает значение типа HRESULT — 32-разрядную величину с описанием результата вызова функции. Ее значение DD_OK показывает, что вызов оказался успешным.

Версия SetDisplayMode() из интерфейса DirectDraw получает три аргумента типа DWORD. Эти аргументы определяют разрешение экрана и глубину пикселей нужного видеорежима, поэтому стандартный видеорежим VGA 640×480×8 активизируется так:

ddraw1->SetDisplayMode(640, 480, 8);

Выглядит довольно просто, поэтому давайте перейдем к версии SetDisplayMode() из интерфейса DirectDraw2. Ее традиционный прототип выглядит так:

HRESULT SetDisplayMode(DWORD width, DWORD height, DWORD depth,  DWORD refreshrate, DWORD flags);

В этой версии появляются два дополнительных аргумента: частота смены кадров и двойное слово, которое может быть использовано в будущих версиях DirectDraw, а пока должно быть равно нулю. В расширенной версии SetDisplayMode() стандартный видеорежим VGA 640×480×8 можно активизировать так:

ddraw1->SetDisplayMode(640, 480, 8, 0, 0);

В данном случае вместо частоты смены кадров передается 0; это означает, что должна быть использована частота, принятая по умолчанию. Кроме того, можно указать конкретное значение частоты (60 Гц в следующем примере):

ddraw1->SetDisplayMode(640, 480, 8, 60, 0);

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

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

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

HRESULT EnumDisplayModes(DWORD flags, LPDDSURFACEDESC desc, LPVOID callbackdata, LPDDENUMMODESCALLBACK callback);

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

ddraw->EnumDisplayModes(0, 0, this, DisplayModeAvailable);

Первый и второй аргументы равны нулю; это означает, что мы не указываем флаги и критерии видеорежимов. Поскольку флаги (первый аргумент) не указаны, каждый обнаруженный видеорежим включается в список один и только один раз. Если бы в первом аргументе был указан флаг DDEDM_REFRESHRATES, каждый видеорежим вошел бы в список столько раз, сколько различных частот смены кадров в нем поддерживается. Такая возможность рассматривается ниже в этой главе при работе с частотами смены кадров в программе SuperSwitch.

Функция ActivateDisplayMode()

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

Листинг 4.1. Функция DirectDrawWin::ActivateDisplayMode()

BOOL DirectDrawWin::ActivateDisplayMode(int mode) {

 if (mode<0 || mode>=totaldisplaymodes) return FALSE;

 DWORD width = displaymode[mode].width;

 DWORD height = displaymode[mode].height;

 DWORD depth = displaymode[mode].depth;

 displayrect.left=0;

 displayrect.top=0;

 displayrect.right=width;

 displayrect.bottom=height;

 displaydepth=depth;

 ddraw2->SetDisplayMode(width, height, depth, rate, 0);

 curdisplaymode = mode;

 TRACE("------------------- %dx%dx%d (%dhz) ---------------\n", width, height, depth, rate);

 if (CreateFlippingSurfaces()==FALSE) {

  FatalError("CreateFlippingSurfaces() failed");

  return FALSE;

 }

 StorePixelFormatData();

 if (CreateCustomSurfaces()==FALSE) {

  FatalError("CreateCustomSurfaces() failed");

  return FALSE;

 }

 return TRUE;

}

Функция ActivateDisplayMode() получает один аргумент — индекс в отсортированном списке обнаруженных видеорежимов. Сначала индекс проверяется на правильность. Если он соответствует допустимому элементу массива displaymode, высота, ширина и глубина заданного режима извлекаются из массива и используются для инициализации переменных displayrect и displaydepth. Затем атрибуты видеорежима используются при вызове функции SetDisplayMode(), активизирующей новый видеорежим.

Далее функция CreateFlipingSurfaces() создает первичную поверхность со вторичным буфером, а функция StorePixelFormatData() проверяет, не устарел ли формат пикселей DirectDrawWin (форматы пикселей подробно рассматриваются в главе 5). Наконец, мы вызываем функцию CreateCustomSurfaces(), отвечающую за создание вспомогательных поверхностей приложения.

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

Программа Switch

Программа Switch — полноэкранное приложение DirectDraw, которое выводит меню всех поддерживаемых видеорежимов и позволяет активизировать любой из них. На рис. 4.1 показано, как она выглядит.

Рис. 4.1. Программа Switch

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

В программе Switch мы научимся:

• переключать видеорежимы;

• выводить текст на поверхностях DirectDraw;

• рассчитывать FPS приложения;

• работать с цветовыми ключами. 

Структура приложения

Программа Switch, как и все остальные программы в этой книге, была создана с помощью DirectDraw AppWizard, так что ее структура покажется вам знакомой, если вы прочитали главу 3. Реализация программы основана на двух классах, SwitchWin и SwitchApp, производных от классов DirectDrawWin и DirectDrawApp соответственно. Класс SwitchApp остался в том виде, в котором он был сгенерирован AppWizard, и потому дальнейшему обсуждению не подлежит.

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

Вывод текста

Самый простой способ вывести текст на поверхность — получить у Windows DC (контекст устройства) с помощью функции GetDC() интерфейса DirectDrawSurface. После этого можно вывести текст на поверхность стандартными функциями TextOut() и TextOutExt() и освободить DC функцией DirectDrawSurface::ReleaseDC(). Атрибуты текста (цвет, фон и способ вывода) выбираются следующими функциями Win32:

• SelectObject()

• SetBkMode()

• SetBkColor()

• SetTextColor()

Мы воспользуемся этими функциями в программе Switch для вывода меню видеорежимов и значения FPS.

Вычисление FPS

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

Чтобы вычислить FPS во время работы приложения, необходимо производить периодические измерения. К сожалению, скорость работы приложения может изменяться в зависимости от сложности графического вывода и объема внутренних вычислений. Кроме того, Windows замедляет работу приложения при передаче части процессорного времени другим приложениям или при переносе содержимого памяти на диск. В момент запуска приложение обычно работает медленнее, потому что Windows начинает сбрасывать данные на диск. Только после того, как Windows «успокоится» и перестанет работать с диском, можно будет получить достоверные значения FPS.

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

Для хронометража используется функция Win32 timeGetTime(), которая возвращает количество миллисекунд, прошедших с момента запуска Windows. В программе Switch функция timeGetTime() вызывается после каждых 100 кадров; значение FPS равно 100, разделенному на количество прошедших секунд.

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

Класс SwitchWin

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

Листинг 4.2. Объявление класса SwitchWin

class SwitchWin : public DirectDrawWin {

public:

 SwitchWin();

protected:

 //{{AFX_MSG(SwitchWin)

 afx_msg void OnKeyDown(UINT nChar, UINT nRepCnt, UINT nFlags);

 //}}AFX_MSG

 DECLARE_MESSAGE_MAP()

private:

 int SelectDriver();

 int SelectInitialDisplayMode();

 BOOL CreateCustomSurfaces();

 void DrawScene();

 void RestoreSurfaces();

 BOOL CreateMenuSurface();

 BOOL UpdateMenuSurface();

 BOOL CreateFPSSurface();

 BOOL UpdateFPSSurface();

private:

 LPDIRECTDRAWSURFACE bmpsurf;

 int x, y;

 int xinc, yinc;

 LPDIRECTDRAWSURFACE menusurf;

 int selectmode;

 LPDIRECTDRAWSURFACE fpssurf;

 RECT fpsrect;

 BOOL displayfps;

 DWORD framecount;

 HFONT smallfont, largefont;

};

Класс SwitchWin содержит всего одну открытую (public) функцию — конструктор класса (вскоре мы его рассмотрим). В классе также присутствует функция OnKeyDown() — обработчик сообщений, созданный ClassWizard (закомментированные директивы AFX, окружающие функцию OnKeyDown(), используются ClassWizard для поиска функций-обработчиков). Мы воспользуемся этой функцией для обработки нажимаемых клавиш — стрелок, Enter и незаменимой клавиши Escape.

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

• SelectDriver()

• SelectInitialDisplayMode()

• CreateCustomSurfaces()

• DrawScene()

• RestoreSurfaces()

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

Функция CreateCustomSurfaces() вызывается DirectDrawWin при активизации нового видеорежима; мы воспользуемся этой функцией для создания и подготовки поверхностей программы Switch. Функция DrawScene() отвечает за обновление экрана; она будет использоваться для отображения анимации, меню видеорежимов и значения FPS. Наконец, функция RestoreSurfaces() вызывается классом DirectDrawWin при необходимости восстановить потерянные поверхности. Эта функция восстанавливает не только сами поверхности, но и (для особо важных поверхностей) их содержимое.

Затем класс SwitchWin объявляет четыре функции, специфические для программы Switch:

• CreateMenuSurface()

• UpdateMenuSurface()

• CreateFPSSurface()

• UpdateFPSSurface()

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

Закрытые переменные, объявленные в конце, предназначены для отображения анимации, меню видеорежимов и FPS, а также для работы со шрифтами средствами Win32.

Переменная bmpsurf — указатель на интерфейс DirectDrawSurface, через который мы будем обращаться к данным перемещаемого растра, а переменные x, y, xinc и yinc определяют его положение.

Указатель menusurf используется для доступа к поверхности меню видеорежимов, а в целой переменной selectmode хранится индекс текущего активного видеорежима.

Следующие переменные списка связаны с выводом значения FPS. Переменная fpssurf — указатель на интерфейс DirectDrawSurface, через который производится доступ к поверхности FPS. Структура типа RECT (fpsrect) содержит размеры поверхности fpssurf. Логическая переменная displayfps управляет отображением значения FPS, а в переменной framecount хранится количество кадров, выведенных в очередном временном интервале измерения FPS.

Две последние переменные, smallfont и largefont, имеют тип HFONT. Это логические номера шрифтов Win32, используемые для вывода текста на поверхностях menusurf и fpssurf.

Инициализация приложения

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

SwitchWin::SwitchWin(){

 bmpsurf=0;

 x=y=0;

 xinc=8;

 yinc=1;

 menusurf=0;

 fpssurf=0;

 vlargefont = CreateFont(28, 0, 0, 0,    FW_NORMAL, FALSE, FALSE, FALSE,   ANSI_CHARSET,    OUT_DEFAULT_PRECIS,   CLIP_DEFAULT_PRECIS,    DEFAULT_QUALITY,   VARIABLE_PITCH,    "Arial");

 smallfont = CreateFont(14, 0, 0, 0,    FW_NORMAL, FALSE, FALSE, FALSE,   ANSI_CHARSET,    OUT_DEFAULT_PRECIS,   CLIP_DEFAULT_PRECIS,    DEFAULT_QUALITY,   VARIABLE_PITCH,    "Arial");

}

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

После того как объект SwitchWin будет создан, DirectDrawWin вызывает функции SelectDriver() и SelectInitialDisplayMode(). Поскольку в программе Switch обе функции ведут себя стандартным образом (как описано в главе 3), мы не будем их рассматривать.

Затем класс DirectDrawWin вызывает функцию SwitchWin::CreateCustomSurfaces(), в которой подготавливает три поверхности, используемые программой Switch:

BOOL SwitchWin::CreateCustomSurfaces() {

 int displaydepth=GetCurDisplayDepth();

 CString filename;

 if (displaydepth==8) filename="tri08.bmp";

 else filename="tri24.bmp";

 bmpsurf=CreateSurface(filename, TRUE);

 if (bmpsurf==0) {

  TRACE("surface creation failed\n");

  return FALSE;

 }

 selectmode=GetCurDisplayMode();

 CreateMenuSurface();

 UpdateMenuSurface();

 CreateFPSSurface();

 return TRUE;

}

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

Затем происходит инициализация самой поверхности и переменных, связанных с видеорежимом. Переменной selectmode присваивается значение, зависящее от текущего видеорежима. Это значение используется для выделения активного видеорежима в меню. Указатель на поверхность меню видеорежимов (menusurf) инициализируется вызовами функций CreateMenuSurface() и UpdateMenuSurface().

Наконец, переменные поверхности FPS инициализируются функцией Create FPSSurface(). Мы рассмотрим ее позднее, после функций CreateMenuSurface() и UpdateMenuSurface().

Функция CreateMenuSurface() выглядит так:

BOOL SwitchWin::CreateMenuSurface() {

 if (menusurf) menusurf->Release(), menusurf=0;

 menusurf=CreateSurface(menuwidth, menuheight);

 if (menusurf==0) Fatal("SwitchWin::CreateMenuSurface() failed\n");

 DDCOLORKEY ddck;

 ddck.dwColorSpaceLowValue = 0;

 ddck.dwColorSpaceHighValue = 0;

 menusurf->SetColorKey(DDCKEY_SRCBLT, &ddck);

 return TRUE;

}

Прежде всего CreateMenuSurface() освобождает любые поверхности, созданные ранее. Новая поверхность создается функцией CreateSurface(). Доступ к ней осуществляется через переменную menusurf. Затем мы назначаем новой поверхности цветовой ключ с помощью структуры DDCOLORKEY и функции SetColorKey() интерфейса DirectDrawSurface.

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

Мы назначаем цветовой ключ поверхности меню с помощью структуры DDCOLORKEY и функции SetColorKey(). Оба поля DDCOLORKEY обнуляются (некоторые видеокарты позволяют задавать интервалы цветовых ключей, но в нашем случае используется всего один цвет). Это означает, что пиксели поверхности, равные нулю, не будут копироваться при блит-операциях с активным цветовым ключом.

После того как поверхность меню будет создана функцией CreateMenuSurface(), она заполняется с помощью функции UpdateMenuSurface(). Внутри последней для вывода текста на поверхность используются функция GetDC() интерфейса DirectDrawSurface и текстовые функции Win32. Функция UpdateMenuSurface() приведена в листинге 4.3.

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

BOOL SwitchWin::UpdateMenuSurface() {

 char buf[40];

 int len;

 int hdrlen=strlen(headertext);

 ClearSurface(menusurf, 0);

 HDC hdc;

 menusurf->GetDC(&hdc);

 SelectObject(hdc, largefont);

 SetBkMode(hdc, TRANSPARENT);

 SetTextColor(hdc, textshadow);

 TextOut(hdc, 1, 1, headertext, hdrlen);

 SetTextColor(hdc, textcolor);

 TextOut(hdc, 0, 0, headertext, hdrlen);

 SelectObject(hdc, smallfont);

 int nmodes=GetNumDisplayModes();

 if (nmodes>maxmodes) nmodes=maxmodes;

 int rows=nmodes/menucols;

 if (nmodes%menucols) rows++;

 for (int i=0; i<nmodes; i++) {

  int x=(i/rows)*colwidth+2;

  int y=(i%rows)*rowheight+reservedspace;

  DWORD w,h,d;

  GetDisplayModeDimensions(i, w, h, d);

  len=sprintf(buf, "%dx%dx%d", w, h, d);

  SetTextColor(hdc, textshadow);

  TextOut(hdc, x+1, y+1, buf, len);

  if (i==selectmode) SetTextColor(hdc, brighttextcolor);

  else SetTextColor(hdc, textcolor);

  TextOut(hdc, x, y, buf, len);

 }

 len=sprintf(buf, "[Arrows] [Enter] [Escape]");

 SetTextColor(hdc, textshadow);

 TextOut(hdc, 3, 186, buf, len);

 SetTextColor(hdc, textcolor);

 TextOut(hdc, 2, 185, buf, len);

 menusurf->ReleaseDC(hdc);

 return TRUE;

}

Функция UpdateMenuSurface() вызывает ClearSurface() и передает ей в качестве аргументов указатель menusurf и 0. В результате все пиксели поверхности обнуляются. Так как ноль является цветовым ключом для данной поверхности, вся поверхность становится прозрачной.

Теперь все готово к выводу текста. Обратите внимание на функцию SetBkMode(), которая указывает, что текст должен выводиться в прозрачном режиме. Это значит, что функция TextOut() будет выводить только сам текст, без фона, благодаря чему наш прозрачный фон останется в неприкосновенности. Цвет текста задается функцией Win32 SetTextColor(). В этой программе используются три цвета: первый — для обычного текста, второй — для затененного текста, и третий — для текста, выделенного подсветкой. Каждая текстовая строка выводится дважды — сначала затемненным, а потом обычным цветом; затененный текст смещен на один пиксель по отношению к обычному. После завершения вывода текста вызывается функция ReleaseDC() интерфейса DirectDrawSurface.

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

BOOL SwitchWin::CreateFPSSurface() {

 static const char dummystr[]="000 FPS";

 HDC hdc = ::GetDC(0);

 SelectObject(hdc, smallfont);

 SIZE size;

 GetTextExtentPoint(hdc, dummystr, strlen(dummystr), &size);

 ::ReleaseDC(0, hdc);

 fpsrect.left=0;

 fpsrect.top=0;

 fpsrect.right=size.cx+1;

 fpsrect.bottom=size.cy+1;

 fpssurf=CreateSurface(fpsrect.right, fpsrect.bottom);

 DDCOLORKEY ddck;

 ddck.dwColorSpaceLowValue = 0;

 ddck.dwColorSpaceHighValue = 0;

 fpssurf->SetColorKey(DDCKEY_SRCBLT, &ddck);

 framecount=0;

 displayfps=FALSE;

 return TRUE;

}

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

По аналогии с menusurf мы обеспечиваем прозрачность, назначая поверхности нулевой цветовой ключ (с помощью функции SetColorKey() интерфейса DirectDrawSurface). Наконец, переменная framecount (предназначенная для подсчета кадров за текущий интервал хронометража) обнуляется, а логической переменной displayfps присваивается значение FALSE, согласно которому поверхность FPS пока не должна отображаться на экране.

Хотя мы создали поверхность fpssurf, она осталась неинициализированной. В отличие от поверхности menusurf, инициализируемой функцией UpdateMenuSurface(), мы пока не можем инициализировать поверхность FPS, потому что у нас еще нет выводимого значения. Приложение только что было запущено (или только что перешло в другой видеорежим), так что вывод любого значения FPS был бы необоснованным.

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

Графический вывод

Графическим выводом в программе Switch занимается функция SwitchWin::DrawScene(). Она отвечает за подготовку кадра во вторичном буфере и переключение страниц, благодаря которому новый кадр отображается на экране. Код функции DrawScene() содержится в листинге 4.4.

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

void SwitchWin::DrawScene() {

 ClearSurface(backsurf, 0);

 BltSurface(backsurf, bmpsurf, x, y);

 x+=xinc;

 y+=yinc;

 const CRect& displayrect=GetDisplayRect();

 if (x<-160 || x>displayrect.right-160) {

  xinc=-xinc;

  x+=xinc;

 }

 if (y<-100 || y>displayrect.bottom-100)  {

  yinc=-yinc;

  y+=yinc;

 }

 backsurf->BltFast(0, 0, menusurf, 0,    DDBLTFAST_SRCCOLORKEY | DDBLTFAST_WAIT);

 UpdateFPSSurface();

 if (displayfps) {

  int x=displayrect.right-fpsrect.right-1;

  int y=displayrect.bottom-fpsrect.bottom-1;

  backsurf->BltFast(x, y, fpssurf, 0, DDBLTFAST_SRCCOLORKEY | DDBLTFAST_WAIT );

 }

 primsurf->Flip(0, DDFLIP_WAIT);

} 

Сначала функция DrawScene() подготавливает вторичный буфер, стирая его содержимое функцией ClearSurface(). Мы заполняем вторичный буфер нулями, но, поскольку он не имеет цветового ключа, 0 в данном случае имеет иной смысл, чем для поверхностей menusurf и fpssurf. Для вторичных буферов 0 означает черный цвет (в большинстве случаев).

СОВЕТ

Черный цвет не гарантирован 

По умолчанию DirectDraw резервирует два элемента палитры: для черного (индекс 0) и для белого (индекс 255). Поэтому обычно заполнение поверхности нулями равносильно ее заливке черным цветом. Тем не менее в палитрах, созданных с флагом DDSCAPS_ALLOW256, можно задавать все 256 элементов.

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

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

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

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

Затем копируется поверхность меню. Она всегда выводится в левом верхнем углу экрана, а ее размеры совпадают с размерами видеорежима с наименьшим разрешением (320×200), так что отсечение не понадобится. Следовательно, мы можем воспользоваться функцией BltFast() интерфейса DirectDrawSurface. Первые два аргумента BltFast() определяют область приемника для наложения копии (оба аргумента равны нулю, что означает левый верхний угол). Третий аргумент является указателем на поверхность-источник, а четвертый описывает копируемую прямоугольную область источника. Вместо прямоугольника мы передаем 0, тем самым показывая, что копироваться должна вся поверхность.

В последний аргумент функции BltFast() включены флаги DDBLTFAST_SRCCOLORKEY и DDBLTFAST_WAIT. Первый флаг активизирует цветовой ключ поверхности-источника. Если бы он не был указан, то во время блиттинга цветовой ключ поверхности menusurf был бы проигнорирован, а пиксели с нулевыми значениями выводились бы черным цветом. Второй флаг показывает, что выход из функции BltFast() должен произойти лишь после завершения копирования.

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

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

BOOL SwitchWin::UpdateFPSSurface() {

 static const long interval=100;

 framecount++;

 if (framecount==interval) {

  static DWORD timenow;

  static DWORD timethen;

  timethen=timenow;

  timenow=timeGetTime();

  double seconds=double(timenow-timethen)/(double)1000;

  int fps=(int)((double)framecount/seconds);

  static char buf[10];

  int len=sprintf(buf, "%d FPS", fps);

  ClearSurface(fpssurf, 0);

  HDC hdc;

  fpssurf->GetDC(&hdc);

  SelectObject(hdc, smallfont);

  SetBkMode(hdc, TRANSPARENT);

  SetBkColor(hdc, RGB(0,0,0));

  SetTextColor(hdc, textshadow);

  TextOut(hdc, 1, 1, buf, len);

  SetTextColor(hdc, brighttextcolor);

  TextOut(hdc, 0, 0, buf, len);

  fpssurf->ReleaseDC(hdc);

  displayfps=TRUE;

  framecount=0;

 }

 return TRUE;

}

Функция UpdateFPSSurface() использует переменную framecount для подсчета выведенных кадров. Переменная framecount обнуляется в двух случаях: при изменении видеорежима и при обновлении поверхности fpssurf заново вычисленным значением FPS.

Каждый раз, когда заданное количество кадров будет подготовлено и выведено на экран, функция timeGetTime() подсчитывает количество прошедших миллисекунд. По этой величине определяется текущий FPS приложения.

Значение FPS преобразуется в строку и выводится на поверхность FPS (после предварительной очистки поверхности функцией ClearSurface()). После вывода текста переменная framecount обнуляется, и начинается новый интервал хронометража. Наконец, переменной displayfps присваивается значение TRUE; оно говорит о том, что на поверхности FPS находится допустимое значение, которое следует вывести на экран.

Возвращаясь к функции DrawScene() (см. листинг 4.4), мы видим, что код отображения fpssurf и переключения страниц выглядит так:

if (displayfps) {

 int x=displayrect.right-fpsrect.right-1;

 int y=displayrect.bottom-fpsrect.bottom-1;

 backsurf->BltFast(x, y, fpssurf, 0, DDBLTFAST_SRCCOLORKEY | DDBLTFAST_WAIT);

}

primsurf->Flip(0, DDFLIP_WAIT);

Если флаг displayfps равен TRUE, поверхность FPS следует вывести на экран. Однако сначала мы рассчитываем ее положение по известным размерам видеорежима и поверхности. Затем мы копируем поверхность fpssurf функцией BltFast(), после чего выводим на экран вторичный буфер функцией Flip() интерфейса DirectDrawSurface.

Задача функции DrawScene() выполнена — все три поверхности программы Switch выведены на экран. Тем не менее изучение приложения еще не закончено. Мы должны рассмотреть обработку пользовательского ввода.

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

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

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

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

void SwitchWin::OnKeyDown(UINT nChar, UINT nRepCnt, UINT nFlags) {

 int newindex;

 int nmodes=GetNumDisplayModes();

 if (nmodes>maxmodes)  nmodes=maxmodes;

 int rows=nmodes/menucols;

 if (nmodes%menucols)  rows++;

 switch (nChar) {

 case VK_ESCAPE:

  PostMessage(WM_CLOSE);

  break;

 case VK_UP:

  newindex=selectmode-1;

  if (newindex>=0) {

   selectmode=newindex;

   UpdateMenuSurface();

  }

  break;

 case VK_DOWN:

  newindex=selectmode+1;

  if (newindex<nmodes)  {

   selectmode=newindex;

   UpdateMenuSurface();

  }

  break;

 case VK_LEFT:

  newindex=selectmode-rows;

  if (newindex>=0) {

   selectmode=newindex;

   UpdateMenuSurface();

  }

  break;

 case VK_RIGHT:

  newindex=selectmode+rows;

  if (newindex<nmodes) {

   selectmode=newindex;

   UpdateMenuSurface();

  }

  break;

 case VK_RETURN:

  if (selectmode != GetCurDisplayMode()) {

   ActivateDisplayMode(selectmode);

   x=y=0;

  }

  break;

 case 'S':

  SaveSurface(primsurf, "switch.bmp");

  break;

 case 'M':

  SaveSurface(menusurf, "menusurf.bmp");

  break;

 case 'F':

  SaveSurface(fpssurf, "fpssurf.bmp");

  break;

 case 'T':

  SaveSurface(bmpsurf, "trisurf.bmp");

  break;

 default:

  DirectDrawWin::OnKeyDown(nChar, nRepCnt, nFlags);

 }

}

Обработка нажатых клавиш происходит в различных секциях оператора switch. Клавиша Escape (код виртуальной клавиши VK_ESCAPE) приводит к посылке сообщения WM_CLOSE и последующему завершению приложения. При нажатии клавиш со стрелками изменяется индекс текущего видеорежима и вызывается функция UpdateMenuSurface(), которая перерисовывает menusurf в соответствии с произведенными изменениями. При нажатии клавиши Enter (VK_RETURN) вызывается функция ActivateDisplayMode(), которой в качестве аргумента передается индекс режима (при условии, что выбран видеорежим, отличный от текущего). Все остальные клавиши, нажатые пользователем, обрабатываются функцией OnKeyDown() базового класса. 

Восстановление поверхностей 

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

void SwitchWin::RestoreSurfaces() {

 int displaydepth=GetCurDisplayDepth();

 CString filename;

 if (displaydepth==8) filename="tri08.bmp";

 else filename="tri24.bmp";

 if (bmpsurf->IsLost()) {

  bmpsurf->Restore();

  LoadSurface(bmpsurf, filename);

 }

 if (menusurf->IsLost()) {

  menusurf->Restore();

  UpdateMenuSurface();

 }

 if (fpssurf->IsLost()) {

  fpssurf->Restore();

  ClearSurface(fpssurf, 0);

 }

 displayfps=FALSE;

 framecount=0;

}

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

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

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

Восстановление двух других поверхностей происходит несколько иначе, потому что их содержимое не является BMP-файлом. Поверхность menusurf восстанавливается функцией Restore() с последующим вызовом функции UpdateMenuSurface(), в которой происходит стирание и перерисовка поверхности меню. При восстановлении fpssurf мы сначала вызываем Restore(), а потом стираем содержимое поверхности, потому что это содержимое после восстановления оказывается непредсказуемым. Не забывайте, поверхности чаще всего теряются из-за того, что занимаемая ими видеопамять понадобилась другому приложению.

Обратите внимание: мы не восстанавливаем значение, отображаемое на поверхности FPS. Потеря первичной поверхности и вторичного буфера означает, что последнее вычисленное значение FPS, по всей видимости, стало неверным. Наша программа было свернута или уступила фокус другому приложению; в любом случае нельзя с уверенностью сказать, насколько быстро обновляется изображение в данный момент. Вместо того чтобы выводить устаревшее значение FPS, мы очищаем поверхность и присваиваем переменной displayfps значение FALSE, тем самым запрещая вывод поверхности до получения новой величины FPS. Кроме того, мы обнуляем переменную framecount, чтобы перезапустить механизм вычисления FPS.

Вот и все, что касается программы Switch. Пора заняться частотой смены кадров и перейти к приложению SuperSwitch.

Частота смены кадров 

В главе 1 мы узнали, что DirectDraw позволяет приложению задать не только видеорежим, но и частоту смены кадров. Однако перед тем, как писать демонстрационную программу, следует разобраться, что же такое «частота смены кадров».

Частота смены кадров представляет собой скорость обновления экрана. Например, частота в 60 Гц означает, что экран перерисовывается 60 раз в секунду. Данный показатель представляет большой интерес для программистов, работающих с DirectDraw, потому что он управляет скоростью работы приложения. Для полноэкранных приложений DirectDraw с возможностью переключения страниц это происходит автоматически, потому что функция Flip() интерфейса DirectDrawSurface синхронизирует операцию переключения страниц с частотой смены кадров. Такая синхронизация определяет (или, если хотите, ограничивает) скорость, с которой приложение обновляет экран.

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

И все же некоторые частоты смены кадров оставляют желать лучшего. Низкие частоты (особенно ниже 60 Гц) раздражают и обычно плохо подходят для высокопроизводительных приложений. С помощью DirectDraw API ваше приложение может узнать, какие частоты поддерживаются для конкретного видеорежима, и активизировать их по мере необходимости.

Тем не менее подобные «игры» с частотами требуют определенной осторожности. Во-первых, не все видеоустройства позволяют управлять частотой смены кадров. В этом случае вам придется использовать параметры по умолчанию, какими бы они ни были. Кроме того, даже если некоторая частота поддерживается видеокартой, это еще не означает, что она поддерживается монитором. В Windows NT, где DirectDraw не проверяет тип монитора, можно легко включить видеорежим с частотой, при которой на экран выводится сплошной «мусор». Если ваше приложение управляет частотой смены кадров, позаботьтесь о том, чтобы пользователь всегда мог вернуть исходные параметры.

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

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

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

Программа SuperSwitch 

Программа SuperSwitch, как и программа Switch, позволяет установить любой видеорежим, но, кроме того, для выбранного видеорежима можно задать и частоту смены кадров. Основной экран программы SuperSwitch выглядит так же, как и в Switch, но при выборе видеорежима появляется подменю с возможными частотами смены кадров (см. рис. 4.2).

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

Класс SuperSwitchWin 

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

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

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

Листинг 4.6. Объявление класса SuperSwitchWin

class SuperSwitchWin : public DirectDrawWin {

public:

 SuperSwitchWin();

protected:

 //{{AFX_MSG(SuperSwitchWin)

 afx_msg void OnKeyDown(UINT nChar, UINT nRepCnt, UINT nFlags);

 afx_msg int OnCreate(LPCREATESTRUCT lpCreateStruct);

 //}}AFX_MSG

 DECLARE_MESSAGE_MAP()

private:

 int SelectDriver();

 int SelectInitialDisplayMode();

 BOOL CreateCustomSurfaces();

 static HRESULT WINAPI StoreModeInfo(LPDDSURFACEDESC, LPVOID);

 void DrawScene();

 void RestoreSurfaces();

 BOOL CreateModeMenuSurface();

 BOOL UpdateModeMenuSurface();

 BOOL CreateRateMenuSurface();

 BOOL UpdateRateMenuSurface();

 BOOL CreateFPSSurface();

 BOOL UpdateFPSSurface();

private:

 LPDIRECTDRAWSURFACE bmpsurf;

 int x,y;

 int xinc, yinc;

 LPDIRECTDRAWSURFACE modemenusurf;

 int selectmode;

 LPDIRECTDRAWSURFACE ratemenusurf;

 int selectrate;

 int numrates;

 BOOL ratemenu_up;

 LPDIRECTDRAWSURFACE fpssurf;

 RECT fpsrect;

 BOOL displayfps;

 DWORD framecount;

 BOOL include_refresh;

 CArray<DWORD,DWORD> refresh_rates[MAXDISPLAYMODES];

 HFONT smallfont, largefont;

};

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

Другая новая функция — StoreModeInfo(). Эта функция косвенного вызова вызывается при составлении списка частот каждого видеорежима. Как говорилось в главе 3, класс DirectDrawWin имеет для этой цели собственную функцию косвенного вызова (DisplayModeAvailable()). Вместо того чтобы изменять класс DirectDrawWin, мы воспользуемся функцией StoreModeInfo(), приспособленной для целей конкретного приложения. Это означает, что список видеорежимов будет составляться дважды: сначала без частот смены кадров (класс DirectDrawWin), а потом с частотами (класс SuperSwitchWin).

Далее в списке идут четыре новые функции:

• CreateModeMenuSurface()

• UpdateModeMenuSurface()

• CreateRateMenuSurface()

• UpdateRateMenuSurface()

Функции CreateModeMenuSurface() и UpdateModeMenuSurface() — это просто переименованные функции CreateMenuSurface() и UpdateMenuSurface() из программы Switch. Их пришлось переименовать, потому что теперь существуют две поверхности меню: одна — для видеорежимов, а другая — для частот смены кадров. Функции CreateModeMenuSurface() и UpdateModeMenuSurface() работают с поверхностью меню видеорежимов. Две новые функции, CreateRateMenuSurface() и UpdateRateMenuSurface(), предназначены для работы с поверхностью меню частот.

Теперь давайте рассмотрим новые и изменившиеся переменные класса. Указатель menusurf из программы Switch был переименован в modemenusurf по той же причине, по которой были переименованы функции для работы с поверхностью меню видеорежимов. Далее в классе появились шесть новых переменных. Я снова приведу объявления новых переменных класса из листинга 4.6:

LPDIRECTDRAWSURFACE ratemenusurf;

int selectrate;

int numrates;

BOOL ratemenu_up;

BOOL include_refresh;

CArray<DWORD,DWORD> refresh_rates[MAXDISPLAYMODES];

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

Значение логической переменной include_refresh определяется выбором пользователя, сделанным в окне диалога при старте программы. Если эта переменная равна TRUE, программа создает и выводит меню со списком частот для каждого выделенного видеорежима. Если переменная равна FALSE, частоты не отображаются. Наконец, массив refresh_rates предназначен для хранения возможных частот каждого видеорежима. Содержимое массива определяется с помощью косвенно вызываемой функции StoreModeInfo() и используется функцией UpdateRateMenusurface(). 

Инициализация приложения 

Как упоминалось выше, перед инициализацией DirectDraw программа SuperSwitch выводит в функции SuperSwitchWin::OnCreate() диалоговое окно. После вывода диалогового окна функция вызывает версию OnCreate() класса DirectDrawWin. Код функции SuperSwitchWin::OnCreate() выглядит так:

int SuperSwitchWin::OnCreate(LPCREATESTRUCT lpCreateStruct) {

 IntroDialog introdialog;

 if (introdialog.DoModal()!=IDOK) return -1;

 include_refresh=introdialog.include_refresh;

 if (DirectDrawWin::OnCreate(lpCreateStruct)==-1) return -1;

 if (include_refresh) ddraw2->EnumDisplayModes(DDEDM_REFRESHRATES, 0, this, StoreModeInfo);

 return 0;

}

Сначала мы создаем объект класса IntroDialog — этот класс-оболочка был сгенерирован ClassWizard. Диалоговое окно отображается функцией CDialog::DoModal(), которая возвращает код IDOK в случае нажатия пользователем кнопки OK. Если пользователь закрывает диалоговое окно другим способом (например, нажимая кнопку Cancel), функция OnCreate() возвращает код –1, что для MFC является признаком завершения приложения. Если была нажата кнопка OK, переменной include_refresh присваивается значение в зависимости от состояния флажка в диалоговом окне.

Теперь мы вызываем версию OnCreate() класса DirectDrawWin, где и происходит инициализация DirectDraw. Функция составляет список видеорежимов, активизирует исходный режим и создает поверхности приложения. Если вызов функции OnCreate() завершается неудачей, мы завершаем приложение, возвращая код –1.

Следующий шаг — повторное составление списка видеорежимов. На этот раз при вызове функции EnumDisplayModes() в первом аргументе передается флаг DDEDM_REFRESHRATES, согласно которому каждый видеорежим должен быть включен в список по одному разу для каждой поддерживаемой частоты. В результате мы сможем построить список частот для каждого видеорежима. Четвертый аргумент EnumDisplayModes() — функция косвенного вызова StoreModeInfo(), которая выглядит так:

HRESULT WINAPI SuperSwitchWin::StoreModeInfo(LPDDSURFACEDESC desc, LPVOID p) {

 DWORD w=desc->dwWidth;

 DWORD h=desc->dwHeight;

 DWORD d=desc->ddpfPixelFormat.dwRGBBitCount;

 DWORD r=desc->dwRefreshRate;

 SuperSwitchWin* win=(SuperSwitchWin*)p;

 int index=win->GetDisplayModeIndex(w, h, d);

 win->refresh_rates[index].Add(r);

 return DDENUMRET_OK;

}

Функции StoreModeInfo()> передается указатель на структуру DDSURFACEDESC с описанием очередного видеорежима. В описание входит частота смены кадров (поле dwRefreshRate), а также размеры, по которым определяется индекс режима. Затем этот индекс используется для сохранения частоты видеорежима в массиве.

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

Графический вывод 

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

void SuperSwitchWin::DrawScene() {

 ClearSurface(backsurf, 0);

 BltSurface(backsurf, bmpsurf, x, y);

 x+=xinc; y+=yinc;

 const CRect& displayrect=GetDisplayRect();

 if (x<-160 || x>displayrect.right-160) {

  xinc=-xinc;

  x+=xinc;

 }

 if (y<-100 || y>displayrect.bottom-100) {

  yinc=-yinc;

  y+=yinc;

 }

 backsurf->BltFast(0, 0, modemenusurf, 0, DDBLTFAST_SRCCOLORKEY | DDBLTFAST_WAIT);

 if (ratemenu_up) {

  DWORD w,h;

  GetSurfaceDimensions(ratemenusurf, w, h);

  backsurf->BltFast((320-w)/2, (200-h)/2, ratemenusurf, 0, DDBLTFAST_WAIT);

 }

 UpdateFPSSurface();

 if (displayfps) {

  int x=displayrect.right-fpsrect.right;

  int y=displayrect.bottom-fpsrect.bottom;

  backsurf->BltFast(x, y, fpssurf, &fpsrect, DDBLTFAST_SRCCOLORKEY | DDBLTFAST_WAIT);

 }

 primsurf->Flip(0, DDFLIP_WAIT);

}

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

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

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

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

void SuperSwitchWin::OnKeyDown(UINT nChar, UINT nRepCnt, UINT nFlags) {

 int newindex;

 int nmodes=GetNumDisplayModes();

 if (nmodes>maxmodes) nmodes=maxmodes;

 int rows=nmodes/menucols;

 if (nmodes%menucols) rows++;

 switch (nChar) {

 case VK_ESCAPE:

  if (!include_refresh || !ratemenu_up) {

   PostMessage(WM_CLOSE);

   break;

  }

  if (ratemenu_up) {

   ratemenu_up=FALSE;

   if (ratemenusurf)     ratemenusurf->Release(), ratemenusurf=0;

  }

  break;

 case VK_UP:

  if (include_refresh && ratemenu_up) {

   if (selectrate>0) {

    selectrate--;

    UpdateRateMenuSurface();

   }

  } else {

   newindex=selectmode-1;

   if (newindex>=0) {

    selectmode=newindex;

    UpdateModeMenuSurface();

   }

  }

  break;

 case VK_DOWN:

  if (include_refresh && ratemenu_up)  {

   if (selectrate<numrates-1) {

    selectrate++;

    UpdateRateMenuSurface();

   }

  } else {

   newindex=selectmode+1;

   if (newindex>nmodes) {

    selectmode=newindex;

    UpdateModeMenuSurface();

   }

  }

  break;

 case VK_LEFT:

  if (include_refresh && ratemenu_up)   break;

  newindex=selectmode-rows;

  if (newindex>=0) {

   selectmode=newindex;

   UpdateModeMenuSurface();

  }

  break;

 case VK_RIGHT:

  if (include_refresh && ratemenu_up)    break;

  newindex=selectmode+rows;

  if (newindex<nmodes) {

   selectmode=newindex;

   UpdateModeMenuSurface();

  }

  break;

 case VK_RETURN:

  if (include_refresh) {

   if (ratemenu_up) {

    int rate=refresh_rates[selectmode][selectrate];

    ActivateDisplayMode(selectmode, rate);

    x=y=0;

    ratemenu_up=FALSE;

   } else {

    CreateRateMenuSurface();

    UpdateRateMenuSurface();

    ratemenu_up=TRUE;

   }

  } else {

   if (selectmode!=GetCurDisplayMode()) {

    ActivateDisplayMode(selectmode);

    x=y=0;

   }

  }

  break;

 case 'S':

  SaveSurface(primsurf, "SuperSwitch.bmp");

  break;

 default:

  DirectDrawWin::OnKeyDown(nChar, nRepCnt, nFlags);

 }

}

Все case-секции оператора switch были изменены для работы с новым меню. При нажатии клавиши Escape программа по-прежнему завершает работу, если меню частот в данный момент не отображается; тем не менее, если меню присутствует на экране, клавиша Escape просто скрывает его. Действие клавиш со стрелками также зависит от состояния меню. Если меню частот отображается, стрелки ­ и изменяют выделенную частоту, а если нет — выделенный пункт в меню видеорежимов.

Самые существенные различия связаны с обработкой клавиши Enter. Если во время нажатия клавиши Enter меню частот не отображается, мы вызываем функции CreateRateMenuSurface() и UpdateRateMenuSurface() и присваиваем флагу ratemenu_up значение TRUE. Давайте рассмотрим эти две функции. Функция CreateRateMenuSurface() выглядит так:

BOOL SuperSwitchWin::CreateRateMenuSurface() {

 if (ratemenusurf) ratemenusurf->Release(), ratemenusurf=0;

 int rates=refresh_rates[selectmode].GetSize();

 ratemenusurf=CreateSurface(80, rates*12+22);

 return TRUE;

}

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

Функция UpdateRateMenuSurface() отвечает за отображение текста меню. Выглядит она так:

BOOL SuperSwitchWin::UpdateRateMenuSurface() {

 RECT rect;

 GetSurfaceRect(ratemenusurf, rect);

 rect.left++;

 rect.top++;

 rect.right--;

 rect.bottom--;

 if (!ClearSurface(ratemenusurf, 0, 200, 132)) TRACE("first Clear failed\n");

 if (!ClearSurface(ratemenusurf, 0, 128, 100, &rect)) TRACE("second Clear failed\n");

 HDC hdc;

 ratemenusurf->GetDC(&hdc);

 SelectObject(hdc, smallfont);

 SetBkMode(hdc, TRANSPARENT);

 SetTextColor(hdc, ratetextshadow);

 ExtTextOut(hdc, 6, 4, 0, 0, rateheader, strlen(rateheader), 0);

 SetTextColor(hdc, ratetextcolor);

 ExtTextOut(hdc, 5, 3, 0, 0, rateheader, strlen(rateheader), 0);

 CArray<DWORD,DWORD>& ratelist=refresh_rates[selectmode];

 numrates=ratelist.GetSize();

 for (int i=0; i<numrates; i++) {

  char buf[10];

  int len=sprintf(buf, "%d hz", ratelist[i]);

  SetTextColor(hdc, ratetextshadow);

  ExtTextOut(hdc, 11, i*12+18, 0, 0, buf, len, 0);

  if (i==selectrate) SetTextColor(hdc, ratehighlightcolor);

  else SetTextColor(hdc, ratetextcolor);

  ExtTextOut(hdc, 10, i*12+17, 0, 0, buf, len, 0);

 }

 ratemenusurf->ReleaseDC(hdc);

 return TRUE;

}

Прежде всего функция очищает поверхность, вызывая ClearSurface(). Затем содержимое массива refresh_rates используется для вывода текстовых строк, связанных с каждым пунктом меню. Вывод текста, как обычно, осуществляется функцией GetDC() интерфейса DirectDrawSurface в сочетании с текстовыми функциями Win32. Перед выходом из функции UpdateRateMenuSurface() контекст устройства, полученный функцией GetDC(), освобождается с помощью функции ReleaseDC(). 

Заключение

В этой главе мы рассмотрели две демонстрационные программы и воспользовались такими возможностями DirectDraw, как переключение видеорежимов и частот смены кадров, а также применили цветовые ключи. Для переключения видеорежимов и частот использовалась функция EnumDisplayModes() интерфейса DirectDraw в сочетании с функцией SetDisplayMode(), а для работы с цветовыми ключами — функции SetColorKey() и BltFast() интерфейса DirectDrawSurface. Вывод текста в программах осуществлялся с помощью функции GetDC() интерфейса DirectDrawSurface и текстовых функций Win32.

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

Глава 5. Поверхности и форматы пикселей     

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

Поверхности

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

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

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

Несмотря на все преимущества прямого линейного доступа, при манипуляциях с поверхностями программист должен соблюдать осторожность. Например, чтобы получить указатель на память поверхности, ее необходимо предварительно заблокировать. Чаще всего такая блокировка заставляет DirectDraw временно отключать основные механизмы Windows. Если вы забудете разблокировать поверхность или ваша программа «зависнет» при заблокированной поверхности, скорее всего, придется перезагружать компьютер. Кроме того, для проверки правильности работы кода между вызовами Lock() и Unlock() нельзя пользоваться отладчиками.

СОВЕТ

Новые возможности DirectX 5

DirectX 5 позволяет указать DirectDraw, что во время блокировки поверхностей можно обойтись без остановки механизмов Windows. DirectDraw постарается заблокировать поверхность, но при этом обойтись без обычных проблем.

Эта новая возможность обеспечивается функцией Lock() интерфейса DirectDrawSurface3, которой можно передать новый флаг DDLOCK_NOSYSLOCK. Ситуации, в которой DirectDraw сможет заблокировать поверхность без остановки системы, нигде не описаны, поэтому нет никаких гарантий, что ваша просьба будет удовлетворена. Если это не удастся сделать, поверхность блокируется стандартным способом.

Для прямого доступа к поверхности нужно знать формат ее пикселей. Этот формат определяет способ хранения цветовых данных каждого пикселя. Он может изменяться в зависимости от видеоустройства и даже от видеорежима. Форматы пикселей особенно сильно различаются для поверхностей High Color (16-битных).

При прямом доступе к памяти поверхности необходимо также знать значение шага поверхности (surface stride). Шагом называется объем памяти, необходимый для представления горизонтальной строки пикселей. С первого взгляда кажется, что шаг поверхности совпадает с ее шириной, но на самом деле это разные параметры. Шаг поверхности, как и формат пикселей, зависит от конкретного видеоустройства.

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

Глубина пикселей 

Глубина пикселей показывает, сколько разных цветов может быть представлено одним пикселем поверхности. Глубина пикселей также влияет на объем памяти, необходимой для представления поверхности. В DirectDraw предусмотрена поддержка четырех глубин пикселей: 8-битных (палитровых), 16-битных (High Color), 24-битных и 32-битных (объединяемых термином True Color).

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

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

Пиксели High Color (16-битные) выглядят несколько сложнее, однако результат часто оправдывает усилия. Простота использования, характерная для беспалитровых поверхностей, сочетается в них с умеренным расходом памяти (по сравнению с пикселями глубины True Color). Каждый пиксель High Color содержит не индекс, а цвет. Цвета выражаются в виде комбинации трех цветовых составляющих: красной, зеленой и синей (RGB).

Пиксели True Color делятся на две категории (24- и 32-битные), но в обоих случаях используются только 24 бита данных RGB. Лишние 8 бит 32-битных пикселей иногда используются для хранения альфа-канала (то есть данных о прозрачности пикселя). К сожалению, в DirectDraw все еще отсутствует возможность эмуляции альфа-наложения, так что лишние биты 32-битного пикселя часто пропадают впустую.

Разумеется, достоинства поверхностей True Color отчасти снижаются увеличенным расходом памяти. Сказанное поясняет рис. 5.1, на котором наглядно изображены глубины всех четырех вариантов пикселей.

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

Рис. 5.1. Зависимость требований к памяти от глубины пикселей

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

Для примера возьмем 8-битную поверхность (поскольку один пиксель в таких поверхностях представляется одним байтом, что упрощает вычисления). Предположим, ваше видеоустройство требует, чтобы во внутреннем (для DirectDraw) представлении ширина поверхности была выровнена по границам параграфов (то есть была кратна 4 байтам). В этом случае поверхность с шириной в 10 пикселей будет иметь внутреннюю ширину в 12 байт. Если мы заблокируем эту поверхность и назначим значения пикселей, предполагая, что развертка одной горизонтальной строки занимает 10 байт, изображение получится перекошенным. Проблему можно легко решить, если вместо ширины при развертке поверхностей будет использоваться шаг. При этом независимо от внутренней ширины поверхностей, используемой DirectDraw, вычисление адресов пикселей будет давать правильный результат. Ситуация поясняется на рис. 5.2.

Рис. 5.2. Небольшая 8-битная поверхность с разными значениями шага и ширины

Для беспалитровых поверхностей шаг и ширина поверхности уже не связаны между собой, поскольку каждый пиксель занимает несколько байт. К примеру, возьмем поверхность High Color (16-битную). При ширине поверхности в 5 пикселей каждая строка будет занимать 10 байт. Если видеоустройство требует, чтобы фактическая ширина поверхности выравнивалась по границе параграфа, DirectDraw создает поверхность с внутренней шириной в 12 байт (см. рис. 5.3).

Обратите внимание: если бы ширина 16-битной поверхности на рис. 5.3 была равна 6 пикселям вместо 5, шаг поверхности остался бы прежним, потому что в каждой строке остается свободное место для одного дополнительного пикселя.

Рис. 5.3. Небольшая 16-битная поверхность с разными значениями шага и ширины

Давайте рассмотрим еще два примера, на этот раз с 24-битными поверхностями. При 12-байтовой модели, использованной выше, и 24-битной глубине пикселя в одной строке можно будет хранить 4 пикселя и избежать потерь памяти. Но что произойдет, если поверхность имеет ширину в 5 пикселей? Шаг увеличится до 16 байт, а в каждой строке будет напрасно пропадать один байт. Обе ситуации изображены на рис. 5.4.

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

Рис. 5.4. Две небольшие 24-битные поверхности

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

Форматы пикселей 

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

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

В формате 5-5-5 каждая цветовая составляющая может принимать значения из интервала от 0 до 31. Чем больше значение составляющей, тем интенсивнее она проявляется в результирующем цвете. Формат 5-6-5 работает аналогично, за исключением того, что зеленая составляющая может принимать значения из интервала 0–63. Эти два вида 16-битных пикселей изображены на рис. 5.5.

Дело осложняется тем, что форматы 5-5-5 и 5-6-5 тоже делятся на два типа. На рис. 5.5 изображен RGB -формат, в котором цветовые составляющие хранятся в порядке «красный, зеленый, синий». Также существует BGR-формат, в котором красная и синяя составляющая меняются местами. Вряд ли в ближайшем будущем появятся еще какие-нибудь варианты.

Рис. 5.5. Два распространенных 16-битных формата пикселей

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

С пикселями формата True Color работать проще, потому что каждая из RGB-составляющих представлена одним байтом. В этом случае значение каждой составляющей принадлежит интервалу 0–255; ноль означает, что составляющая вообще не влияет на результирующий цвет, а 255 - что ее влияние максимально. Форматы пикселей для 24- и 32-битных вариантов изображены на рис. 5.6.

24- и 32-битные пиксели, как и 16-битные, делятся на две разновидности: RGB и BGR. Следовательно, код для работы с пикселями True Color должен использовать сведения о формате, полученные от DirectDraw, и не делать никаких безусловных предположений.

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

Рис. 5.6. Типичные форматы пикселей True Color

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

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

DDPIXELFORMAT format;

ZeroMemory(&format, sizeof(format));

format.dwSize=sizeof(format);

surf->GetPixelFormat(&format);

Структура DDPIXELFORMAT содержит четыре поля, представляющих для нас интерес:

• dwRGBBitCount

• dwRBitMask

• dwGBitMask

• dwBBitMask

Поле dwRGBBitCount показывает глубину пикселей поверхности. Три оставшихся поля являются масками, определяющими, в каких битах пикселя хранятся данные красной, зеленой и синей составляющих. Например, типичные значения полей для поверхности High Color формата 5-6-5 приведены в табл. 5.1.

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

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

Поле Значение Двоичное значение dwRGBBitCount 16 (неважно) dwRBitMask 63488 1111100000000000 dwGBitMask 2016 0000011111100000 dwBBitMask 31 0000000000011111

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

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

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

Поле Значение Двоичное значение Стартовый бит Количество бит dwRBitMask 63488 1111100000000000 11 5 dwGBitMask 2016 0000011111100000 5 6 dwBBitMask 31 0000000000011111 0 5

Однако до сих пор мы рассматривали лишь 16-битные пиксели. 8-битные пиксели нас не интересуют, но перед тем, как идти дальше, необходимо уделить внимание пикселям формата True Color. В табл. 5.3 приведены данные формата пикселей (в том числе две вычисленные величины для каждой цветовой составляющей) для типичного 24-битного формата.

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

Поле Значение Двоичное значение Стартовый бит Количество бит dwRBitMask 16711680 111111110000000000000000 16 8 dwGBitMask 65280 000000001111111110000000 8 8 dwBBitMask 255 000000000000000011111111 0 8

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

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

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

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

BOOL DirectDrawWin::StorePixelFormatData() {

 DDPIXELFORMAT format;

 ZeroMemory(&format, sizeof(format));

 format.dwSize=sizeof(format);

 if (primsurf->GetPixelFormat(&format)!=DD_OK) {

  TRACE("StorePixelFormatData() failed\n");

  return FALSE;

 }

 loREDbit = LowBitPos(format.dwRBitMask);

 WORD hiREDbit = HighBitPos(format.dwRBitMask);

 numREDbits=(WORD)(hiREDbit-loREDbit+1);

 loGREENbit = LowBitPos(format.dwGBitMask);

 WORD hiGREENbit = HighBitPos(format.dwGBitMask);

 numGREENbits=(WORD)(hiGREENbit-loGREENbit+1);

 loBLUEbit = LowBitPos(format.dwBBitMask);

 WORD hiBLUEbit = HighBitPos(format.dwBBitMask);

 numBLUEbits=(WORD)(hiBLUEbit-loBLUEbit+1);

 return TRUE;

}

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

• loREDbit

• numREDbits

• loGREENbit

• numGREENbits

• loBLUEbit

• numBLUEbits

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

Блокировка поверхностей

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

HRESULT Lock(LPRECT rect, LPDDSURFACEDESC desc, DWORD flags, HANDLE event);

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

Второй аргумент функции Lock() — структура DDSURFACEDESC, которая используется для возвращения указателя на память поверхности (поле lpSurface) и шага поверхности (поле lPitch). Функция Lock() (как и другие функции DirectDraw) требует правильно присвоить значение полю dwSize структуры DDSURFACEDESC.

Третий аргумент используется для настройки параметров Lock(). В него могут входить следующие флаги:

• DDLOCK_EVENT

• DDLOCK_READONLY

• DDLOCK_WRITEONLY

• DDLOCK_SURFACEMEMORYPTR

• DDLOCK_WAIT

На момент выхода DirectX 5 флаг DDLOCK_EVENT не поддерживался. Возможно, в будущих версиях DirectDraw он будет использоваться совместно с последним аргументом Lock() для реализации альтернативного метода блокировки поверхностей.

Флаги DDLOCK_READONLY и DDLOCK_WRITEONLY следует использовать в том случае, когда доступ к памяти поверхности осуществляется исключительно для чтения или записи. В большинстве ситуаций эти флаги ни на что не действуют, однако в видеорежимах «Mode X» DirectDraw использует их для оптимизации доступа к поверхности.

Флаг DDLOCK_SURFACEMEMORYPTR необязателен, потому что он задает поведение Lock(), которое и так является стандартным. Lock() возвращает указатель на память поверхности как с этим флагом, так и без него, поэтому мы не станем использовать его в своих программах (флаг DDLOCK_SURFACEMEMORYPTR на самом деле определен равным 0, так что я нисколько не преувеличиваю, говоря, что он ни на что не влияет).

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

BMP-файлы

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

Формат BMP-файлов

BMP — стандартный формат графических файлов Windows. Подавляющее большинство BMP-файлов хранится без сжатия, что облегчает работу с ними. Даже в сжатых BMP-файлах нет ничего особенно сложного, но мы ограничимся файлами без сжатия.

BMP-файлы состоят из трех основных частей:

• заголовок;

• палитра;

• графические данные (значения пикселей).

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

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

Графические данные — это и есть само изображение. Формат этих данных зависит от глубины пикселей. Хотя BMP-файлы делятся на несколько типов, мы ограничимся 8-битными и 24-битными изображениями. 8-битные BMP-файлы будут использоваться для работы с 8-битными поверхностями, а 24-битные — для беспалитровых поверхностей. Хотя, по слухам, в природе существуют 16-битные и 32-битные BMP-файлы, они встречаются очень редко — например, мне таковые ни разу не попадались. Впрочем, это не имеет особого значения, так как 24-битную графику можно легко преобразовать в 16- или 32-битный формат.

Структура заголовка

Данные заголовка BMP-файла хранятся в двух структурах: BITMAPFILEHEADER и BITMAPINFOHEADER. Структура BITMAPFILEHEADER присутствует в начале любого BMP-файла и содержит информацию о самом файле. Для нас в этой структуре представляет интерес лишь одно поле — bfType, сигнатура BMP-файла (информацию об остальных полях можно найти в справочной системе Visual C++). В BMP-файлах это поле содержит буквы BM (обе буквы — прописные). По содержимому этого поля мы будем убеждаться в том, что выбранные файлы действительно имеют формат BMP.

Структура BITMAPINFOHEADER содержит информацию об изображении, хранящемся в BMP-файле. Эта структура объявляется так:

typedef struct tagBITMAPINFOHEADER {

 DWORD biSize;

 LONG  biWidth;

 LONG  biHeight;

 WORD  biPlanes;

 WORD  biBitCount;

 DWORD biCompression;

 DWORD biSizeImage;

 LONG  biXPelsPerMeter;

 LONG  biYPelsPerMeter;

 DWORD biClrUsed;

 DWORD biClrImportant;

} BITMAPINFOHEADER, FAR *LPBITMAPINFOHEADER, *PBITMAPINFOHEADER;

Первое поле, biSize, определяет размер структуры BITMAPINFOHEADER в байтах. Если ваша программа создает BMP-файл, это поле заполняется тривиально — достаточно определить размер структуры функцией sizeof. Однако при чтении BMP-файла по содержимому этого поля приходится рассчитывать позицию файла, на которой структура заголовка кончается. Эта мера обеспечивает обратную совместимость, благодаря ей Microsoft в будущем сможет увеличить размер структуры BITMAPINFOHEADER, не нарушая работы существующих приложений.

СОВЕТ

Лучше молчать и прослыть глупцом…

Когда я только начал программировать для Windows, то не понимал, зачем в некоторые структуры включаются поля с их размерами. Забыв о мудром совете Авраама Линкольна, я высказался на эту тему в одной из ранних статей и был справедливо наказан. Впрочем, если бы все прислушались к совету Линкольна, никто бы не писал книг.

Поля biWidth, biHeight и biBitCount определяют размеры изображения. Содержимое поля biCompression позволяет узнать, хранится ли изображение в сжатом виде. Поскольку мы не собираемся работать со сжатыми BMP-файлами, необходимо проверить, имеет ли это поле значение BI_RGB (а не BI_RLE8, свидетельствующее о сжатии файла).

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

Наконец, поле biClrUsed определят количество цветов в палитре (для палитровых изображений). Как и поле biSizeImage, оно часто может быть равно нулю. Это означает, что палитра содержит максимальное количество элементов (256 для 8-битных изображений). Остальные поля структуры BITMAPINFOHEADER не представляют для нас интереса, поэтому я не стану утомлять вас их обсуждением. 

Палитра 

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

typedef struct tagRGBQUAD {

 BYTE rgbBlue;

 BYTE rgbGreen;

 BYTE rgbRed;

 BYTE rgbReserved;

} RGBQUAD;

В первых трех полях хранятся цветовые RGB-составляющие. На поле rgbReserved мы не будем обращать внимания (предполагается, что оно равно нулю). Как я упоминал выше, количество структур RGBQUAD в BMP-файле определяется полем biClrUsed. Тем не менее обычно 8-битные BMP-файлы содержат 256 структур RGBQUAD. В 24-битных RGB-файлах структуры RGBQUAD отсутствуют. 

Графические данные 

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

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

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

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

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

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

Функция CreateSurface() 

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

Давайте посмотрим, как реализована функция CreateSurface() (см. листинг 5.1).

Листинг 5.1. Функция CreateSurface()

LPDIRECTDRAWSURFACE DirectDrawWin::CreateSurface(LPCTSTR filename, BOOL installpalette) {

 int imagew, imageh;

 GetBmpDimensions(filename, imagew, imageh);

 LPDIRECTDRAWSURFACE surf=CreateSurface(imagew, imageh);

 if (surf==0) {

  TRACE("CreateSurface(filename) failed to create surface\n");

  return 0;

 }

 ifstream bmp(filename, ios::binary | ios::nocreate);

 if (!bmp.is_open()) {

  TRACE("LoadSurface: cannot open Bmp file\n");

  return 0;

 }

 BITMAPFILEHEADER bmpfilehdr;

 bmp.read((char*)&bmpfilehdr, sizeof(bmpfilehdr));

 char* ptr=(char*)&bmpfilehdr.bfType;

 if (*ptr!='B' || *++ptr!='M') {

  TRACE("invalid bitmap\n");

  return 0;

 }

 BITMAPINFOHEADER bmpinfohdr;

 bmp.read((char*)&bmpinfohdr, sizeof(bmpinfohdr));

 bmp.seekg(sizeof(bmpfilehdr)+bmpinfohdr.biSize, ios::beg);

 int imagebitdepth=bmpinfohdr.biBitCount;

 int imagesize=bmpinfohdr.biSizeImage;

 if (imagesize==0) imagesize=((imagew*(imagebitdepth/8)+3) & ~3)*imageh;

 if (bmpinfohdr.biCompression!=BI_RGB) {

  TRACE("compressed BMP format\n");

  return 0;

 }

 TRACE("loading '%s': width=%d height=%d depth=%d\n", filename, imagew, imageh, imagebitdepth);

 if (imagebitdepth==8) {

  int ncolors;

  if (bmpinfohdr.biClrUsed==0)   ncolors=256;

  else   ncolors=bmpinfohdr.biClrUsed;

  RGBQUAD* quad=new RGBQUAD[ncolors];

  bmp.read((char*)quad, sizeof(RGBQUAD)*ncolors);

  if (installpalette) CreatePalette(quad, ncolors);

  delete[] quad;

 }

 BYTE* buf=new BYTE[imagesize];

 bmp.read(buf, imagesize);

 if (!Copy_Bmp_Surface(surf, &bmpinfohdr, buf)) {

  TRACE("copy failed\n");

  delete[] buf;

  surf->Release();

  return 0;

 }

 delete[] buf;

 return surf;

}

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

Затем мы открываем BMP-файл с помощью класса ifstream и извлекаем из него данные заголовка. Далее проверяется сигнатура файла; если проверка дает отрицательный результат, BMP-файл может содержать неверную информацию, поэтому функция завершает работу.

Дополнительные данные заголовка извлекаются с помощью структуры BITMAPINFOHEADER. Обратите внимание: после заполнения структуры текущая позиция в файле ifstream изменяется в соответствии со значением поля biSize. Это сделано для того, чтобы в будущем, при увеличении размера структуры BITMAPINFOHEADER, наша программа нормально работала с новыми BMP-файлами.

Ширина и высота изображения уже известны, поэтому читать значения полей biWidth и biHeight структуры BITMAPINFOHEADER не нужно. Функция CreateSurface() считывает глубину пикселей (biBitCount) и размер изображения (biSizeImage). Как упоминалось выше, поле biSizeImage часто равно нулю, поэтому мы проверяем его значение. Снова приведу соответствующий фрагмент кода:

int imagesize=bmpinfohdr.biSizeImage;

if (imagesize==0) imagesize=((imagew*(imagebitdepth/8)+3) & ~3)*imageh;

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

И последняя проверка: по содержимому поля biCompression мы убеждаемся, что BMP-файл не содержит сжатых данных, не поддерживаемых нами. Для сжатых файлов функция возвращает ноль, код неудачного завершения.

Если изображение является палитровым, мы загружаем палитру. Количество элементов палитры в файле определяется полем biClrUsed, но это поле также может быть равно нулю. В этом случае предполагается, что присутствуют все 256 элементов палитры. Палитра загружается лишь в том случае, если параметр installpalette равен TRUE; тогда вызывается функция CreatePalette(). Вскоре мы рассмотрим код этой функции.

Следующий этап — чтение графических данных, которое в нашем случае выполняется одним вызовом функции ifstream::read(). Графические данные передаются функции Copy_Bmp_Surface(), отвечающей за пересылку данных новой поверхности. После возврата из функции Copy_Bmp_Surface() буфер с графическими данными освобождается. BMP-файл автоматически закрывается при возвращении из функции CreateSurface() (поскольку локальный объект ifstream выходит из области видимости). 

Функция CreatePalette() 

Если второй аргумент функции CreateSurface() равен TRUE, CreatePalette() создает и заполняет объект DirectDrawPalette данными, полученными из BMP-файла. Функция CreatePalette() выглядит так:

BOOL DirectDrawWin::CreatePalette(RGBQUAD* quad, int ncolors){

 if (palette) palette->Release(), palette=0;

 PALETTEENTRY pe[256];

 ZeroMemory(pe, sizeof(pe));

 for(int i=0; i<ncolors; i++) {

  pe[i].peRed = quad[i].rgbRed;

  pe[i].peGreen = quad[i].rgbGreen;

  pe[i].peBlue = quad[i].rgbBlue;

 }

 HRESULT r=ddraw2->CreatePalette(DDPCAPS_8BIT | DDPCAPS_ALLOW256, pe, &palette, 0);

 if (r!=DD_OK) {

  TRACE("failed to reate DirectDraw palette\n");

  return FALSE;

 }

 primsurf->SetPalette(palette);

 return TRUE;

}

Палитры DirectDraw создаются функцией CreatePalette() интерфейса DirectDraw, которой передается массив структур PALETTEENTRY. Чтобы выполнить это требование, приходится преобразовывать массив структур RGBQUAD, извлеченный из BMP-файла, во временный массив (структуры PALETTEENTRY и RGBQUAD очень похожи, поэтому такое преобразование оказывается тривиальным). Затем созданный массив передается функции CreatePalette(). Флаг DDPCAPS_ALLOW256 сообщает, что мы намерены задать значения всех 256 элементов палитры. Если вы пропустили главу 4 (конечно же, нет!), вернитесь к ней и ознакомьтесь с возможными аспектами использования этого флага.

Наконец, функция SetPalette() интерфейса DirectDrawSurface() присоединяет палитру к поверхности. Обратите внимание на то, что палитра присоединяется к первичной поверхности. Хотя палитры можно присоединять и к другим поверхностям, на системную палитру влияет только палитра, присоединенная к первичной поверхности. 

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

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

BOOL DirectDrawWin::Copy_Bmp_Surface(LPDIRECTDRAWSURFACE surf, BITMAPINFOHEADER* bmphdr, BYTE* buf) {

 if (surf==0 || bmphdr==0 || buf==0) return FALSE;

 int imagew=bmphdr->biWidth;

 int imageh=bmphdr->biHeight;

 int imagebitdepth=bmphdr->biBitCount;

 BOOL ret=FALSE;

 if (imagebitdepth==8) {

  if (displaydepth==8) ret=Copy_Bmp08_Surface08(surf, buf, imagew, imageh);

 } else if (imagebitdepth==24) {

  if (displaydepth==16) ret=Copy_Bmp24_Surface16(surf, buf, imagew, imageh);

  else if (displaydepth==24) ret=Copy_Bmp24_Surface24(surf, buf, imagew, imageh);

   else if (displaydepth==32) ret=Copy_Bmp24_Surface32(surf, buf, imagew, imageh);

 }

 return ret;

}

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

8-битные поверхности

Начнем с самой простой из четырех функций, Copy_Bmp08_Surface08(). Она выглядит так:

BOOL DirectDrawWin::Copy_Bmp08_Surface08(LPDIRECTDRAWSURFACE surf,      BYTE* bmpbuf, int w, int h) {

 if (surf==0 || bmpbuf==0) return FALSE;

 DDSURFACEDESC desc;

 ZeroMemory(&desc, sizeof(desc));

 desc.dwSize = sizeof(desc);

 HRESULT r=surf->Lock(0, &desc, DDLOCK_WAIT | DDLOCK_WRITEONLY, 0);

 if (r!=DD_OK) {

  TRACE("ShowBmp: Lock() failed\n");

  return FALSE;

 }

 int bytesgiven=(w+3) & ~3;

 BYTE* surfbits = (BYTE*)desc.lpSurface;

 BYTE* imagebits = (BYTE*)(&bmpbuf[(h-1)*bytesgiven]);

 for(int i=0; i<h; i++) {

  memcpy(surfbits, imagebits, w);

  surfbits += desc.lPitch;

  imagebits -= bytesgiven;

 }

 surf->Unlock(0);

 return TRUE;

}

После проверки обоих аргументов-указателей мы подготавливаем экземпляр структуры DDSURFACEDESC(desc) и используем его при вызове функции Lock() интерфейса DirectDrawSurface. После возвращения из функции Lock() поле lpSurface содержит указатель на память поверхности, и мы можем спокойно изменять содержимое поверхности через этот указатель до вызова Unlock(). Безопасная работа с поверхностью стала возможной только потому, что мы указали флаг DDLOCK_WRITEONLY. Если вы собираетесь осуществлять и чтение, и запись, не устанавливайте этот флаг.

Далее мы инициализируем целую переменную bytesgiven. Присваиваемое значение определяется шириной изображения (w), выровненного по границе параграфа. Получившаяся величина равна объему памяти, необходимой для хранения одной строки пикселей. Если ширина изображения кратна четырем, переменная bytesgiven совпадает с w.

Указатель на поверхность (surfbits) инициализируется значением поля lpSurface. Этот указатель используется для обращений к памяти поверхности. Указатель на графические данные (imagebits) инициализируется адресом последней строки пикселей BMP-файла, поскольку в формате BMP изображение хранится в перевернутом виде.

Затем мы в цикле перебираем все строки пикселей изображения. Благодаря тому, что формат графических данных BMP-файла совпадает с форматом поверхности, для копирования можно воспользоваться функцией memcopy(). Для поверхностей остальных типов такая удобная возможность часто отсутствует. Поле lPitch определяет смещение для указателя на поверхность при переходе к следующей строке. Вспомните, что в этом поле хранится шаг поверхности, который может не совпадать с ее шириной. Целая переменная bytesgiven аналогичным образом используется для перехода к следующей строке буфера графических данных. Поскольку чтение начинается с конца буфера, указатель imagebits уменьшается с каждой очередной итерацией.

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

16-битные поверхности

Загрузка 8-битных изображений выполняется достаточно просто. Давайте перейдем к 16-битным поверхностям, с ними дело обстоит значительно сложнее. Помимо учета разных типов 16-битных форматов пикселей нам придется сокращать количество цветов. 24-битные данные передаются на 16-битную поверхность, поэтому во время передачи необходимо «урезать» каждую цветовую составляющую. Функция Copy_Bmp24_Surface16() приведена в листинге 5.2.

Листинг 5.2. Функция Copy_Bmp24_Surface16()

BOOL DirectDrawWin::Copy_Bmp24_Surface16(LPDIRECTDRAWSURFACE surf, BYTE* bmpbuf, int w, int h) {

 if (surf==0 || bmpbuf==0)  return FALSE;

 DDSURFACEDESC desc;

 ZeroMemory(&desc, sizeof(desc));

 desc.dwSize = sizeof(desc);

 HRESULT r=surf->Lock(0, &desc, DDLOCK_WAIT | DDLOCK_WRITEONLY, 0);

 if (r!=DD_OK) {

  TRACE("Copy_Bmp24_Surface16: Lock() failed\n");

  return FALSE;

 }

 int bytesrequired=w*3;

 int bytesgiven=(bytesrequired+3) & ~3;

 BYTE* surfbits = (BYTE*)desc.lpSurface;

 BYTE* imagebits = (BYTE*)(&bmpbuf[(h-1)*bytesgiven]);

 float REDdiv=(float)256/(float)pow(2, numREDbits);

 float GREENdiv=(float)256/(float)pow(2, numGREENbits);

 float BLUEdiv=(float)256/(float)pow(2, numBLUEbits);

 for(int i=0; i<h; i++) {

  USHORT* pixptr=(unsigned short*)surfbits;

  RGBTRIPLE* triple=(RGBTRIPLE*)imagebits;

  for (int p=0;p>w;p++) {

   float rf=(float)triple->rgbtRed/REDdiv;

   float gf=(float)triple->rgbtGreen/GREENdiv;

   float bf=(float)triple->rgbtBlue/BLUEdiv;

   WORD r=(WORD)((WORD)rf<<loREDbit);

   WORD g=(WORD)((WORD)gf<<loGREENbit);

   WORD b=(WORD)((WORD)bf<<loBLUEbit);

   *pixptr = (WORD)(r|g|b);

   triple++;

   pixptr++;

  }

  surfbits += desc.lPitch;

  imagebits –= bytesgiven;

 }

 surf->Unlock(0);

 return TRUE;

}

Хотя по своей структуре функция Copy_Bmp24_Surface16() напоминает Copy_Bmp 08_Surface08(), она устроена сложнее по причинам, уже упоминавшимся, а также потому, что значение каждого пикселя приходится задавать отдельно. Давайте посмотрим, что происходит в этой функции.

Сначала функция Lock() интерфейса DirectDrawSurface используется для получения указателя на поверхность. Затем мы инициализируем две целые переменные, bytesrequired и bytesgiven. Значение bytesrequired равно количеству байт, необходимых для представления строки пикселей. Поскольку мы работаем с 24-битными пикселями, для получения этой величины достаточно умножить ширину изображения на три (по три байта на пиксель). По значению bytesrequired рассчитывается значение bytesgiven, которое равно количеству байт для хранения строки пикселей в памяти (с учетом выравнивания по границе параграфа). Значение bytesgiven используется для перебора строк пикселей в графических данных BMP-файла.

Затем мы инициализируем указатели surfbits и imagebits; первый указывает на память поверхности, а второй — на буфер графических данных. Как и в функции Copy_Bmp08_Surface08(), imagebits указывает на последнюю строку буфера.

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

Назначение пикселей происходит во вложенном цикле. Внешний цикл перебирает строки пикселей, а внутренний задает значение для каждого пикселя строки. Внутренний цикл инициализирует два указателя, pixptr и triple, которые используются для обращения к текущему пикселю. Переменная pixptr указывает на память поверхности, а triple - на буфер графических данных. Обратите внимание — pixptr объявлен как указатель на 16-битный тип USHORT. В этом случае для перехода к следующему пикселю достаточно увеличить значение указателя. Аналогично triple указывает на 24-битный тип RGBTRIPLE.

Внутренний цикл извлекает три цветовые составляющие каждого пикселя и делит их на ранее вычисленную величину. Значения с плавающей точкой, использованные при вычислениях, преобразуются к целым и сдвигаются к нужной позиции в соответствии с переменными loREDbit, loGREENbit и loBLUEbit. Окончательный результат представляет собой тройку «урезанных» цветовых составляющих. Побитовый оператор OR упаковывает составляющие в единую величину, и результат заносится в память поверхности. Указатели pixptr и triple инкрементируются для перехода к следующему пикселю. 

24-битные поверхности

Мы рассмотрели доступ к 16-битным поверхностям, и все самое сложное осталось позади. Для 24- и 32-битных поверхностей сокращение цветов уже не требуется, поэтому вычислить значение пикселя оказывается проще. В основном нам нужно лишь извлечь цветовые составляющие и сдвинуть их в позицию, определяемую расположением и форматом пикселя. Для 24-битных поверхностей процесс можно оптимизировать, если формат пикселей поверхности совпадает с форматом пикселей BMP-файла. 24-битные поверхности обрабатываются функцией Copy_Bmp24_Surface24() (см. листинг 5.3).

Листинг 5.3. Функция Copy_Bmp24_Surface24()

BOOL DirectDrawWin::Copy_Bmp24_Surface24(LPDIRECTDRAWSURFACE surf, BYTE* bmpbuf, int w, int h) {

 if (surf==0 || bmpbuf==0)  return FALSE;

 DDSURFACEDESC desc;

 ZeroMemory(&desc, sizeof(desc));

 desc.dwSize = sizeof(desc);

 HRESULT r=surf->Lock(0, &desc, DDLOCK_WAIT | DDLOCK_WRITEONLY, 0);

 if (r!=DD_OK) {

  TRACE("Copy_Bmp24_Surface24: Lock() failed\n");

  return FALSE;

 }

 int bytesrequired=w*3;

 int bytesgiven=(bytesrequired+3) & ~3;

 BYTE* surfbits = (BYTE*)desc.lpSurface;

 BYTE* imagebits = (BYTE*)(&bmpbuf[(h-1)*bytesgiven]);

 // Проверить, совпадает ли формат файла с форматом поверхности

 // Если совпадает, пересылку можно ускорить функцией memcpy()

 if (loREDbit==16 && loGREENbit==8 && loBLUEbit==0) {

  TRACE("using optimized code...\n");

  for (int i=0;i<h;i++)  {

   memcpy(surfbits, imagebits, bytesrequired);

   surfbits += desc.lPitch;

   imagebits -= bytesgiven;

  }

 } else {

  TRACE("not using optimated code...\n");

  for(int i=0; i>h; i++) {

   RGBTRIPLE* surf=(RGBTRIPLE*)surfbits;

   RGBTRIPLE* image=(RGBTRIPLE*)imagebits;

   for (int p=0;p<w;p++) {

    DWORD r=image->rgbtRed << loREDbit;

    DWORD g=image->rgbtGreen << loGREENbit;

    DWORD b=image->rgbtBlue << loBLUEbit;

    DWORD* data=(DWORD*)surf;

    *data = r|g|b;

    surf++;

    image++;

   }

   surfbits += desc.lPitch;

   imagebits -= bytesgiven;

  }

 }

 surf->Unlock(0);

 return TRUE;

}

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

Неоптимизированный цикл похож на тот, что применялся для 16-битных поверхностей, но на этот раз нам не нужно выполнять сокращение цветов. Для доступа к поверхности и графическим данным используются два указателя, surf и image. Оба являются указателями на 24-битный тип RGBTRIPLE, что упрощает перебор 24-битных пикселей.

Каждая цветовая составляющая извлекается из буфера графических данных и сдвигается в соответствии со значением переменных loREDbit, loGREENbit и loBLUEbit. Затем компоненты объединяются и заносятся в память поверхности. Наконец, инкрементирование указателей surf и image перемещает их к следующему пикселю. 

32-битные поверхности

Последняя функция, Copy_Bmp24_Surface32(), предназначена для 32-битных поверхностей и очень напоминает функцию Copy_Bmp24_Surface24(). Если бы в 32-битной поверхности все 32 бита использовались для хранения цветовых составляющих, нам пришлось бы выполнять расширение цветов, но так как используется только 24 бита, в этом нет необходимости. Функция Copy_Bmp24_Surface32() приведена в листинге 5.4.

Листинг 5.4. Функция Copy_Bmp24_Surface32()

BOOL DirectDrawWin::Copy_Bmp24_Surface32(LPDIRECTDRAWSURFACE surf, BYTE* bmpbuf, int w, int h) {

 if (surf==0 || bmpbuf==0)  return FALSE;

 DDSURFACEDESC desc;

 ZeroMemory(&desc, sizeof(desc));

 desc.dwSize = sizeof(desc);

 HRESULT r=surf->Lock(0, &desc, DDLOCK_WAIT | DDLOCK_WRITEONLY, 0);

 if (r!=DD_OK) {

  TRACE("Copy_Bmp24_Surface32: Lock() failed\n");

  return FALSE;

 }

 int bytesrequired=w*3;

 int bytesgiven=(bytesrequired+3) & ~3;

 BYTE* surfbits = (BYTE*)desc.lpSurface;

 BYTE* imagebits = (BYTE*)(&bmpbuf[(h-1)*bytesgiven]);

 for(int i=0; i<h; i++) {

  DWORD* surf=(DWORD*)surfbits;

  RGBTRIPLE* image=(RGBTRIPLE*)imagebits;

  for (int p=0;p>w;p++) {

   DWORD r=image->rgbtRed << loREDbit;

   DWORD g=image->rgbtGreen << loGREENbit;

   DWORD b=image->rgbtBlue << loBLUEbit;

   DWORD* data=(DWORD*)surf;

   *data = r|g|b;

   surf++;

   image++;

  }

  surfbits += desc.lPitch;

  imagebits -= bytesgiven;

 }

 surf->Unlock(0);

 return TRUE;

}

Для работы с пикселями каждой строки используются два указателя, surf и image. Первый является указателем на 32-битный тип DWORD и используется для перебора 32-битных пикселей в памяти поверхности. Второй является указателем на 24-битный тип RGBTRIPLE и используется для доступа к пикселям графических данных. Функция вряд ли нуждается в пояснениях, поскольку она ничем не отличается от своего аналога для 24-битных поверхностей, кроме типа указателя surf и отсутствия оптимизированного варианта цикла.

Программа 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.

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

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

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

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

• установка библиотеки DirectX 5;

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

• наличие достаточного объема видеопамяти.

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

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

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

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

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

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

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

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

Второй вариант — восстанавливать видеорежим и рабочий стол Windows перед отображением диалогового окна. Он встречается в некоторых коммерческих продуктах; например в игре MechWarrior 2 фирмы Activision для заставок, воспроизведения видеороликов и вступительного инструктажа используется стандартный интерфейс Windows. Затем, с началом миссии, игра берет на себя все управление видеокартой и не пользуется никакими интерфейсными компонентами Windows. После завершения миссии поверхность рабочего стола снова восстанавливается. В этой игре данная методика работает неплохо.

Версия MechWarrior 2, о которой я говорю, проектировалась для чипов 3Dfx. Для видеоустройств, построенных на таких чипах, вывод диалоговых окон в DirectDraw невозможен, потому что 3Dfx являются вторичными видеоустройствами, и GDI ничего не знает об их существовании. Поэтому команда разработчиков Activision не могла выбрать первый вариант и отображать диалоговые окна в DirectDraw.

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

В программе BmpView используется первый вариант. Перед выводом диалогового окна на рис. 5.7 мы отображаем поверхность GDI и восстанавливаем системную палитру. 

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

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

Листинг 5.5. Класс BmpViewWin

class BmpViewWin : public DirectDrawWin {

public:

 BmpViewWin();

protected:

 //{{AFX_MSG(BmpViewWin)

 afx_msg void OnKeyDown(UINT nChar, UINT nRepCnt, UINT nFlags);

 afx_msg void OnRButtonDown(UINT nFlags, CPoint point);

 afx_msg int OnCreate(LPCREATESTRUCT lpCreateStruct);

 afx_msg void OnDestroy();

 //}}AFX_MSG

 DECLARE_MESSAGE_MAP()

private:

 int SelectInitialDisplayMode();

 BOOL CreateCustomSurfaces() {

  return TRUE;

 }

 void DrawScene();

 void RestoreSurfaces();

 void GetSystemPalette();

 void ShowDialog();

 BOOL LoadBmp();

 void PageUp();

 void PageDown();

 void Home();

 void End();

 void Left(int inc=4);

 void Right(int inc=4);

 void Up(int inc=4);

 void Down(int inc=4);

private:

 BmpDialog* bmpdialog;

 LPDIRECTDRAWPALETTE syspal;

 CString fullfilename;

 CString filename;

 CString pathname;

 CRect displayrect;

 LPDIRECTDRAWSURFACE bmpsurf;

 CRect bmprect;

 int x,y;

 int xscroll, yscroll;

 int xlimit, ylimit;

 BOOL update_screen;

 DisplayModeArray palettemode, nonpalettemode;

};

Единственной открытой (public) функцией класса является конструктор, используемый для инициализации переменных. Далее мы объявляем четыре обработчика сообщений:

• OnKeyDown()

• OnRButtonDown()

• OnCreate()

• OnDestroy()

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

Функции OnCreate() и OnDestroy() предназначены соответственно для инициализации и освобождения структур данных приложения. В частности, функция OnCreate() создает диалоговое окно для выбора BMP-файла, а функция OnDestroy() уничтожает его.

Далее следуют объявления нескольких закрытых переменных. Функция SelectInitialDisplayMode() похожа на версию, созданную DirectDraw AppWizard и использованную в прошлых программах, но в нее внесены некоторые изменения. Кроме выбора исходного видеорежима, эта функция сохраняет текущую палитру Windows с помощью функции GetSystemPalette() (которая объявляется несколькими строками ниже функции SelectInitialDisplayMode()).

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

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

Функция ShowDialog() выводит диалоговое окно для выбора BMP-файла. Функция LoadBmp() по имени, полученному из диалогового окна, загружает BMP-файл на поверхность и инициализирует переменные x, y, xscroll, yscroll, xlimit и ylimit. Эти переменные предназначены для позиционирования поверхности в случае, если размер поверхности BMP-файла превышает размеры первичной поверхности.

Затем мы объявляем восемь функций, вызываемых при нажатии конкретных клавиш:

• PageUp()

• PageDown()

• Home()

• End()

• Left()

• Right()

• Up()

• Down()

Класс содержит несколько переменных, часть из которых упоминалась выше. Их назначение рассматривается при описании функций. 

Инициализация приложения 

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

Следующим этапом инициализации приложения является вызов функции SelectInitialDisplayMode(), которую мы обязаны переопределить. Наша версия SelectInitialDisplayMode() выбирает видеорежим с параметрами 640x480x16. Исходный видеорежим не так уж важен, потому что он, скорее всего, будет переопределен пользователем при выборе BMP-файла. Однако функция SelectInitialDisplayMode() (см. листинг 5.6) выполняет две дополнительные задачи.

Листинг 5.6. Функция BmpViewWin::SelectInitialDisplayMode()

int BmpViewWin::SelectInitialDisplayMode() {

 DisplayModeDescription desc;

 int i, nummodes=GetNumDisplayModes();

 DWORD w,h,d;

 for (i=0;i<nummodes;i++) {

  GetDisplayModeDimensions(i, w, h, d);

  desc.w=w;

  desc.h=h;

  desc.d=d;

  desc.desc.Format("%dx%dx%d", w, h, d );

  if (d==8) palettemode.Add(desc);

  else nonpalettemode.Add(desc);

 }

 DWORD curdepth=GetDisplayDepth();

 for (i=0;i>nummodes;i++) {

  GetDisplayModeDimensions(i, w, h, d);

  if (w==640 && h==480 && d==curdepth) return i;

 }

 for (i=0;i<nummodes;i++) {

  GetDisplayModeDimensions(i, w, h, d);

  if (d==curdepth) return i;

 }

 for (i=0;i>nummodes;i++) {

  GetDisplayModeDimensions(i, w, h, d);

  if (w==640 && h==480) return i;

 }

 GetSystemPalette();

 return 0;

}

Помимо выбора исходного видеорежима функция SelectInitialDisplayMode() используется для подготовки двух массивов: в первом хранятся сведения о палитровых (palettemode), а во втором — о беспалитровых (nonpalettemode) видеорежимах. Мы воспользуемся этими массивами позднее, при отображении диалогового окна. Когда пользователь выбирает файл с палитровым изображением, в список включаются только палитровые режимы; для беспалитровых режимов дело обстоит аналогично. Обратите внимание — в подготовленные массивы (коллекции структур DisplayModeDescription) включены строки, отображаемые в диалоговом окне.

Функция SelectInitialDisplayMode() также используется для вызова функции GetSystemPalette(), создающей палитру DirectDraw на базе системной палитры. Функция GetSystemPalette() выглядит так:

void BmpViewWin::GetSystemPalette() {

 PALETTEENTRY pe[256];

 HDC dc = ::GetDC(0);

 if (GetDeviceCaps(dc, RASTERCAPS) & RC_PALETTE) {

  GetSystemPaletteEntries(dc, 0, 256, pe);

  ddraw2->CreatePalette(DDPCAPS_8BIT, pe, &syspal, 0);

 }

 ::ReleaseDC(0, dc);

}

С помощью функции Win32 GetSystemPaletteEntries() мы получаем содержимое текущей палитры Windows и создаем по ее образцу палитру DirectDraw функцией CreatePalette() интерфейса DirectDraw. Указатель на созданную палитру syspal позднее будет применяться для восстановления системной палитры; это обеспечивает правильное отображение диалоговых окон Windows в 8-битных видеорежимах.

Следующий шаг инициализации приложения, заслуживающий нашего внимания, — функция OnCreate(). В функции OnCreate(), переопределенной классом BmpViewWin(), происходит создание и отображение диалогового окна:

int BmpViewWin::OnCreate(LPCREATESTRUCT lpCreateStruct) {

 if (DirectDrawWin::OnCreate(lpCreateStruct) == -1) return -1;

 ShowDialog();

 return 0;

} 

Выбор и отображение BMP-файла 

Функция ShowDialog() вызывается при запуске приложения и при выборе нового файла. ShowDialog() подготавливает DirectDraw к отображению диалогового окна, выводит окно, получает информацию о выбранном BMP-файле и выбранном видеорежиме и отображает содержимое файла. Функция ShowDialog() приведена в листинге 5.7.

Листинг 5.7. Функция ShowDialog()

void BmpViewWin::ShowDialog() {

 CRect displayrect=GetDisplayRect();

 if (displayrect.Width()<640) ddraw2->SetDisplayMode(640, 480, 8, 0, 0);

 if (GetDisplayDepth()==8) {

  ClearSurface(backsurf, 0);

  primsurf->SetPalette(syspal);

 } else {

  BltSurface(backsurf, bmpsurf, x, y);

 }

 ddraw2->FlipToGDISurface();

 ShowCursor(TRUE);

 if (bmpdialog==0) {

  bmpdialog=new BmpDialog();

  bmpdialog->SetArrays(&palettemode, &nonpalettemode);

 }

 if (bmpdialog->DoModal()==IDCANCEL) {

  PostMessage(WM_CLOSE);

  return;

 }

 fullfilename=bmpdialog->fullfilename;

 filename=bmpdialog->filename;

 pathname=bmpdialog->pathname;

 int index=bmpdialog->GetIndex();

 DWORD w,h,d;

 if (bmpdialog->FilePalettized()) {

  w=palettemode[index].w;

  h=palettemode[index].h;

  d=palettemode[index].d;

 } else {

  w=nonpalettemode[index].w;

  h=nonpalettemode[index].h;

  d=nonpalettemode[index].d;

 }

 if (GetDisplayDepth()==8) primsurf->SetPalette(palette);

 ActivateDisplayMode(GetDisplayModeIndex(w, h, d));

 LoadBmp();

 ShowCursor(FALSE);

}

Функция ShowDialog() прежде всего проверяет, что текущий видеорежим имеет разрешение не менее 640×480. Из обсуждения функции SelectInitialDisplayMode() нам известно, что при инициализации приложения это условие заведомо выполняется, однако функция ShowDialog() также вызывается при каждом отображении BMP-файла. Если в данный момент установлен режим низкого разрешения, то перед тем, как продолжать, мы переходим в режим 640×480×8. Это обусловлено тем, что режимы низкого разрешения часто являются режимами Mode X, а GDI в таких режимах не может правильно отображать диалоговые окна.

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

СОВЕТ

Диалоговое окно и изображение

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

Вызов функции FlipToGDISurface() гарантирует, что вывод GDI будет присутствовать на экране. Кроме того, мы включаем курсор мыши (отключенный при запуске приложения классом DirectDrawWin), чтобы для работы с диалоговым окном можно было пользоваться мышью.

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

Обратите внимание: при создании диалогового окна мы вызываем функцию SetArrays() и передаем ей массивы palettemode и nonpalettemode в качестве аргументов. Эта функция передает диалоговому окну информацию о видеорежимах, предназначенных для отображения как палитровых, так и беспалитровых изображений.

Диалоговое окно отображается функцией DoModal(). Пользователь сможет нажать кнопку Display лишь после того, как будет выбран BMP-файл и видеорежим. При этом мы сохраняем имя и путь выбранного BMP-файла и определяем параметры выбранного видеорежима. Если же пользователь закрывает диалоговое окно, мы посылаем сообщение WM_CLOSE и выходим из функции, завершая приложение.

Наконец, функция ActivateDisplayMode() активизирует выбранный видеорежим, функция LoadBmp() загружает содержимое BMP-файла, а курсор мыши отключается.

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

Листинг 5.8. Функция LoadBmp()

BOOL BmpViewWin::LoadBmp() {

 CWaitCursor cur;

 LPDIRECTDRAWSURFACE surf;

 surf=CreateSurface(filename, TRUE);

 if (surf) {

  if (bmpsurf)    bmpsurf->Release();

  bmpsurf=surf;

 } else {

  TRACE("failed to load new file\n");

  return FALSE;

 }

 displayrect=GetDisplayRect();

 TRACE("display: %d %d\n", displayrect.right, displayrect.bottom);

 GetSurfaceRect(bmpsurf, bmprect);

 TRACE("surface: %d %d\n", bmprect.right, bmprect.bottom);

 int mx = displayrect.Width()-bmprect.Width();

 if (mx<0) {

  xscroll=TRUE;

  xlimit=mx;

  x=0;

 } else {

  xscroll=FALSE;

  x=mx/2;

 }

 int my = displayrect.Height()-bmprect.Height();

 if (my<0) {

  yscroll=TRUE;

  ylimit=my;

  y=0;

 } else {

  yscroll=FALSE;

  y=my/2;

 }

 update_screen=TRUE;

 return TRUE;

}

Сначала функция LoadBmp() создает объект MFC CWaitCursor, чтобы на время ее работы на экране отображался курсор Windows в виде песочных часов. Затем она вызывает функцию CreateSurface() и передает ей в качестве аргумента имя выбранного BMP-файла. Реализация CreateSurface() рассматривалась ранее в этой главе, поэтому мы знаем, что эта функция загружает указанный BMP-файл на новую поверхность.

Затем LoadBmp() определяет параметры новой поверхности и текущий активный видеорежим и использует полученные данные для инициализации переменных класса BmpViewWin, связанных с прокруткой и позиционированием поверхностей. Если размеры поверхности меньше размеров видеорежима, поверхность центрируется на экране; если поверхность больше, следует разрешить ее прокрутку. Переменные x и y определяют текущую позицию на поверхности, а переменные xlimit и ylimit ограничивают диапазон прокрутки. Логические переменные xscroll и yscroll показывают, разрешена ли горизонтальная и вертикальная прокрутка поверхности.

Наконец, логической переменной update_screen присваивается значение TRUE; оно говорит о том, что функция DrawScene() должна обновить первичную поверхность. О функции DrawScene() речь пойдет в следующем разделе. 

Графический вывод 

Функция DrawScene() обновляет экран в зависимости от состояния логической переменной update_screen. Если переменная update_screen равна FALSE, предполагается, что содержимое первичной поверхности не устарело, и делать ничего не нужно. Функция DrawScene() выглядит так:

void BmpViewWin::DrawScene() {

 if (update_screen && bmpsurf) {

  ClearSurface(backsurf, 0);

  BltSurface(backsurf, bmpsurf, x, y);

  primsurf->Flip(0, DDFLIP_WAIT);

  update_screen=FALSE;

 }

}

Поскольку текущее положение поверхности рассчитывается в другом месте программы, а функция BltSurface() при необходимости автоматически выполняет отсечение, функция DrawScene() реализуется просто. Если переменная update_screen равна TRUE и существует поверхность для вывода, экран обновляется. Если поверхность не заполняет экран целиком, содержимое вторичного буфера стирается; если заполняет, то в стирании буфера нет необходимости. Затем функция BltSurface() копирует поверхность на вторичный буфер, а функция Flip() отображает изменения на экране. После того как обновление будет завершено, переменной update_screen присваивается значение FALSE. 

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

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

void BmpViewWin::OnKeyDown(UINT key, UINT nRepCnt, UINT nFlags) {

 switch (key) {

 case VK_UP:

  Up();

  break;

 case VK_DOWN:

  Down();

  break;

 case VK_LEFT:

  Left();

  break;

 case VK_RIGHT:

  Right();

  break;

 case VK_HOME:

  Home();

  break;

 case VK_END:

  End();

  break;

 case VK_PRIOR:

  PageUp();

  break;

 case VK_NEXT:

  PageDown();

  break;

 case VK_ESCAPE:

 case VK_SPACE:

 case VK_RETURN:

  ShowDialog();

  break;

 }

 DirectDrawWin::OnKeyDown(key, nRepCnt, nFlags);

}

С первого взгляда на листинг OnKeyDown() можно разве что понять, какие клавиши обрабатываются программой, потому что вся содержательная работа поручается другим функциям. Обратите внимание — при нажатии клавиш Escape, пробел и Enter вызывается одна и та же функция ShowDialog(). Это облегчает вызов диалогового окна после вывода изображения.

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

• Up()

• Down()

• Left()

• Right()

• Home()

• End()

• PageUp()

• PageDown()

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

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

void BmpViewWin::Up(int inc) {

 if (!yscroll) return;

 if (y+inc<0) {

  y+=inc;

  update_screen=TRUE;

 } else {

  y=0;

  update_screen=TRUE;

 }

}

void BmpViewWin::Down(int inc) {

 if (!yscroll) return;

 if (y-inc>=ylimit) {

  y-=inc;

  update_screen=TRUE;

 } else {

  y=ylimit;

  update_screen=TRUE;

 }

}

void BmpViewWin::Left(int inc) {

 if (!xscroll)  return;

 if (x+inc<0) {

  x+=inc;

  update_screen=TRUE;

 } else {

  x=0;

  update_screen=TRUE;

 }

}

void BmpViewWin::Right(int inc) {

 if (!xscroll) return;

 if (x-inc>=xlimit) {

  x-=inc;

  update_screen=TRUE;

 } else {

  x=xlimit;

  update_screen=TRUE;

 }

}

void BmpViewWin::Home() {

 if (xscroll && x!=0) {

  x=0;

  update_screen=TRUE;

 }

 if (yscroll && y!=0) {

  y=0;

  update_screen=TRUE;

 }

}

void BmpViewWin::End() {

 if (yscroll) {

  y=-(bmprect.Height()-displayrect.Height());

  update_screen=TRUE;

 }

 if (xscroll) {

  x=-(bmprect.Width()-displayrect.Width());

  update_screen=TRUE;

 }

}

void BmpViewWin::PageUp() {

 if (yscroll) {

  if (y-displayrect.Height()>0)   {

   y-=displayrect.Height();

   update_screen=TRUE;

  } else {

   y=0;

   update_screen=TRUE;

  }

 }

}

void BmpViewWin::PageDown() {

 if (yscroll) {

  if (y+displayrect.Height()<=ylimit) {

   y+=displayrect.Height();

   update_screen=TRUE;

  } else {

   y=ylimit;

   update_screen=TRUE;

  }

 }

}

Обработчикам клавиш со стрелками (Up(), Down(), Left(), Right()) можно передать необязательный аргумент, который определяет шаг прокрутки. Как видно из определения класса BmpViewWin (см. листинг 5.5), по умолчанию шаг прокрутки равен 4. 

Заключение 

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

BOOL CopyBmp(LPDIRECTDRAWSURFACE surface, HBITMAP bmp, int x, int y) {

 if (bmp==0) {

  TRACE("no bmp specified\n");

  return FALSE;

 }

 if (surface==0) {

  TRACE("no surface specified\n");

  return FALSE;

 }

 HDC imageDC = CreateCompatibleDC(0);

 SelectObject(imageDC, bmp);

 BITMAP bitmap;

 GetObject(bmp, sizeof(bitmap), &bitmap);

 int w=bitmap.bmWidth;

 int h=bitmap.bnHeight;

 DDSURFACEDESC desc;

 desc.dwSize = sizeof(desc);

 desc.dwFlags = DDSD+HEIGHT |DDSC_WIDTH;

 surface->GetSurfaceDesc(&desc);

 HDC dc;

 HRESULT result;

 if ((result=surface->GetDC(&dc))==DD_OK)) {

  Stretchblt(dc, 0, 0, desc.dwWidth, desc.dwHeight, imageDC, x, y, w, h, SRCCOPY);

  surface->ReleaseDC(dc);

 }

 DeleteDC(imageDC);

 return result==DD_OK;

}

Эта функция не имеет никакого отношения к программе этой главы, ее даже нет на CD-ROM. Она приведена с единственной целью — показать, что с помощью функции GetDC() интерфейса DirectDrawSurface и функции Win32 наподобие StretchBlt() можно легко скопировать растровое изображение Windows на поверхность. Разумеется, в этом случае приходится жертвовать скоростью, поскольку механизм GDI не отличается особым быстродействием, а его функции не поддаются оптимизации.

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

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

Глава 6. DirectInput

Давайте отдохнем от DirectDraw и познакомимся с библиотекой DirectInput. Конечно, эта книга посвящена компьютерной графике, но ввод информации пользователем — необходимая часть любого графического приложения. Применение DirectInput улучшает работу программ, так как ввод обнаруживается и обрабатывается с максимальной скоростью. После краткого знакомства с DirectInput API мы обсудим различные схемы получения пользовательского ввода, поддерживаемые DirectInput. Знакомство закончится созданием двух приложений: Qwerty и Smear. Программа Qwerty использует DirectInput для ввода с клавиатуры, а Smear работает с мышью.

Для компиляции и запуска программ этой главы вам понадобится DirectX 3 SDK. Пользователи Windows NT 4.0 должны установить Service Pack 3 или более позднюю версию.

Что такое DirectInput?

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

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

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

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

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

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

Быстродействие

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

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

Схемы получения данных

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

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

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

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

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

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

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

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

Уровни кооперации

Чтобы приложение могло задать нужную степень контроля над устройством, в DirectInput используются уровни кооперации. DirectInput, как и DirectDraw, позволяет установить монопольный (exclusive) и совместный (nonexclusive) режим доступа для каждого устройства. Если приложение DirectInput обладает монопольным доступом к устройству ввода, то никакое другое приложение заведомо не сможет получить монопольного доступа к тому же устройству (хотя сможет получить совместный доступ).

DirectInput также позволяет задать уровень кооперации для активного (foreground) и фонового (background) режимов работы — эти два термина часто приводят к недоразумениям. Активный доступ (foreground access) означает, что приложение работает с устройством только тогда, когда обладает фокусом ввода (по аналогии с тем, как ввод с клавиатуры по умолчанию передается приложению, обладающему фокусом). Фоновый доступ (background access) означает, что приложение может обращаться к устройству независимо от того, обладает ли оно фокусом ввода. Интуитивно кажется, будто активный доступ обладает большими возможностями, но на самом деле это не так. В программах Qwerty и Smear используется совместный активный уровень кооперации.

Данные об осевых смещениях

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

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

Захват устройств

Приложение DirectDraw в случае необходимости может уступить видеопамять другому приложению и восстановить ее, когда исходное приложение снова получит фокус. В DirectInput приложение тоже может потерять устройство и восстановить контроль над ним перед тем, как продолжить работу. В таких случаях говорят, что приложение захватывает устройство (acquire) или уступает его (unacquire). Для получения данных необходимо захватить устройство. Приложение может уступить устройство по требованию (доступ к устройству передается Windows или другому приложению) или автоматически (например, если DirectInput отбирает право доступа к устройству, чтобы передать его другому приложению).

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

DirectInput API

До выхода DirectX 3 библиотека DirectInput была построена на существующих функциях Win32 и не поддерживала ввода с клавиатуры или от мыши. В DirectX 3 появились COM-интерфейсы для клавиатуры и мыши, но все остальные устройства продолжали зависеть от функций Win32 (и особенно от функции joyGetPosEx()). В DirectX 5 зависимость DirectInput от Win32 полностью устранена, а все устройства ввода переведены на использование COM-интерфейсов. Работа с устройствами ввода реализована через три интерфейса:

• DirectInput

• DirectInputDevice

• DirectInputEffect

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

Интерфейс DirectInputDevice представляет устройство ввода. Его функции выполняют инициализацию, настройку, захват и отпускание устройств. Что еще важнее, DirectInputDevice содержит функции для получения данных от устройства.

Интерфейс DirectInputEffect применяется для обслуживания устройств с обратной связью. В этой книге он не используется.

Интерфейс DirectInput

Инициализация DirectInput происходит в тот момент, когда вы получаете указатель на интерфейс DirectInput функцией DirectInputCreate(). Затем полученным интерфейсом можно воспользоваться для создания экземпляров интерфейса DirectInputDevice, составления списка доступных устройств и даже для вызова панели управления DirectInput. Интерфейс DirectInput содержит следующие четыре функции:

• CreateDevice()

• EnumDevice()

• GetDeviceStatus()

• RunControlPanel()

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

• GUID_SysKeyboard

• GUID_SysMouse

Значения GUID остальных устройств можно получить функцией EnumDevices().

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

С помощью функции GetDeviceStatus() можно определить, доступно ли устройство для DirectInput в данный момент. Код возврата DI_OK означает, что устройство подключено и доступно. Функция RunControlPanel() вызывает приложение DirectInput Control Panel. Точнее, она вызывает приложение DirectX Control Panel и активизирует вкладку DirectInput.

Интерфейс DirectInputDevice

Доступ ко всем устройствам ввода, представленным в DirectInput, осуществляется через интерфейс DirectInputDevice. Интерфейс DirectInputDevice содержит следующие функции:

• Acquire()

• Unacquire()

• GetCapabilities()

• GetDeviceData()

• GetDeviceInfo()

• GetDeviceState()

• SetDataFormat()

• SetEventNotification()

• EnumObjects()

• GetObjectInfo()

• GetProperty()

• SetProperty()

• SetCooperativeLevel()

• RunControlPanel()

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

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

Функция Acquire() используется для начального захвата устройства и для восстановления нарушенной связи с устройством. Обычно связь между устройством ввода и DirectInput разрывается из-за того, что приложение теряет фокус ввода. Функция Unacquire() используется, как правило, для того, чтобы вернуть Windows право доступа к устройству. Например, при работе с меню необходимо уступить объекты DirectInputDevice, представляющие мышь и клавиатуру, чтобы Windows могли нормально обработать выбор команды меню.

Функция GetCapabilities() с помощью структуры DIDEVCAPS описывает возможности устройства, в том числе количество кнопок, количество осей и поддержку обратной связи. Кроме того, в структуру включаются описания конкретных особенностей (или ограничений) устройства, влияющих на его использование. Например, установка флага DIDC_POLLEDDEVICE означает, что от устройства можно получать лишь непосредственные данные.

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

Функция GetDeviceInfo() заполняет структуру DIDEVICEINSTANCE информацией об устройстве. В структуру заносятся значения GUID экземпляра и продукта для данного устройства, а также строки с неформальными описаниями. Ту же самую информацию можно получить функцией EnumDevices() интерфейса DirectInput, так что, строго говоря, эта функция не является обязательной.

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

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

• c_dfDIKeyboard

• c_dfDIMouse

• c_dfDIJoystick

Перед захватом устройства необходимо вызвать для него функцию SetDataFormat().

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

Каждое устройство ввода содержит один или несколько объектов. Для клавиатуры объект представляет отдельную клавишу. Для мыши объекты представляют каждую кнопку и каждую ось. Функция EnumObjects() составляет список объектов заданного устройства и возвращает для каждого объекта GUID и строку. Строка содержит неформальное описание объекта (например, «ось X» или «Right Shift»). GUID описывает тип объекта и может принимать одно из следующих значений:

• GUID_XAxis

• GUID_YAxis

• GUID_ZAxis

• GUID_RAxis

• GUID_UAxis

• GUID_VAxis

• GUID_Button

• GUID_Key

• GUID_POV

Чтобы успокоить вас, скажу, что функция EnumObjects() обычно не нужна, особенно для стандартных устройств. Например, для работы с клавиатурой вам не придется составлять список всех клавиш.

Функция GetObjectInfo() позволяет получить ту же информацию, что и EnumObjects(), но без предварительного составления списка объектов. Интересующий вас объект задается значением его смещения или идентификатора.

Функции GetProperty() и SetProperty() применяются для просмотра и установки параметров устройств (свойств), отсутствующих в DirectInput API. В DirectInput предусмотрен ряд стандартных свойств (например, свойства autocenter и deadzone для джойстиков), однако эти функции могут применяться и для других, нестандартных свойств.

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

Функция SetCooperativeLevel() определяет степень контроля над заданным устройством. Допускаются следующие значения:

• DISCL_BACKGROUND

• DISCL_EXCLUSIVE

• DISCL_FOREGROUND

• DISCL_NONEXCLUSIVE

Вызов функции SetCooperativeLevel() наряду с вызовом SetDataFormat() необходим для получения данных от устройства.

Наконец, функция RunControlPanel() запускает приложение Control Panel для типа устройства, представленного интерфейсом DirectInputDevice. Например, для стандартной клавиатуры эта функция запускает приложение Keyboard, которое также можно запустить из стандартной Control Panel. Не путайте ее с функцией RunControlPanel() интерфейса DirectInput, которая запускает общее приложение DirectInput Control Panel вместо приложения для конкретного устройства ввода.

Программа Qwerty

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

Примеров хватает в избытке. Скажем, когда кто-нибудь чихнет, мы привыкли говорить: «Будь здоров». Когда-то считалось, что чихание — акт (или во всяком случае попытка) изгнания злого духа из тела. Сегодня даже самые религиозные люди вряд ли считают чихание чем-то вроде экзорцизма в миниатюре, и все равно, если вы чихнете, кто-нибудь непременно пожелает вам здоровья. Мы просто не задумываемся над тем, что означают эти слова.

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

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

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

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

Рис. 6.1. Программа Qwerty

На экране изображены буквы Qwerty и названия еще нескольких клавиш. Программа с помощью DirectInput обнаруживает нажатые клавиши и рисует их в наклонном начертании. Все остальные клавиши рисуются прямо.

Класс QwertyWin

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

Листинг 6.1. Класс QwertyWin

class QwertyWin : public DirectDrawWin {

public:

 QwertyWin();

protected:

 //{{AFX_MSG(QwertyWin)

 afx_msg int OnCreate(LPCREATESTRUCT lpCreateStruct);

 afx_msg void OnDestroy();

 afx_msg void OnActivate(UINT nState, CWnd* pWndOther,    BOOL bMinimized);

 //}}AFX_MSG

 DECLARE_MESSAGE_MAP()

private:

 int SelectDriver();

 int SelectInitialDisplayMode();

 BOOL CreateCustomSurfaces();

 void DrawScene();

 void RestoreSurfaces();

private:

 LPDIRECTINPUT dinput;

 LPDIRECTINPUTDEVICE keyboard;

 BOOL esc_pressed;

 LPDIRECTDRAWSURFACE esc_up, esc_dn;

 LPDIRECTDRAWSURFACE space_up, space_dn;

 LPDIRECTDRAWSURFACE q_up, q_dn;

 LPDIRECTDRAWSURFACE w_up, w_dn;

 LPDIRECTDRAWSURFACE e_up, e_dn;

 LPDIRECTDRAWSURFACE r_up, r_dn;

 LPDIRECTDRAWSURFACE t_up, t_dn;

 LPDIRECTDRAWSURFACE y_up, y_dn;

 LPDIRECTDRAWSURFACE rctrl_up, rctrl_dn;

 LPDIRECTDRAWSURFACE lctrl_up, lctrl_dn;

 LPDIRECTDRAWSURFACE lalt_up, lalt_dn;

 LPDIRECTDRAWSURFACE ralt_up, ralt_dn;

};

Прежде чем двигаться дальше, обратите внимание на отсутствие обработчика OnKeyDown(). Во всех программах, рассмотренных нами ранее, функция OnKeyDown() обрабатывала сообщения от клавиатуры. В программе Qwerty мы пользуемся услугами DirectInput и потому не нуждаемся в OnKeyDown().

В самом начале объявляются три обработчика сообщений:

• OnCreate()

• OnDestroy()

• OnActivate()

Функция OnCreate() инициализирует и настраивает DirectInput, а функция OnDestroy() освобождает объекты DirectInput. Функция OnActivate(), вызываемая MFC при получении или потере фокуса, будет использована для повторного захвата клавиатуры.

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

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

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

После функций следуют переменные класса. Сначала объявляется указатель на интерфейс DirectInput(dinput), через него выполняется инициализация и осуществляются обращения к DirectInput. Переменная key — указатель на интерфейс DirectInputDevice, используемый для обращений к клавиатуре. Логическая переменная esc_pressed сигнализирует о завершении приложения.

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

Инициализация DirectInput

Инициализация DirectInput и DirectDraw выполняется в функции OnCreate(). DirectInput инициализируется версией OnCreate() класса QwertyWin, а DirectDraw — версией из DirectDrawWin. Функция QwertyWin::OnCreate() приведена в листинге 6.2.

Листинг 6.2. Функция QwertyWin::OnCreate()

int QwertyWin::OnCreate(LPCREATESTRUCT lpCreateStruct) {

 HRESULT r=DirectInputCreate(AfxGetInstanceHandle(),    DIRECTINPUT_VERSION, &dinput, 0);

 if (r!=DI_OK) {

  AfxMessageBox("DirectInputCreate() failed");

  return -1;

 }

 r = dinput->CreateDevice(GUID_SysKeyboard, &keyboard, 0);

 if (r!=DI_OK) {

  AfxMessageBox("CreateDevice(keyboard) failed");

  return -1;

 }

 r = keyboard->SetDataFormat(&c_dfDIKeyboard);

 if (r!=DI_OK) {

  AfxMessageBox("keyboard->SetDataFormat() failed");

  return -1;

 }

 r=keyboard->SetCooperativeLevel(GetSafeHwnd(), DISCL_FOREGROUND | DISCL_NONEXCLUSIVE);

 if (r!=DI_OK) {

  AfxMessageBox("keyboard->SetCooperativeLevel() failed");

  return -1;

 }

 if (DirectDrawWin::OnCreate(lpCreateStruct)==-1) return -1;

 return 0;

}

Прежде всего обратите внимание — версия OnCreate() базового класса вызывается лишь в конце функции. Это сделано для того, чтобы при неудачной инициализации DirectInput программа выводила окно сообщения и прекращала работу без инициализации DirectDraw.

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

HRESULT r=DirectInputCreate(AfxGetInstanceHandle(), DIRECTINPUT_VERSION, &dinput, 0);

Первый аргумент - логический номер экземпляра приложения, получаемый функцией AfxGetInstanceHandle(). Второй аргумент — номер версии DirectInput. В нашем случае используется константа DIRECTINPUT_VERSION, она определяется DirectInput в зависимости от версии SDK, использованной для компиляции приложения. Различные версии DirectInput более подробно рассматриваются в этой главе ниже. Третий аргумент DirectInputCreate() — адрес инициализируемого указателя, а четвертый — показатель агрегирования COM, который обычно равен нулю (агрегированием называется разновидность наследования, используемая в COM). Если инициализация DirectInput проходит успешно (то есть если DirectInputCreate() возвращает DI_OK), указатель dinput может использоваться для работы с DirectInput.

Затем мы создаем экземпляр интерфейса DirectInputDevice, который представляет клавиатуру. Я снова приведу соответствующую строку листинга 6.2:

r = dinput->CreateDevice(GUID_SysKeyboard, &keyboard, 0);

Функция CreateDevice() интерфейса DirectInput применяется для инициализации устройств DirectInput. В нашем случае первым аргументом является стандартная константа GUID_SysKeyboard, показывающая, что мы собираемся работать с системной клавиатурой. Второй аргумент — адрес указателя keyboard, через который мы впоследствии будем обращаться к клавиатуре. Третий аргумент — показатель агрегирования COM, в нашем случае он должен быть равен нулю.

Следующий шаг — выбор формата данных устройства. Для клавиатуры он выполняется просто:

r = keyboard->SetDataFormat(&c_dfDIKeyboard);

Функции SetDataFormat() интерфейса DirectInputDevice передается единственный аргумент — константа стандартного формата c_dfDIKeyboard. Программа Qwerty работает лишь с одним устройством (клавиатурой), но, как мы убедимся в программе Smear, формат данных должен задаваться отдельно для каждого устройства, используемого программой.

Затем мы задаем уровень кооперации устройства с помощью функции SetCooperativeLevel() интерфейса DirectInputDevice. Соответствующий фрагмент листинга 6.2 выглядит так:

r=keyboard->SetCooperativeLevel(GetSafeHwnd(), DISCL_FOREGROUND | DISCL_NONEXCLUSIVE);

Функция SetCooperativeLevel() получает два аргумента: логический номер окна и набор флагов, определяющих уровень кооперации. Функция GetSafeHwnd() определяет логический номер окна, а флаги DISCL_FOREGROUND и DISCL_NONEXCLUSIVE задают нужный уровень кооперации. Флаг активного режима DISCL_FOREGROUND присутствует потому, что на время активности другого приложения нам не потребуется ввод от клавиатуры, а флаг DISCL_NONEXCLUSIVE — потому, что DirectInput не позволяет установить монопольный доступ к клавиатуре.

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

Функция QwertyWin::OnCreate() завершается вызовом функции DirectDrawWin::OnCreate(), инициализирующей DirectDraw. Эта функция обсуждалась в главе 3.

Захват клавиатуры

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

void QwertyWin::OnActivate(UINT nState, CWnd* pWndOther, BOOL bMinimized) {

 DirectDrawWin::OnActivate(nState, pWndOther, bMinimized);

 if (nState!=WA_INACTIVE && keyboard) {

  TRACE("keyboard->Acquire()\n");

  keyboard->Acquire();

 }

}

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

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

Определение состояния клавиш

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

Листинг 6.3. Функция QwertyWin::DrawScene()

void QwertyWin::DrawScene() {

 static char key[256];

 keyboard->GetDeviceState(sizeof(key), &key);

 //---------- Клавиши QWERTY --------

 if (key[DIK_Q] & 0x80) BltSurface(backsurf, q_dn, 213, 70);

 else BltSurface(backsurf, q_up, 213, 70);

 if (key[DIK_W] & 0x80) BltSurface(backsurf, w_dn, 251, 70);

 else BltSurface(backsurf, w_up, 251, 70);

 if (key[DIK_E] & 0x80) BltSurface(backsurf, e_dn, 298, 70);

 else BltSurface(backsurf, e_up, 298, 70);

 if (key[DIK_R] & 0x80) BltSurface(backsurf, r_dn, 328, 70);

 else BltSurface(backsurf, r_up, 328, 70);

 if (key[DIK_T] & 0x80) BltSurface(backsurf, t_dn, 361, 70);

 else BltSurface(backsurf, t_up, 361, 70);

 if (key[DIK_Y] & 0x80) BltSurface(backsurf, y_dn, 393, 70);

 else BltSurface(backsurf, y_up, 393, 70);

 //---------------- LEFT CONTROL ---------------

 if (key[DIK_LCONTROL] & 0x80) BltSurface(backsurf, lctrl_dn, 50, 180);

 else BltSurface(backsurf, lctrl_up, 49, 180);

 //---------------- RIGHT CONTROL ---------------

 if (key[DIK_RCONTROL] & 0x80) BltSurface(backsurf, rctrl_dn, 490, 180);

 else BltSurface(backsurf, rctrl_up, 490, 180);

 //---------------- LEFT ALT ---------------

 if (key[DIK_LMENU] & 0x80) BltSurface(backsurf, lalt_dn, 100, 260);

 else BltSurface(backsurf, lalt_up, 100, 260);

 //---------------- RIGHT ALT ---------------

 if (key[DIK_RMENU] & 0x80) BltSurface(backsurf, ralt_dn, 440, 260);

 else BltSurface(backsurf, ralt_up, 440, 260);

 //---------------- SPACE -----------------

 if (key[DIK_SPACE] & 0x80) BltSurface(backsurf, space_dn, 170, 340);

 else BltSurface(backsurf, space_up, 170, 340);

 //---------- ESCAPE -------------

 if (key[DIK_ESCAPE] & 0x80) {

  BltSurface(backsurf, esc_dn, 0, 0);

  esc_pressed=TRUE;

 } else {

  BltSurface(backsurf, esc_up, 0, 0);

  if (esc_pressed) PostMessage(WM_CLOSE);

 }

 primsurf->Flip(0, DDFLIP_WAIT);

}

Состояние устройства определяется функцией GetDeviceState() интерфейса DirectInputDevice. Тип и размер второго аргумента GetDeviceState() зависят от типа устройства, а также от формата данных, заданного функцией SetDataFormat(). Для клавиатуры функция должна получать массив из 256 байт, где каждый байт соответствует одной клавише. В DirectInput предусмотрен набор клавиатурных констант, которые используются как индексы массива и позволяют ссылаться на нужные клавиши. DirectInput обозначает нажатие клавиши установкой старшего бита того байта, который представляет данную клавишу. Объявление массива и вызов функции GetDeviceState() находятся в верхней части листинга 6.3, я снова привожу их:

static char key[256];

keyboard->GetDeviceState(sizeof(key), &key);

Адрес массива клавиш передается во втором аргументе GetDeviceState(). Первый аргумент определяет размер данных в байтах.

Все готово к проверке элементов массива. Сначала мы проверяем, была ли нажата клавиша Q:

if (key[DIK_Q] & 0x80) BltSurface(backsurf, q_dn, 213, 70);

else BltSurface(backsurf, q_up, 213, 70);

Константа DIK_Q определяет индекс клавиши Q в массиве. Мы проверяем значение старшего бита; если бит установлен, значит, клавиша Q нажата, и мы копируем поверхность, изображающую клавишу Q в нажатом состоянии (q_dn), функцией BltSurface(). Если клавиша не нажата, копируется поверхность q_up.

Обратите внимание: каждой клавише соответствует отдельный элемент массива, даже для функционально одинаковых клавиш. Например, две клавиши Alt обрабатываются по отдельности. Кроме того, DirectInput не отличает прописных букв от строчных. Чтобы учесть регистр буквы, придется дополнительно проверить состояние обеих клавиш Shift.

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

Завершение приложения

Завершить работу DirectInput несложно — для этого достаточно освободить все интерфейсы DirectInput. В нашей программе это происходит в функции OnDestroy():

void QwertyWin::OnDestroy() {

 DirectDrawWin::OnDestroy();

 if (dinput) dinput->Release(), dinput=0;

 if (keyboard) {

  keyboard->Unacquire();

  keyboard->Release(), keyboard=0;

 }

}

Управление версией DirectInput

По умолчанию приложения DirectInput требуют, чтобы версия runtime-части DirectX, установленной на компьютере пользователя, совпадала с версией SDK, использованной для компиляции приложения, или превышала ее. Например, если вы создаете приложение с использованием DirectX 5 и запускаете его на компьютере с установленным DirectX 3, вызов функции DirectInputCreate() закончится неудачей.

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

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

Переопределяя стандартную константу DIRECTINPUT_VERSION, программа сообщает заголовочным файлам DirectInput о том, что необходимо обеспечить совместимость с DirectX 3. Это делается так:

#include

#include

#include

#include

#include

#include

#define DIRECTINPUT_VERSION 0x0300

#include

В приведенном фрагменте присутствуют директивы include для всех заголовочных файлов программы. Символическая константа DIRECTINPUT_VERSION должна быть определена до включения файла dinput.h (номер версии определяется старшим байтом).

В результате программа будет компилироваться как версией 3, так и версией 5 DirectX SDK (Microsoft пропустила версию DirectX 4). Получившиеся выполняемые файлы будут работать с runtime-частью DirectX 3 и выше. Поскольку Windows NT Service Pack 3 включает поддержку DirectX 3 для DirectInput, программы успешно компилируются и работают в Windows NT.

Программа Smear

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

Структура приложения

Хотя программа Smear демонстрирует работу с мышью, она также использует клавиатуру для проверки клавиши Escape. Работа с клавиатурой уже рассматривалась на примере программы Qwerty, поэтому мы не будем надолго задерживаться на ней.

Рис. 6.2. Программа Smear

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

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

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

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

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

Класс SmearWin

Основная функциональность программы Smear обеспечивается классом SmearWin (см. листинг 6.4).

Листинг 6.4. Класс SmearWin

class SmearWin : public DirectDrawWin {

public:

 SmearWin();

protected:

 //{{AFX_MSG(SmearWin)

 afx_msg int OnCreate(LPCREATESTRUCT lpCreateStruct);

 afx_msg void OnDestroy();

 afx_msg void OnActivate(UINT nState, CWnd* pWndOther, BOOL bMinimized);

 //}}AFX_MSG

 DECLARE_MESSAGE_MAP()

private:

 BOOL CreateFlippingSurfaces();

private:

 int SelectDriver();

 int SelectInitialDisplayMode();

 BOOL CreateCustomSurfaces();

 void DrawScene();

 void RestoreSurfaces();

private:

 BOOL InitKeyboard();

 BOOL InitMouse();

private:

 LPDIRECTINPUT dinput;

 LPDIRECTINPUTDEVICE mouse;

 LPDIRECTINPUTDEVICE keyboard;

 LPDIRECTDRAWSURFACE sphere;

 int x, y;

};

В классе объявлены три обработчика:

• OnCreate()

• OnDestroy()

• OnActivate()

Функция OnCreate() инициализирует DirectInput, а также готовит к работе мышь и клавиатуру. Функция OnDestroy() освобождает объекты DirectInput, инициализированные функцией OnCreate(). Функция OnActivate() захватывает клавиатуру в начале работы и при повторной активизации приложения.

Затем следует переопределенная функция DirectDrawWin::CreateFlippingSurfaces(). Нам не нужна переключаемая первичная поверхность, которая по умолчанию предоставляется классом DirectDrawWin, поэтому мы переопределяем эту функцию и создаем первичную поверхность, неспособную к переключению страниц.

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

Затем класс SmearWin объявляет функции InitMouse() и InitKeyboard(). Функция OnCreate() возлагает на них ответственность за инициализацию устройств.

Наконец, мы объявляем несколько переменных. Переменная dinput — указатель на интерфейс DirectInput, она используется для работы с DirectInput после инициализации. Переменные mouse и keyboard указывают на интерфейсы DirectInputDevice, они инициализируются функциями InitMouse() и InitKeyboard() соответственно. Указатель на поверхность sphere и целые переменные x и y предназначены для вывода и позиционирования единственной поверхности приложения.

Инициализация DirectInput

Функция OnCreate() инициализирует DirectInput, а затем инициализирует мышь и клавиатуру функциями InitMouse() и InitKeyboard(). Она выглядит так:

int SmearWin::OnCreate(LPCREATESTRUCT lpCreateStruct) {

 HRESULT r=DirectInputCreate(AfxGetInstanceHandle(), DIRECTINPUT_VERSION, &dinput, 0);

 if (r!=DI_OK) {

  AfxMessageBox("DirectInputCreate() failed");

  return -1;

 }

 if (InitMouse()==FALSE) return -1;

 if (InitKeyboard()==FALSE) return -1;

 if (DirectDrawWin::OnCreate(lpCreateStruct) == -1) return -1;

 return 0;

}

DirectInput инициализируется функцией DirectInputCreate(). При успешном вызове в переменную dinput заносится указатель на созданный объект DirectInput. Остальные аргументы DirectInputCreate() рассматривались в программе Qwerty.

Затем мы вызываем функции, которые инициализируют мышь и клавиатуру. Они рассматриваются ниже. Функция OnCreate() завершается вызовом версии OnCreate() базового класса, инициализирующим DirectDraw.

Инициализация мыши

Функция InitMouse() (см. листинг 6.5) готовит мышь к работе.

Листинг 6.5. Функция InitMouse()

BOOL SmearWin::InitMouse() {

 HRESULT r;

 r = dinput->CreateDevice(GUID_SysMouse, &mouse, 0);

 if (r!=DI_OK) {

  TRACE("CreateDevice(mouse) failed\n");

  return FALSE;

 }

 r = mouse->SetDataFormat(&c_dfDIMouse);

 if (r!=DI_OK) {

  TRACE("mouse->SetDataFormat() failed\n");

  return FALSE;

 }

 r = mouse->SetCooperativeLevel(GetSafeHwnd(), DISCL_NONEXCLUSIVE | DISCL_FOREGROUND);

 if (r!=DI_OK) {

  TRACE("mouse->SetCooperativeLevel() failed\n");

  return FALSE;

 }

 DIPROPDWORD property;

 property.diph.dwSize=sizeof(DIPROPDWORD);

 property.diph.dwHeaderSize=sizeof(DIPROPHEADER);

 property.diph.dwObj=0;

 property.diph.dwHow=DIPH_DEVICE;

 property.dwData=64;

 r = mouse->SetProperty(DIPROP_BUFFERSIZE, &property.diph);

 if (r!=DI_OK) {

  TRACE("mouse->SetProperty() failed (buffersize)\n");

  return FALSE;

 }

 return TRUE;

}

Функция InitMouse() включает в себя четыре этапа:

1. Создание объекта DirectInputDevice, представляющего мышь.

2. Определение формата данных, получаемых от мыши.

3. Установку уровня кооперации для мыши.

4. Инициализацию буфера данных устройства.

Функция CreateDevice() интерфейса DirectInput (первый этап) создает экземпляр интерфейса DirectInputDevice, представляющего системную мышь:

r = dinput->CreateDevice(GUID_SysMouse, &mouse, 0);

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

Если вызов функции CreateDevice() прошел успешно, переменной mouse присваивается указатель на созданный объект DirectInputDevice. Третий аргумент должен быть равен нулю, если только вы не пользуетесь агрегированием COM.

На втором этапе функция SetDataFormat() интерфейса DirectInputDevice сообщает DirectInput формат ожидаемых данных:

r = mouse->SetDataFormat(&c_dfDIMouse);

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

На третьем этапе определяется уровень кооперации для мыши:

r = mouse->SetCooperativeLevel(GetSafeHwnd(), DISCL_NONEXCLUSIVE | DISCL_FOREGROUND);

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

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

DIPROPDWORD property;

property.diph.dwSize=sizeof(DIPROPDWORD);

property.diph.dwHeaderSize=sizeof(DIPROPHEADER);

property.diph.dwObj=0;

property.diph.dwHow=DIPH_DEVICE;

property.dwData=64;

r = mouse->SetProperty(DIPROP_BUFFERSIZE, &property.diph);

Функция SetProperty() получает два аргумента: величину, которая определяет задаваемое свойство, и адрес структуры DIPROPDWORD. Среди прочего эта структура содержит значение свойства.

В нашем случае константа DIPROP_BUFFERSIZE говорит о том, что SetProperty() задает размер буфера. Поле dwSize структуры property равно 64; это значит, что мы заказываем буфер данных из 64 элементов. Размер буфера выбирается достаточно произвольно. Он должен быть достаточно большим, чтобы избежать переполнения, и достаточно малым, чтобы не тратить память напрасно.

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

Инициализация клавиатуры

Инициализация клавиатуры выполняется функцией InitKeyboard():

BOOL SmearWin::InitKeyboard() {

 HRESULT r;

 r = dinput->CreateDevice(GUID_SysKeyboard, &keyboard, 0);

 if (r!=DI_OK) {

  TRACE("CreateDevice(keyboard) failed");

  return FALSE;

 }

 r = keyboard->SetDataFormat(&c_dfDIKeyboard);

 if (r!=DI_OK)  {

  TRACE("keyboard->SetDataFormat() failed\n");

  return FALSE;

 }

 r=keyboard->SetCooperativeLevel(GetSafeHwnd(), DISCL_FOREGROUND | DISCL_NONEXCLUSIVE);

 if (r!=DI_OK) {

  TRACE("keyboard->SetCooperativeLevel() failed\n");

  return FALSE;

 }

 return TRUE;

}

Инициализация клавиатуры происходит так же, как и в программе Qwerty.

Захват мыши и клавиатуры

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

void SmearWin::OnActivate(UINT nState, CWnd* pWndOther, BOOL bMinimized) {

 DirectDrawWin::OnActivate(nState, pWndOther, bMinimized);

 if (nState!=WA_INACTIVE) {

  if (keyboard) {

   TRACE("keyboard->Acquire()\n");

   keyboard->Acquire();

  }

  if (mouse) {

   TRACE("mouse->Acquire()\n");

   mouse->Acquire();

  }

 }

}

Функция Acquire() вызывается для каждого устройства независимо от того, уступалось ли оно. DirectInput игнорирует лишние вызовы Acquire().

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

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

Листинг 6.6. Функция SmearWin::DrawScene()

void SmearWin::DrawScene() {

 static char key[256];

 keyboard->GetDeviceState(sizeof(key), &key);

 if (key[DIK_ESCAPE] & 0x80) PostMessage(WM_CLOSE);

 BOOL done=FALSE;

 while (!done) {

  DIDEVICEOBJECTDATA data;

  DWORD elements=1;

  HRESULT r=mouse->GetDeviceData(sizeof(data), &data,     &elements, 0);

  if (r==DI_OK && elements==1) {

   switch(data.dwOfs) {

   case DIMOFS_X:

    x+=data.dwData;

    break;

   case DIMOFS_Y:

    y+=data.dwData;

    break;

   }

  } else if (elements==0) done=TRUE;

 }

 BltSurface(primsurf, sphere, x, y, TRUE);

}

Функция DrawScene() сначала проверяет состояние клавиатуры функцией GetDeviceState() интерфейса DirectInputDevice. Если была нажата клавиша Escape, она посылает сообщение WM_CLOSE, что приводит к завершению приложения. О функции GetDeviceState() и проверке состояния клавиш рассказано в программе Qwerty, поэтому сейчас мы займемся кодом, относящимся к мыши. DrawScene() в цикле извлекает элементы буфера мыши. Для получения данных, а также для проверки отсутствия элементов при пустом буфере используется функция GetDeviceData() интерфейса DirectInputDevice.

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

typedef struct {

 DWORD dwOfs;

 DWORD dwData;

 DWORD dwTimeStamp;

 DWORD dwSequence;

} DIDEVICEOBJECTDATA, *LPDIDEVICEOBJECTDATA;

Для мыши поле dwOfs определяет тип события. В DirectInput определены следующие константы, описывающие ввод от мыши:

• DIMOFS_X

• DIMOFS_Y

• DIMOFS_Z

• DIMOFS_BUTTON0

• DIMOFS_BUTTON1

• DIMOFS_BUTTON2

• DIMOFS_BUTTON3

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

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

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

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

while (!done) {

 DIDEVICEOBJECTDATA data;

 DWORD elements=1;

 HRESULT r=mouse->GetDeviceData(sizeof(data), &data, &elements, 0);

 if (r==DI_OK && elements==1) {

  switch (data.dwOfs) {

  case DIMOFS_X:

   x+=data.dwData;

   break;

  case DIMOFS_Y:

   y+=data.dwData;

   break;

  }

 } else if (elements==0) done=TRUE;

}

Третий аргумент GetDeviceData() используется двояко. Значение, передаваемое функции, определяет количество элементов, извлекаемых из буфера. В нашем случае используется всего одна структура DIDEVICEOBJECTDATA, поэтому передается число 1. При возврате из функции это значение показывает количество полученных элементов.

Если вызов функции прошел успешно и значение elements осталось равным 1, значит, элемент буфера был прочитан, а поля dwOfs и dwData определяют тип события. Нулевое значение elements говорит о том, что буфер пуст и цикл завершается.

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

BltSurface(primsurf, sphere, x, y, TRUE);

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

Завершение приложения

Перед завершением приложения MFC вызывает функцию OnDestroy(); мы воспользуемся ею для освобождения объектов DirectInput. Функция OnDestroy() выглядит так:

void SmearWin::OnDestroy() {

 DirectDrawWin::OnDestroy();

 if (dinput) dinput->Release(), dinput=0;

 if (keyboard) {

  keyboard->Unacquire();

  keyboard->Release(), keyboard=0;

 }

 if (mouse) {

  mouse->Unacquire();

  mouse->Release(), mouse=0;

 }

}

Функция OnDestroy() просто освобождает каждый объект DirectInput (и вызывает одноименную функцию базового класса).

Заключение

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

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

Глава 7. Проблема курсора

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

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

Более того, курсор может оказаться искаженным или вообще отсутствовать. Например, в видеорежимах Mode X используется нелинейная организация пикселей. Windows пытается вывести курсор мыши, но поскольку режимы Mode X не поддерживаются Windows GDI, изображение курсора портится. Кроме того, Windows не умеет выводить курсор мыши на вторичных видеоустройствах (например, на видеокартах с чипами 3Dfx). Вывод продолжает поступать на первичное видеоустройство независимо от того, какое устройство активно в данный момент, поэтому курсор мыши пропадает.

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

Раз курсор мыши отображается самим приложением, а не Windows, частота его прорисовки зависит от быстродействия приложения. Если приложение постоянно работает на 75 FPS, это будет приемлемо, но что если частота вывода кадров упадет до 30 FPS и ниже? С падением частоты курсор будет все медленнее реагировать на действия пользователя.

Существует множество причин, по которым приложение может иметь низкую частоту вывода кадров. Трехмерные приложения предъявляют особенно жесткие требования к системе и часто работают с частотой 30 FPS и менее. Но «тормозить» могут и обычные, не трехмерные приложения. Сложное приложение, выводящее сотни объектов, будет иметь низкий FPS (конечно, все зависит от компьютера и видеокарты). Кроме того, режимы High и True Color часто оказываются намного медленнее 8-битных режимов.

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

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

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

Частичное обновление экрана

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Зачем нужна многопоточность?

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

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

И последнее замечание: на однопроцессорном компьютере многопоточные приложения работают не быстрее однопоточных. Скорость возрастает лишь на многопроцессорном компьютере с многопроцессорной операционной системой (например, Windows NT).

Синхронизация потоков

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

Потоки координируются с помощью событий (events), которые передают информацию о состоянии одного или нескольких потоков. Событие может быть установленным (signaled) или сброшенным (unsignaled). Конкретный смысл событий может быть разным, но обычно они сигнализируют о блокировке потока.

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

Блокировка потоков чаще всего используется для защиты совместных ресурсов от одновременного доступа со стороны нескольких потоков. Мутекс (mutex, сокращение от mutually exclusive, то есть «взаимоисключающий») представляет собой объект, который может в любой момент времени принадлежать лишь одному потоку, гарантируя безопасность доступа к связанному с ним ресурсу. Когда мутекс принадлежит некоторому потоку, все остальные потоки, пытающиеся получить его в свое распоряжение, блокируются до освобождения мутекса.

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

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

Классы потоков в MFC

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

• CWinThread

• CSyncObject

• CEvent

• CCriticalSection

• CMutex

• CSemaphore

• CSingleLock

• CMultiLock

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

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

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

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

Решение проблемы курсора

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

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

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

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

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

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

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

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

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

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

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

Поток ввода

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

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

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

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

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

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

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

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

Что делать с кнопками мыши?

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

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

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

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

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

Программа Cursor

Программа Cursor использует описанную выше методику и выводит на экран изображение вращающейся спирали, меню задержки и курсор мыши. По умолчанию программа выводит кадры максимально часто, но меню задержки позволяет уменьшить частоту вывода за счет задержки в основном потоке (максимальная задержка равна 500 миллисекундам, при этом приложение замедляется до 2 FPS). Если бы курсор не управлялся отдельным потоком, его обновление происходило бы лишь с выводом очередного кадра. Но поскольку курсор мыши не зависит от основного потока, он нормально реагирует на действия пользователя при любой частоте вывода. Программа Cursor изображена на рис. 7.1.

Рис. 7.1. Программа Cursor

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

СОВЕТ

Как создать собственный курсор

Программа Cursor может работать с курсором любого размера. В версии программы на CD-ROM использован небольшой курсор (12×20 пикселей), но вы можете легко изменить этот стандартный размер. Для этого достаточно заменить cursor_08.bmp и/или cursor_24.bmp файлами с более крупными изображениями курсоров.

По умолчанию приложение работает в 8-битном видеорежиме и соответственно с 8-битным курсором. Многое зависит от вашего графического редактора, но, скорее всего, вы избавитесь от проблем с палитрой, если воспользуетесь файлом cursor_08.bmp с CD-ROM как шаблоном для создания нестандартного курсора. С курсором формата True Color дело обстоит проще, но, чтобы воспользоваться им, придется слегка подправить функцию SelectInitialDisplayMode(), чтобы активизировать беспалитровый видеорежим вместо палитрового.

Класс CursorWin 

Программа Cursor, как и все остальные программы этой книги, построена на базе структурных классов DirectDrawWin и DirectDrawApp. Эти классы остались неизменными, а вся специфика приложения реализуется классом CursorWin. На практике функциональность курсора мыши, вероятно, следовало бы встроить в структурный класс. И все же для наглядности я объединил код для работы с курсором со специфическим кодом приложения. Класс CursorWin приведен в листинге 7.1.

Листинг 7.1. Класс CursorWin

class CursorWin : public DirectDrawWin {

public:

 CursorWin();

protected:

 //{{AFX_MSG(CursorWin)

 afx_msg int OnCreate(LPCREATESTRUCT lpCreateStruct);

 afx_msg void OnDestroy();

 afx_msg void OnActivate(UINT nState, CWnd* pWndOther,     BOOL bMinimized);

 //}}AFX_MSG

 DECLARE_MESSAGE_MAP()

private:

 int SelectDriver();

 int SelectInitialDisplayMode();

 BOOL CreateCustomSurfaces();

 void DrawScene();

 void RestoreSurfaces();

private:

 BOOL InitMouse();

 BOOL InitKeyboard();

 BOOL UpdateDelaySurface();

private:

 //------- Функции потока ввода ------

 static DWORD MouseThread(LPVOID);

 BOOL UpdateCursorSimpleCase(int curx, int cury, int oldcurx, int oldcury);

 BOOL UpdateCursorComplexCase(int curx, int cury, int oldcurx, int oldcury);

private:

 //------- Данные мыши -------

 static LPDIRECTINPUTDEVICE mouse;

 static CCriticalSection critsection;

 static CWinThread* mousethread;

 static CEvent* mouse_event[2];

 static int cursor_width;

 static int cursor_height;

 static LPDIRECTDRAWSURFACE cursor;

 static LPDIRECTDRAWSURFACE cursor_under;

 static LPDIRECTDRAWSURFACE cursor_union;

 static int curx, cury;

 static int oldcurx, oldcury;

 static CList<MouseClickData, MouseClickData> mouseclickqueue;

private:

 //------- Данные приложения -------

 LPDIRECTINPUT dinput;

 LPDIRECTINPUTDEVICE keyboard;

 LPDIRECTDRAWSURFACE coil[coil_frames];

 LPDIRECTDRAWSURFACE dm_surf;

 int dm_index;

 DWORD menubarfillcolor;

 HFONT largefont, smallfont;

};

Класс CursorWin объявляет три обработчика сообщений: OnCreate(), OnDestroy() и OnActivate(). Функция OnCreate() инициализирует DirectDraw, DirectInput и поток ввода. Функция OnDestroy() освобождает интерфейсы DirectX и завершает поток ввода. Функция OnActivate() обеспечивает захват мыши и клавиатуры на период активности приложения.

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

• SelectDriver()

• SelectInitialDisplayMode()

• CreateCustomSurfaces()

• DrawScene()

• RestoreSurfaces()

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

Затем объявляются функции InitMouse() и InitKeyboard(). Эти функции используются функцией OnCreate() и отвечают за инициализацию объектов DirectInput, предназначенных для работы с мышью и клавиатурой. Функция InitKeyboard() совпадает с одноименными функциями программ Qwerty и Smear из главы 6, поэтому она также не рассматривается. Однако функция InitMouse() помимо инициализации мыши запускает поток ввода. Вскоре мы рассмотрим эту функцию.

Функция UpdateDelaySurface() готовит к выводу поверхность меню задержки. Она выводит текст меню и выделяет текущую задержку.

Далее в классе CursorWin объявляются три функции потока мыши:

• MouseThread()

• UpdateCursorSimpleCase()

• UpdateCursorComplexCase()

Функция MouseThread() реализует поток ввода. Когда основной поток создает поток ввода, он передает указатель на статическую функцию MouseThread(). Созданный поток использует эту функцию в качестве точки входа и продолжает выполнять ее до возврата из функции или вызова функции AfxEndThread(). Функция MouseThread() обновляет изображение курсора с помощью функций UpdateCursorSimpleCase() и UpdateCursorComplexCase().

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

Обратите внимание: в число переменных мыши входят объекты классов CCriticalSection, CEvent и CWinThread, предназначенные для синхронизации двух потоков нашей программы.

Мы объявляем два указателя на объекты CEvent — один используется для оповещений DirectInput, а второй сигнализирует о завершении потока.

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

Инициализация приложения 

Наше знакомство с программой Cursor начинается с функции OnCreate(), которая отвечает за инициализацию DirectDraw, DirectInput и потока ввода. Функция OnCreate() приведена в листинге 7.2.

Листинг 7.2. Функция CursorWin::OnCreate()

int CursorWin::OnCreate(LPCREATESTRUCT lpCreateStruct) {

 HRESULT r=DirectInputCreate(AfxGetInstanceHandle(), DIRECTINPUT_VERSION, &dinput, 0);

 if (r!=DI_OK) {

  AfxMessageBox("DirectInputCreate() failed");

  return -1;

 }

 if (InitMouse()==FALSE)  return -1;

 if (InitKeyboard()==FALSE)  return -1;

 if (DirectDrawWin::OnCreate(lpCreateStruct) == -1) return -1;

 mousethread->ResumeThread();

 return 0;

}

Сначала OnCreate() инициализирует DirectInput функцией DirectInputCreate(). Затем мышь и клавиатура инициализируются функциями InitMouse() и InitKeyboard(), после чего вызывается функция DirectDrawWin::OnCreate(). Функция InitMouse(), которую мы рассмотрим чуть ниже, создает поток ввода, доступ к которому осуществляется через указатель mousepointer. Однако поток ввода создается в приостановленном состоянии, чтобы он не пытался преждевременно обращаться к первичной поверхности. Поток будет запущен лишь после инициализации DirectDraw. Приостановленный поток активизируется функцией CWinThread::ResumeThread().

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

Листинг 7.3. Функция InitMouse()

BOOL CursorWin::InitMouse() {

 HRESULT r;

 r = dinput->CreateDevice(GUID_SysMouse, &mouse, 0);

 if (r!=DI_OK) {

  TRACE("CreateDevice(mouse) failed\n");

  return FALSE;

 }

 r = mouse->SetDataFormat(&c_dfDIMouse);

 if (r!=DI_OK) {

  TRACE("mouse->SetDataFormat() failed\n");

  return FALSE;

 }

 r = mouse->SetCooperativeLevel(GetSafeHwnd(),    DISCL_NONEXCLUSIVE | DISCL_FOREGROUND);

 if (r!=DI_OK) {

  TRACE("mouse->SetCooperativeLevel() failed\n");

  return FALSE;

 }

 DIPROPDWORD property;

 property.diph.dwSize=sizeof(DIPROPDWORD);

 property.diph.dwHeaderSize=sizeof(DIPROPHEADER); 

 property.diph.dwObj=0;

 property.diph.dwHow=DIPH_DEVICE;

 property.dwData=64;

 r = mouse->SetProperty(DIPROP_BUFFERSIZE, &property.diph);

 if (r!=DI_OK) {

  TRACE("mouse->SetProperty() failed (buffersize)\n");

  return FALSE;

 }

 mouse_event[mouse_event_index]=new CEvent;

 mouse_event[quit_event_index]=new CEvent;

 r = mouse->SetEventNotification(*mouse_event[mouse_event_index]);

 if (r!=DI_OK) {

  TRACE("mouse->SetEventNotification() failed\n");

  return FALSE;

 }

 mousethread=AfxBeginThread((AFX_THREADPROC)MouseThread, this, THREAD_PRIORITY_TIME_CRITICAL, 0, CREATE_SUSPENDED);

 return TRUE;

}

Функция InitMouse() состоит из семи этапов:

1. Инициализация устройства DirectInput, которое представляет мышь.

2. Выбор формата данных, получаемых от мыши.

3. Установка уровня кооперации для мыши.

4. Инициализация буфера данных мыши.

5. Создание двух объектов CEvent.

6. Инициализация механизма оповещений DirectInput.

7. Создание потока ввода.

На этапах 1-4 происходит нормальная инициализация DirectInput, подробно рассмотренная в главе 6, поэтому основное внимание будет уделено этапам 5, 6 и 7.

На этапе 5 создаются два динамических объекта CEvent, а полученные указатели сохраняются в маленьком массиве. Положение этих указателей в массиве определяется константами mouse_event_index и quit_event_index (которые равны 0 и 1 соответственно). Первое событие блокирует или активизирует поток ввода в зависимости от того, поступили ли от мыши новые данные. Второе событие сообщает потоку мыши о завершении приложения. Как мы вскоре увидим, указатели сохраняются в массиве для того, чтобы мы могли заблокировать поток мыши по двум событиям одновременно.

На этапе 6 функция SetEventNotification() интерфейса DirectInputDevice приказывает DirectInput устанавливать событие мыши при появлении новых данных. Функция SetEventNotification() получает один аргумент типа HANDLE, однако наш объект CEvent наследует оператор преобразования типа от класса CSyncObject, благодаря чему мы можем использовать объект CEvent так, словно он имеет тип HANDLE (тип HANDLE, в частности, используется потоковым API Win32 для представления событий).

На этапе 7 создается поток ввода от мыши. Я снова приведу соответствующий фрагмент листинга 7.2:

mousethread=AfxBeginThread((AFX_THREADPROC)MouseThread, this, THREAD_PRIORITY_TIME_CRITICAL, 0, CREATE_SUSPENDED);

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

Первый аргумент AfxBeginThread — указатель на функцию, выполняемую новым потоком; в нашем случае используется функция MouseThread(). Второй аргумент — значение, которое передается функции потока при вызове. Мы передаем указатель this, чтобы функция MouseThread() могла обращаться к членам нашего класса.

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

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

На создании потока ввода работа функции InitMouse() заканчивается. Благодаря флагу CREATE_SUSPENDED поток ввода приостанавливается до момента, когда основной поток завершит инициализацию DirectDraw. Затем, перед возвратом из функции OnCreate(), поток ввода активизируется функцией ResumeThread() (см. листинг 7.2).

Функция DrawScene() 

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

Листинг 7.4. Функция DrawScene()

void CursorWin::DrawScene() {

 //------ Проверить клавишу ESCAPE -------

 static char key[256];

 keyboard->GetDeviceState(sizeof(key), &key);

 if (key[DIK_ESCAPE] & 0x80) PostMessage(WM_CLOSE);

 //------ Обычные задачи ------

 ClearSurface(backsurf, 0);

 BltSurface(backsurf, dm_surf, 539, 0);

 static coil_idx;

 BltSurface(backsurf, coil[coil_idx], coilx, coily);

 coil_idx=(coil_idx+1)%coil_frames;

 //------ Начало синхронизированной секции ------

 critsection.Lock();

 //------ Сохранить область вторичного буфера под курсором

 RECT src;

 src.left=curx;

 src.top=cury;

 src.right=curx+cursor_width;

 src.bottom=cury+cursor_height;

 cursor_under->BltFast(0, 0, backsurf, &src, DDBLTFAST_WAIT);

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

 backsurf->BltFast(curx, cury, cursor, 0, DDBLTFAST_SRCCOLORKEY | DDBLTFAST_WAIT);

 primsurf->Flip(0, DDFLIP_WAIT);

 while (primsurf->GetFlipStatus(DDGFS_ISFLIPDONE)!=DD_OK);

 // ничего не делать (ждать, пока закончится

 // переключение страниц)

 int x, y;

 BOOL newclick=FALSE;

 int count=mouseclickqueue.GetCount();

 while (count--) {

  MouseClickData mc=mouseclickqueue.RemoveTail();

  if (mc.button==0) {

   x=mc.x;

   y=mc.y;

   newclick=TRUE;

  }

 }

 critsection.Unlock();

 //------ Конец синхронизированной секции -------

 //------ Сделать паузу в соответствии с выбранной задержкой ----

 if (delay_value[dm_index]!=0) Sleep(delay_value[dm_index]);

 //------ Обновить меню задержки --------

 if (newclick) {

  int max_index=sizeof(delay_value)/sizeof(int)-1;

  int menux=screen_width-dm_width+dm_margin;

  int menuw=dm_width-dm_margin*2;

  if (x>=menux && x<=menux+menuw) {

   int index=(y-dm_header)/dm_entrysize;

   if (index>=0 && index<=max_index && index!=dm_index) {

    dm_index=index;

    UpdateDelaySurface();

   }

  }

 }

}

Функция DrawScene() состоит из семи этапов:

1. Проверка клавиши Escape.

2. Подготовка нового кадра во вторичном буфере.

3. Обновление курсора (также во вторичном буфере).

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

5. Проверка очереди событий мыши.

6. Проверка очереди событий мыши.

7. Обновление поверхности меню задержки.

Первый этап выполняется функцией GetDeviceState() интерфейса DirectInputDevice. Если будет обнаружено нажатие клавиши Escape, функция посылает сообщение WM_CLOSE, сигнализируя о завершении приложения.

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

На этапах 3, 4 и 5 программа обращается к ресурсам, используемым потоком ввода, поэтому необходимо воспользоваться критической секцией. Объект класса CCriticalSection (critsection), объявленный в классе CursorWin (см. листинг 7.1), блокируется функцией Lock(). Эта функция пытается получить доступ к критической секции. Если попытка оказывается удачной, функция захватывает критическую секцию и завершается. После этого можно смело работать с совместными ресурсами — поток заведомо обладает монопольным правом доступа к ним. Если функции Lock() будет отказано в доступе (из-за того что критическая секция в данный момент захвачена потоком ввода), функция Lock() блокирует основной поток до освобождения критической секции.

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

На этапе 4 выполняется переключение страниц, однако оно происходит сложнее, чем обычно. Это связано с тем, что функция Flip() интерфейса DirectDrawSurface на самом деле не выполняет переключения. Она лишь приказывает видеокарте переключить страницы и после этого завершается. Фактическое переключение страниц происходит после того, как будут закончены все ранее начатые операции блиттинга во вторичный буфер. Для наших целей этого недостаточно. Нам нужно, чтобы переключение страниц было закончено до кода критической секции, потому что в противном случае поток ввода сможет обновить первичную поверхность во время переключения страниц. С помощью цикла while и функции GetFlipStatus() интерфейса DirectDrawSurface мы опрашиваем DirectDraw до тех пор, пока переключение страниц не закончится (в DirectDraw не предусмотрена блокировка по этой операции, но даже если бы она и была, переключение страниц происходит слишком быстро и не оправдывает блокировки потока).

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

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

Этап 6 не требует синхронизации, поэтому мы вызываем функцию CCriticalSection::Unlock(). Если к этому моменту поток ввода был заблокирован и ожидал доступа к своей критической секции, вызов Unlock() позволит ему войти в нее.

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

Теперь мы знаем, как происходит обновление экрана в основном потоке. Давайте посмотрим, как работает поток ввода.

Поток ввода 

Если не считать двух вспомогательных функций, весь поток ввода реализован в виде одной функции. Функция MouseThread() приведена в листинге 7.5.

Листинг 7.5. Функция MouseThread()

DWORD CursorWin::MouseThread(LPVOID p) {

 TRACE("starting mouse thread\n");

 CursorWin* win=(CursorWin*)p;

 while(TRUE) {

  CMultiLock mlock((CSyncObject**)mouse_event, 2);

  DWORD event=mlock.Lock(INFINITE, FALSE);

  if (event-WAIT_OBJECT_0==quit_event_index)  {

   TRACE("got quit message: quitting mouse thread\n");

   return 0;

  }

  critsection.Lock();

  oldcurx=curx;

  oldcury=cury;

  BOOL buffer_empty=FALSE;

  while (!buffer_empty) {

   DIDEVICEOBJECTDATA data;

   DWORD elements=1;

   if (mouse==0) {

    TRACE("invalid pointer: quitting mouse thread\n");

    return 0;

   }

   HRESULT r=mouse->GetDeviceData(sizeof(data), &data, &elements, 0);

   if (r==DI_OK && elements==1)   {

    static MouseClickData mc;

    switch data.dwOfs) {

    case DIMOFS_X:

     curx+=data.dwData;

     break;

    case DIMOFS_Y:

     cury+=data.dwData;

     break;

    case DIMOFS_BUTTON0:

     if (data.dwData & 0x80) {

      mc.x=curx;

      mc.y=cury;

      mc.button=0;

      mouseclickqueue.AddHead(mc);

     }

     break;

    case DIMOFS_BUTTON1:

     if (data.dwData & 0x80) {

      mc.x=curx;

      mc.y=cury;

      mc.button=1;

      mouseclickqueue.AddHead(mc);

     }

     break;

    }

   } else buffer_empty=TRUE;

  }

  if (curx<0) curx=0;

  if (cury<0) cury=0;

  if (curx>=screen_width-cursor_width) curx=screen_width-cursor_width-1;

  if (cury>=screen_height-cursor_height) cury=screen_height-cursor_height-1;

  if (curx==oldcurx && cury==oldcury) {

   //----- обновление курсора не требуется ------

   goto nevermind;

  } else if (abs(curx-oldcurx) >= cursor_width || abs(cury-oldcury) >= cursor_height) {

   //----- простой случай: прямоугольники нового

   // и старого курсора не перекрываются -----

   win->UpdateCursorSimpleCase(curx, cury, oldcurx, oldcury);

  } else {

   //----- сложный случай: прямоугольники нового

   // и старого курсора перекрываются -----

   win->UpdateCursorComplexCase(curx, cury, oldcurx, oldcury);

  }

  nevermind:;

  critsection.Unlock();

 }

 TRACE("leaving mouse thread\n");

 return 0;

};

Функция MouseThread() имеет один параметр — значение, передаваемое функции AfxBeginThread() при создании потока (см. листинг 7.3). Мы передавали указатель this, поэтому сейчас сможем присвоить его значение указателю на класс CursorWin (переменная win). В функции MouseThread() указатель win будет использоваться для доступа к членам класса CursorWin.

Функция MouseThread() в цикле выполняет блокировку по двум событиям. Класс CMultiLock позволяет блокироваться как по событиям от мыши, так и по событию завершения потока. Фактическая блокировка выполняется функцией CMultiLock::Lock(). По умолчанию функция Lock() блокирует поток до установки всех (в данном случае  - двух) заданных событий. Мы изменяем это поведение и передаем FALSE в качестве второго аргумента Lock(), показывая тем самым, что функция должна снимать блокировку при установке хотя бы одного из этих событий.

Когда любое из двух событий переходит в установленное состояние, функция Lock() завершается, и мы проверяем код возврата. Если выясняется, что было установлено событие завершения потока (обозначенное константой quit_event_index), мы выходим из функции MouseThread(), тем самым завершая поток. В противном случае активизация потока вызвана событием мыши, поэтому мы переходим к обработке новых данных.

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

Мы в цикле получаем данные от объекта DirectInputDevice, представляющего мышь, с помощью функции GetDeviceData(). Если получены данные о перемещении мыши, происходит обновление переменных curx и cury. Если получены данные о нажатии кнопок, они заносятся в очередь событий.

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

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

Начнем с более простой функции UpdateCursorSimpleCase() (см. листинг 7.6).

Листинг 7.6. Функция UpdateCursorSimpleCase()

BOOL CursorWin::UpdateCursorSimpleCase(int curx, int cury, int oldcurx, int oldcury) {

 RECT src;

 HRESULT r;

 //------ Блиттинг 1: стирание старого курсора ----------

 r=primsurf->BltFast(oldcurx, oldcury, cursor_under, 0, DDBLTFAST_WAIT);

 if (r!=DD_OK) {

  TRACE("Blt 1 failed\n");

  CheckResult(r);

 }

 //------ Блиттинг 2: сохранение области под новым курсором ------

 src.left=curx;

 src.top=cury;

 src.right=curx+cursor_width;

 src.bottom=cury+cursor_height;

 r=cursor_under->BltFast(0, 0, primsurf, &src, DDBLTFAST_WAIT);

 if (r!=DD_OK) {

  TRACE("Blt 2 failed\n");

  CheckResult(r);

 }

 //------ Блиттинг 3: рисование нового курсора ----------

 r=primsurf->BltFast(curx, cury, cursor, 0, DDBLTFAST_SRCCOLORKEY | DDBLTFAST_WAIT);

 if (r!=DD_OK) {

  TRACE("Blt 3 failed\n");

  CheckResult(r);

 }

 return TRUE;

}

С помощью трех последовательных вызовов функции BltFast() интерфейса DirectDrawSurface, функция UpdateCursorSimpleCase() стирает существующий курсор, сохраняет область под новым курсором и рисует новый курсор.

В UpdateCursorComplexCase() функция BltFast() вызывается пять раз. Два дополнительных блиттинга предназначены для копирования обновляемой части первичной поверхности на вспомогательную поверхность (cursor_union) и обратно. Функция UpdateCursorComplexCase() приведена в листинге 7.7.

Листинг 7.7. Функция UpdateCursorComplexCase()

BOOL CursorWin::UpdateCursorComplexCase(int curx, int cury, int oldcurx, int oldcury) {

 RECT src;

 HRESULT r;

 int unionx=min(curx, oldcurx);

 int uniony=min(cury, oldcury);

 int unionw=max(curx, oldcurx)-unionx+cursor_width;

 int unionh=max(cury, oldcury)-uniony+cursor_height;

 //----- Блиттинг 1: копирование объединяющего прямоугольника

 // во вспомогательный буфер --------

 src.left=unionx;

 src.top=uniony;

 src.right=unionx+unionw;

 src.bottom=uniony+unionh;

 r=cursor_union->BltFast(0, 0, primsurf, &src, DDBLTFAST_WAIT);

 if (r!=DD_OK) {

  TRACE("Blt 1 failed\n");

  CheckResult(r);

 }

 //------ Блиттинг 2: стирание старого курсора

 // во вспомогательном буфере ---------

 r=cursor_union->BltFast(oldcurx-unionx, oldcury-uniony, cursor_under, 0, DDBLTFAST_WAIT);

 if (r!=DD_OK) {

  TRACE("Blt 2 failed\n");

  CheckResult(r);

 }

 //------ Блиттинг 3: сохранение области под новым курсором -----

 src.left=curx-unionx;

 src.top=cury-uniony;

 src.right=src.left+cursor_width;

 src.bottom=src.top+cursor_height;

 r=cursor_under->BltFast(0, 0, cursor_union, &src, DDBLTFAST_WAIT);

 if (r!=DD_OK) {

  TRACE("Blt 3 failed\n");

  CheckResult(r);

 }

 //------ Блиттинг 4: рисование нового курсора

 // во вспомогательном буфере ---------

 r=cursor_union->BltFast(curx-unionx, cury-uniony, cursor, 0, DDBLTFAST_SRCCOLORKEY | DDBLTFAST_WAIT);

 if (r!=DD_OK) {

  TRACE("Blt 4 failed\n");

  CheckResult(r);

 }

 //------- Блиттинг 5: копирование вспомогательного буфера

 // на первичную поверхность --------

 src.left=0;

 src.top=0;

 src.right=unionw;

 src.bottom=unionh;

 r=primsurf->BltFast(unionx, uniony, cursor_union, &src, DDBLTFAST_WAIT);

 if (r!=DD_OK) {

  TRACE("Blt 5 failed\n");

  CheckResult(r);

 }

 return TRUE;

}

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

Завершение приложения 

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

void CursorWin::OnDestroy() {

 critsection.Lock();

 DirectDrawWin::OnDestroy();

 if (mouse) {

  TRACE("mouse->Unacquire()\n");

  mouse->Unacquire();

  TRACE("sending mouse quit message...\n");

  mouse_event[quit_event_index]->SetEvent();

  Sleep(100);

  // дать потоку мыши возможность ответить

  TRACE("Releasing mouse pointer...\n");

  mouse->Release(), mouse=0;

  delete mouse_event[mouse_event_index];

  delete mouse_event[quit_event_index];

 }

 if (keyboard) keyboard->Release(), keyboard=0;

 if (dinput) dinput->Release(), dinput=0;

 critsection.Unlock();

}

Когда MFC вызывает функцию OnDestroy(), основной поток заведомо не обновляет экран, потому что он занят выполнением этой функции. Тем не менее мы не знаем, не обновляется ли экран потоком ввода. Чтобы поток ввода закончил последнее обновление, мы блокируем критическую секцию.

Далее мы уступаем мышь. Устройство перестает генерировать новые события, которые заставили бы поток ввода попытаться снова обновить экран. Затем функция CEvent::SetEvent() посылает потоку ввода сигнал о завершении.

Нам осталось лишь освободить объекты DirectInput. Но перед тем, как это делать, мы вызываем функцию Sleep(), чтобы ненадолго приостановить основной поток. Поток ввода получает возможность обработать событие и завершиться. Наконец, мы освобождаем критическую секцию, и функция завершается — на этом работа приложения заканчивается.

Заключение 

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

Глава 8. Воспроизведение видеороликов

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

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

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

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

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

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

AVI-файлы

Формат AVI (Audio Video Interleave) был разработан Microsoft для хранения и воспроизведения видеороликов. AVI-файл кроме последовательности растров содержит одну или несколько звуковых дорожек, сопровождающих видеоролик. В этой главе нам придется часто пользоваться AVI-файлами.

Почему для хранения видеоинформации нужен специальный файловый формат? Почему нельзя представить видеоролик в виде последовательности растров и звукового файла? Существует несколько причин, но, видимо, самая важная из них — сжатие. Если кадры видеоролика будут храниться без сжатия (например, в BMP-файлах), то даже относительно короткий ролик будет занимать слишком много места. Например, 1-минутный ролик при разрешении 320×200 и частоте вывода 30 кадров в секунду займет на диске свыше 100 Мбайт.

Разумеется, для практического применения видеороликов необходимо сжатие. Возникает вопрос: какое именно? Существует много различных алгоритмов сжатия, каждый из которых обладает своими достоинствами и недостатками. Маловероятно, чтобы один алгоритм подошел сразу по всем критериям.

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

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

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

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

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

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

Video For Windows

Для создания и чтения AVI-файлов Windows предоставляет разработчикам Video For Windows (VFW) API. Этот API заметно упрощает задачу воспроизведения видео, поскольку в нем имеются удобные средства для поиска и извлечения кадров из ролика.

VFW не пытается поддерживать все возможные алгоритмы сжатия, используемые для хранения AVI-данных. Вместо этого VFW допускает установку и удаление компрессоров и декомпрессоров, обеспечивающих работу одного или нескольких алгоритмов сжатия. Таким образом, VFW позволяет выбрать нужные компрессор и декомпрессор в зависимости от потребностей разработчика. Кроме поддержки сжатия и распаковки VFW API предоставляет средства для поиска и извлечения кадров, а также для решения других задач, связанных с потоками.

VFW API

Имена многих функций VFW API начинаются с букв AVI. Другие функции (например, относящиеся к сжатию) начинаются с IC. Существуют некоторые исключения, но большинство функций VFW снабжается одним из этих префиксов. Алфавитный список всех функций VFW приведен в табл. 8.1.

Таблица 8.1. Функции VFW

AVIBuildFilter()

AVICLearClipboard()

AVIFileAddRef()

AVIFileCreateStream()

AVIFileEndRecord()

AVIFileExit()

AVIFileGetStream()

AVIFileInfo()

AVIFileInit()

AVIFileOpen()

AVIFileReadData()

AVIFileRelease()

AVIFileWriteData()

AVIGetFromClipboard()

AVIMakeCompressedStream()

AVIMakeFileFromStream()

AVIMakeStreamFromClipboard()

AVIPutFileOnClipboard()

AVISave()

AVISaveOptions()

AVISaveOptionsFree()

AVISaveV()

AVIStreamAddRef()

AVIStreamBeginStreaming()

AVIStreamCreate()

AVIStreamEndStreaming()

AVIStreamCreate()

AVIStreamEndStreaming()

AVIStreamFindSample()

AVIStreamGetFrame()

AVIStreamGetFrameClose()

AVIStreamGetFrameOpen()

AVIStreamInfo()

AVIStreamLength()

AVIStreamOpenFromFile()

AVIStreamRead()

AVIStreamReadData()

AVIStreamReadFormat()

AVIStreamRelease()

AVIStreamSampleToTime()

AVIStreamSetFormat()

AVIStreamStart()

AVIStreamTimeToSample()

AVIStreamWrite()

AVIStreamWriteData()

CreateEditableStream()

EditStreamClone()

EditStreamCopy()

EditStreamCut()

EditStreamPaste()

EditStreamSetInfo()

EditStreamSetName()

ICClose()

ICCompress()

ICCompressorChoose()

ICCompressorFree()

ICDecompress()

ICDecompressEx()

ICDecompressExBegin()

ICDecompressExQuery()

ICDraw()

ICDrawBegin()

ICDrawSuggestFormat()

ICGetInfo()

ICGetDisplayFormat()

ICImageCompress()

ICImageDecompress()

ICInfo()

ICInstall()

ICLocate()

ICOpen()

ICOpenFunction()

ICRemove()

ICSendMessage()

ICSeqCompressFrame()

ICCompressFrameEnd()

ICCompressFrameStart()

ICGetStatusProc()

MyStatusProc()

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

СОВЕТ

Не забудьте включить VFW в проект

Перед тем как пользоваться функциями Video For Windows, необходимо включить в проект заголовочный файл vfw.h и добавить vfw32.lib в список файлов компоновщика.

Для правильной работы функций из табл. 8.1 необходимо инициализировать VFW функцией AVIFileInit(). Эта функция не получает аргументов и не возвращает никакого значения, поэтому работать с ней проще простого.

После инициализации VFW можно создавать поток функцией AVIStreamOpenFromFile(). Эта функция получает в одном из аргументов имя AVI-файла и инициализирует по нему логический номер потока. Полученный логический номер затем используется как аргумент большинства функций VFW и определяет поток, с которым выполняется операция.

В частности, по логическому номеру, возвращаемому AVIStreamOpenFromFile(), можно получить сведения о видеоролике. Функция AVIStreamReadFormat() сообщает такие данные, как количество кадров, размер изображения и глубина пикселей; для этого она заполняет структуру BITMAPINFOHEADER (возможно, структура BITMAPINFOHEADER покажется вам знакомой — мы уже встречались с ней при описании BMP-файлов). Я снова приведу определение этой структуры, взятое из файла Windows wingdi.h:

typedef struct tagBITMAPINFOHEADER {

 DWORD biSize;

 LONG  biWidth;

 LONG  biHeight;

 WORD  biPlanes;

 WORD  biBitCount;

 DWORD biCompression;

 DWORD biSizeImage;

 LONG  biXPelsPerMeter;

 LONG  biYPelsPerMeter;

 DWORD biClrUsed;

 DWORD biClrImportant;

} BITMAPINFOHEADER, FAR *LPBITMAPINFOHEADER, *PBITMAPINFOHEADER;

Некоторые поля структуры (например, biXPelsPerMeter и biYPelsPerMeter) не имеют отношения к AVI-файлам, но таких полей немного. Размеры, глубина пикселей, алгоритм сжатия и количество цветов — все это можно взять из структуры BITMAPINFOHEADER после успешного вызова функции AVIStreamReadFormat().

Более подробные сведения о потоке можно получить с помощью функции AVIStreamInfo(). Функция AVIStreamInfo(), как и функция AVIStreamReadFormat(), получает в качестве аргумента логический номер и заполняет структуру данными о потоке. Для передачи информации AVIStreamInfo() использует структуру AVISTREAMINFO. Ее определение в файле vfw.h выглядит так:

typedef struct _AVISTREAMINFOW {

 DWORD fccType;

 DWORD fccHandler;

 DWORD dwFlags;

 DWORD dwCaps;

 WORD  wPriority;

 WORD  wLanguage;

 DWORD dwScale;

 DWORD dwRate;

 DWORD dwStart;

 DWORD dwLength;

 DWORD dwInitialFrames;

 DWORD dwSuggestedBufferSize;

 DWORD dwQuality;

 DWORD dwSampleSize;

 RECT  rcFrame;

 DWORD dwEditCount;

 DWORD dwFormatChangeCount;

 WCHAR szName[64];

} AVISTREAMINFOW, FAR * LPAVISTREAMINFOW;

Давайте рассмотрим некоторые ключевые поля этой структуры. Первое поле, fccType, определяет тип потока. В файлах формата AVI поддерживаются четыре типа потоковых данных: видео, аудио, MIDI (музыка) и текст. В этой книге будут рассматриваться только видеопотоки.

Второе поле структуры AVISTREAMINFO, fccHandler, определяет алгоритм сжатия, примененный при сохранении видеопотока. Как вы вскоре увидите, в Video For Windows это поле можно использовать для создания «декомпрессоров», которые способны восстановить каждый сжатый кадр из потока.

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

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

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

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

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

Программа AviPlay

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

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

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

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

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

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

Класс AviPlayWin 

Большинство возможностей программы AviPlay обеспечивается классом AviPlayWin, который наследует поддержку DirectDraw от класса DirectDrawWin. В отличие от других программ этой книги класс AviPlayWin использует диалоговое окно для выбора файла. Вместо того чтобы создавать поверхности при запуске, программа AviPlay (как и программа BmpView из главы 5) ожидает, пока пользователь выберет файл. Затем программа создает поверхности и настраивает их в соответствии с содержимым выбранного файла. Определение класса AviPlayWin приведено в листинге 8.1.

Листинг 8.1. Класс AviPlayWin

class AviPlayWin : public DirectDrawWin {

public:

 AviPlayWin();

protected:

 //{{AFX_MSG(AviPlayWin)

 afx_msg void OnKeyDown(UINT nChar, UINT nRepCnt, UINT nFlags);

 afx_msg void OnRButtonDown(UINT nFlags, CPoint point);

 afx_msg int OnCreate(LPCREATESTRUCT lpCreateStruct);

 afx_msg void OnDestroy();

 //}}AFX_MSG

 DECLARE_MESSAGE_MAP()

private:

 int SelectInitialDisplayMode();

 BOOL CreateCustomSurfaces() {

  return TRUE;

 }

 void DrawScene();

 void RestoreSurfaces();

 void GetSystemPalette();

 void ShowDialog();

 BOOL LoadAvi();

 BOOL CreateAviSurface();

 BOOL UpdateAviSurface();

 BOOL InstallPalette();

private:

 AviDialog* avidialog;

 CString fullfilename;

 CString filename;

 CString pathname;

 CRect displayrect;

 LPDIRECTDRAWSURFACE avisurf;

 CRect avirect;

 int x,y;

 DisplayModeArray displaymode;

 LPDIRECTDRAWPALETTE syspal;

 LPDIRECTDRAWPALETTE avipal;

 PAVISTREAM avistream;

 AVISTREAMINFO streaminfo;

 HIC decomp;

 long fmtlen, buflen;

 long startframe, endframe;

 long curframe;

 LPBITMAPINFOHEADER srcfmt;

 LPBITMAPINFOHEADER dstfmt;

 BYTE* rawdata;

 BYTE* finaldata;

};

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

В классе определены четыре обработчика сообщений: OnKeyDown(), OnRButtonDown(), OnCreate() и OnDestroy(). Функция OnKeyDown() следит за нажатием клавиш Escape и пробела во время воспроизведения, прерывает ролик и отображает диалоговое окно для выбора AVI-файла (мы могли воспользоваться DirectInput, но программа AviPlay не стоит подобных хлопот). Функция OnRButtonDown() тоже вызывает диалоговое окно для выбора AVI-файла, но по щелчку правой кнопки мыши. Функция OnCreate() инициализирует DirectDraw и AVI, а функция OnDestroy() завершает их работу.

Затем мы объявляем 10 закрытых (private) функций. Первой идет функция SelectInitialDisplayMode(), которая выполняет три задачи: выбор исходного видеорежима (то, для чего предназначена сама функция), построение списка 8-битных режимов для диалогового окна и захват системной палитры. Вскоре мы рассмотрим эту функцию. Функция GetSystemPalette() вызывается функцией SelectInitialDisplayMode(); мы увидим, как она работает, при знакомстве с последней.

Функция CreateCustomSurfaces() объявлена встроенной (inline). Она всего лишь возвращает TRUE, потому что при запуске приложения поверхности не создаются.

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

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

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

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

Последней объявлена функция InstallPalette(), которая устанавливает палитру AVI перед началом воспроизведения ролика. Однако перед этим она должна извлечь данные палитры из потока AVI.

Оставшаяся часть класса содержит лишь переменные. Мы познакомимся с ними во время рассмотрения программы.

Функция OnCreate() 

Мы будем рассматривать функции примерно в порядке их выполнения. Начнем с функции OnCreate(), которая выглядит так:

int AviPlayWin::OnCreate(LPCREATESTRUCT lpCreateStruct) {

 if (DirectDrawWin::OnCreate(lpCreateStruct) == -1) return -1;

 AVIFileInit();

 ShowDialog();

 return 0;

}

Сначала мы вызываем версию OnCreate() базового класса (а она инициализирует DirectDraw). Если вызов этой функции закончится неудачей, продолжать бессмысленно, и мы возвращаем код неудачного завершения –1.

Затем мы вызываем функцию AVIFileInit(), которая инициализирует Video For Windows. После этого можно спокойно пользоваться функциями VFW.

Наконец, функция ShowDialog() выводит диалоговое окно для выбора AVI-файла и ожидает ввод от пользователя. Однако перед тем, как обсуждать ShowDialog(), необходимо рассмотреть функцию SelectInitialDisplayMode(), которая вызывается при использовании функции OnCreate() класса DirectDrawWin.

Функция SelectInitialDisplayMode() 

Как упоминалось выше, функция SelectInitialDisplayMode() решает три задачи. Она выглядит так:

int AviPlayWin::SelectInitialDisplayMode() {

 GetSystemPalette();

 int i, nummodes=GetNumDisplayModes();

 DWORD w,h,d;

 for (i=0;i<nummodes;i++) {

  DisplayModeDescription desc;

  GetDisplayModeDimensions(i, w, h, d);

  if (d==8) {

   desc.w=w;

   desc.h=h;

   desc.d=d;

   desc.desc.Format("%dx%d", w, h);

   displaymode.Add(desc);

  }

 }

 int curdepth=GetDisplayDepth();

 if (curdepth!=8) ddraw2->SetDisplayMode(640, 480, curdepth, 0, 0);

 for (i=0;i<nummodes;i++) {

  GetDisplayModeDimensions(i, w, h, d);

  if (w==640 && h==480 && d==8) return i;

 }

 return 1;

}

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

Затем функция SelectInitialDisplayMode() перебирает список доступных видеорежимов и сохраняет описания 8-битных режимов в массиве displaymodes. Позднее этот массив передается диалоговому окну для вывода списка доступных видеорежимов.

Наконец, функция ищет 8-битный режим с разрешением 640x480. Этот режим выбран лишь потому, что он поддерживается абсолютным большинством видеокарт (если не всеми). После вывода диалогового окна пользователь сможет выбрать любой другой 8-битный режим.

Функция ShowDialog() 

Давайте рассмотрим функцию для вывода диалогового окна. Функция ShowDialog() приведена в листинге 8.2.

Листинг 8.2. Функция ShowDialog()

void AviPlayWin::ShowDialog() {

 const CRect& displayrect=GetDisplayRect();

 if (displayrect.Width()<640 || displayrect.Height()>480) ddraw2->SetDisplayMode(640, 480, 8, 0, 0);

 ClearSurface(backsurf, 0);

 ClearSurface(primsurf, 0);

 primsurf->SetPalette(syspal);

 ddraw2->FlipToGDISurface();

 ShowCursor(TRUE);

 if (avidialog==0) {

  avidialog=new AviDialog();

  avidialog->SetArray(&displaymode);

 }

 if (avistream)  AVIStreamRelease(avistream), avistream=0;

 if (avidialog->DoModal()==IDCANCEL) {

  PostMessage(WM_CLOSE);

  return;

 }

 ShowCursor(FALSE);

 fullfilename=avidialog->fullfilename;

 filename=avidialog->filename;

 pathname=avidialog->pathname;

 int index=avidialog->GetIndex();

 DWORD w,h,d;

 w=displaymode[index].w;

 h=displaymode[index].h;

 d=displaymode[index].d;

 ActivateDisplayMode(GetDisplayModeIndex(w, h, d));

 LoadAvi();

 CreateAviSurface();

 InstallPalette();

 curframe=startframe;

}

Функция ShowDialog() начинается с проверки текущего разрешения. Если в данный момент установлен видеорежим с разрешением меньше 640x480, он изменяется. Это сделано для того, чтобы диалоговое окно не выводилось в режиме Mode X. Поскольку этот режим не поддерживается Windows, такая попытка, скорее всего, закончится неудачей из-за нелинейной организации пикселей в режимах Mode X.

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

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

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

Если экземпляр класса AviDialog не был создан при предыдущем вызове функции ShowDialog(), мы создаем его. Обратите внимание на то, что при создании диалогового окна ему передается массив 8-битных видеорежимов, подготовленный в функции SelectInitialDisplayMode().

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

Функция DoModal() отображает диалоговое окно, в котором пользователь может выбрать нужный файл. При нажатии кнопки Cancel мы посылаем сообщение WM_CLOSE. Если все идет нормально, мы получаем имя выбранного файла (в трех различных формах) вместе с индексом видеорежима (видеорежим необходимо выбрать до нажатия кнопки Play). Размеры выбранного видеорежима, взятые из массива displaymode, передаются функции SetDisplayMode().

Дальше следует вызов функции LoadAvi(). Как вы вскоре убедитесь, функция LoadAvi() на самом деле не загружает видеоролик — она лишь открывает файл и извлекает сведения о ролике (например, количество кадров и их размеры). Функция CreateAviSurface() по полученным размерам создает поверхность для хранения одного кадра видеопотока.

Функция InstallPalette() извлекает данные палитры из AVI-файла и строит по ним палитру DirectDraw, которая лучше всего подходит для просмотра. Наконец, переменной curframe, предназначенной для перебора кадров, присваивается значение переменной startframe.

Функция LoadAvi() 

Перейдем к функции, которая непосредственно открывает AVI-файл. Функция LoadAvi() приведена в листинге 8.3.

Листинг 8.3. Функция LoadAvi()

BOOL AviPlayWin::LoadAvi() {

 long r;

 CWaitCursor cur;

 if (avistream) AVIStreamRelease(avistream), avistream=0;

 r=AVIStreamOpenFromFile(&avistream, filename, streamtypeVIDEO, 0, OF_READ | OF_SHARE_EXCLUSIVE, 0);

 TRACE("AVIStreamOpenFromFile: %s\n", r==0 ? "OK" : "failed");

 r=AVIStreamFormatSize(avistream, 0, &fmtlen);

 TRACE("AVIStreamFormatSize: %s\n", r==0 ? "OK" : "failed");

 int formatsize=fmtlen+sizeof(RGBQUAD)*256;

 if (srcfmt)   delete [] srcfmt;

 srcfmt = (LPBITMAPINFOHEADER)new BYTE[formatsize];

 ZeroMemory(srcfmt, formatsize);

 if (dstfmt)   delete [] dstfmt;

 dstfmt = (LPBITMAPINFOHEADER)new BYTE[formatsize];

 ZeroMemory(dstfmt, formatsize);

 r=AVIStreamReadFormat(avistream, 0, srcfmt, &fmtlen);

 TRACE("AVIStreamReadFormat: %s\n", r==0 ? "OK" : "failed");

 TRACE(" --- %s ---\n", filename);

 TRACE(" biSize: %d\n", srcfmt->biSize);

 TRACE(" biWidth x biHeight: %dx%d\n", srcfmt->biWidth, srcfmt->biHeight);

 if (srcfmt->biPlanes != 1) TRACE(" - biPlanes: %d\n", srcfmt->biPlanes);

 TRACE(" biBitCount: %d\n", srcfmt->biBitCount);

 CString comp;

 switch (srcfmt->biCompression) {

 case BI_RGB:

  comp="BI_RGB";

  break;

 case BI_RLE8:

  comp="BI_RLE8";

  break;

 case BI_RLE4:

  comp="BI_RLE4";

  break;

 case BI_BITFIELDS:

  comp="BI_BITFIELDS";

  break;

 }

 TRACE(" biCompression: %s\n", comp);

 TRACE(" biSizeImage: %d\n", srcfmt->biSizeImage);

 TRACE(" ------------------\n");

 memcpy(dstfmt, srcfmt, fmtlen);

 dstfmt->biBitCount = 8;

 dtfmt->biCompression = BI_RGB;

 dstfmt->biSizeImage = dstfmt->biWidth * dstfmt->biHeight;

 startframe = AVIStreamStart(avistream);

 TRACE("stream start: %d\n", startframe);

 endframe = AVIStreamEnd(avistream);

 TRACE("stream end: %d\n", endframe);

 r=AVIStreamInfo(avistream, &streaminfo, sizeof(streaminfo));

 TRACE("AVIStreamInfo: %s\n", r==0 ? "OK" : "failed" );

 buflen = dstfmt->biSizeImage;

 int finalbuflen=((dstfmt->biWidth+3) & ~3) * dstfmt->biHeight;

 if (streaminfo.dwSuggestedBufferSize) if ((LONG)streaminfo.dwSuggestedBufferSize < buflen) {

  TRACE("adjusting buflen to suggested size\n");

  buflen = (LONG)streaminfo.dwSuggestedBufferSize;

 }

 if (decomp) ICClose(decomp);

 decomp = ICDecompressOpen(ICTYPE_VIDEO, streaminfo.fccHandler, srcfmt, dstfmt);

 TRACE("ICDecompressOpen: %s\n", decomp ? "OK" : "failed");

 if (rawdata) {

  TRACE("delete [] rawdata...\n");

  delete [] rawdata;

 }

 rawdata = new BYTE[buflen];

 if (finaldata) {

  TRACE("delete [] finaldata...\n");

  delete [] finaldata;

 }

 finaldata = new BYTE[finalbuflen];

 return TRUE;

}

В функции LoadAvi() используются функции VFW. Сначала LoadAvi() закрывает открытый ранее AVI-поток функцией AVIStreamRelease(), а затем открывает новый поток функцией AVIStreamOpenFromFile(), которой в числе прочих аргументов передается имя открываемого AVI-файла.

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

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

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

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

Функция CreateAviSurface() 

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

BOOL AviPlayWin::CreateAviSurface() {

 if (avisurf) avisurf->Release(), avisurf=0;

 avisurf=CreateSurface(srcfmt->biWidth, srcfmt->biHeight);

 CRect displayrect=GetDisplayRect();

 x=(displayrect.Width()-srcfmt->biWidth)/2;

 y=0;

 return TRUE;

}

После освобождения поверхности, созданной ранее, функция CreateAviSurface() с помощью функции CreateSurface() интерфейса DirectDraw создает поверхность, размеры которой совпадают с размерами кадра. Кроме того, функция CreateAviSurface() инициализирует переменные x и y, определяющие положение поверхности AVI на вторичном буфере. В нашем случае кадры будут выравниваться по центру экрана, поэтому в вычислениях применяется функция DirectDrawWin::GetDisplayRect() для определения размеров экрана.

Функция InstallPalette() 

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

BOOL AviPlayWin::InstallPalette() {

 ICDecompressGetPalette(decomp, srcfmt, dstfmt);

 PALETTEENTRY pe[256];

 LPBITMAPINFO info=(LPBITMAPINFO)dstfmt;

 for (int i=0; i<256; i++) {

  pe[i].peRed = info->bmiColors[i].rgbRed;

  pe[i].peGreen = info->bmiColors[i].rgbGreen;

  pe[i].peBlue = info->bmiColors[i].rgbBlue;

  pe[i].peFlags = 0;

 }

 if (avipal) avipal->Release();

 ddraw2->CreatePalette(DDPCAPS_8BIT, pe, &avipal, 0);

 primsurf->SetPalette(avipal);

 return TRUE;

}

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

Функция DrawScene() 

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

void AviPlayWin::DrawScene() {

 long r;

 r=AVIStreamRead(avistream, curframe, 1, rawdata, buflen, 0, 0);

 if (r) {

  TRACE("AVIStreamRead failed: ");

  switch (r)  {

  case AVIERR_BUFFERTOOSMALL:

   TRACE("BUFFERTOOSMALL\n");

   break;

  case AVIERR_MEMORY:

   TRACE("MEMORY\n");

   break;

  case AVIERR_FILEREAD:

   TRACE("FILEREAD\n");

   break;

  }

 }

 r=ICDecompress(decomp, 0, srcfmt, rawdata, dstfmt, finaldata);

 UpdateAviSurface();

 backsurf->BltFast(x, y, avisurf, 0, DDBLTFAST_WAIT);

 curframe=(curframe<endframe) ? curframe+1 : startframe;

 primsurf->Flip(0, DDFLIP_WAIT);

}

Функция DrawScene() с помощью функции AVIStreamRead() извлекает очередной кадр из AVI-потока, после чего сохраняет полученные данные в буфере rawdata. Я оставил в ней несколько макросов TRACE(), которые пригодились мне при отладке, но надеюсь, что вам они не понадобятся.

Затем мы вызываем функцию ICDecompress() и передаем ей логический номер декомпрессора, ранее полученный от функции LoadAvi(). Аргументами функции ICDecompress() являются два буфера — первый содержит необработанные (сжатые) данные, а второй — восстановленное изображение.

Функция UpdateAviSurface() копирует восстановленный кадр на поверхность AVI. Эта функция рассматривается ниже.

Подготовленная поверхность AVI копируется во вторичный буфер функцией BltFast() интерфейса DirectDrawSurface. После этого переменная curframe увеличивается или сбрасывается в зависимости от ее значения и количества кадров в ролике. Наконец, функция Flip() интерфейса DirectDrawSurface выводит кадр на экран.

Функция UpdateAviSurface()

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

BOOL AviPlayWin::UpdateAviSurface() {

 HRESULT r;

 if (finaldata==0) return FALSE;

 DWORD dwWidth = (srcfmt->biWidth+3) & ~3;

 DWORD dwHeight = srcfmt->biHeight;

 DDSURFACEDESC desc;

 ZeroMemory(&desc, sizeof(desc));

 desc.dwSize = sizeof(desc);

 r = avisurf->Lock(0, &desc, DDLOCK_WAIT, 0);

 if (r==DD_OK) {

  BYTE* src = finaldata + dwWidth * (dwHeight-1);

  BYTE* dst = (BYTE *)desc.lpSurface;

  for (DWORD y=0; y<dwHeight; y++) {

   memcpy(dst, src, dwWidth);

   dst += desc.lPitch;

   src -= dwWidth;

  }

  avisurf->Unlock(0);

 }

 return TRUE;

}

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

Функция RestoreSurfaces() 

Все трудное осталось позади, дальше будет легко. Особенно просто реализуется функция RestoreSurfaces():

void AviPlayWin::RestoreSurfaces() {

 avisurf->Restore();

}

Вспомните — функция RestoreSurfaces() вызывается только при восстановлении потерянных поверхностей, а класс DirectDrawWin автоматически восстанавливает первичную поверхность со вторичным буфером. В программе AviPlay остается лишь восстановить поверхность AVI, а для этого достаточно вызвать функцию Restore() интерфейса DirectDrawSurface.

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

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

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

void AviPlayWin::OnKeyDown(UINT key, UINT nRepCnt, UINT nFlags) {

 switch (key) {

 case VK_ESCAPE:

 case VK_SPACE:

 case VK_RETURN:

  ShowDialog();

  break;

 }

 DirectDrawWin::OnKeyDown(key, nRepCnt, nFlags);

}

Все три клавиши вызывают функцию ShowDialog(). Аналогично обрабатывается и ввод от мыши, это происходит в функции OnRButtonDown():

void AviPlayWin::OnRButtonDown(UINT nFlags, CPoint point) {

 ShowDialog();

 DirectDrawWin::OnRButtonDown(nFlags, point);

}

Когда пользователь закрывает диалоговое окно для выбора AVI-файла, функция ShowDialog() посылает сообщение WM_CLOSE, сигнализируя о завершении приложения.

Функция OnDestroy() 

Остается лишь завершить приложение. Функция OnDestroy() занимается «уборкой мусора» — она закрывает открытые AVI-потоки, освобождает декомпрессор и буферы данных AVI:

void AviPlayWin::OnDestroy() {

 DirectDrawWin::OnDestroy();

 if (avistream) AVIStreamRelease(avistream), avistream=0;

 if (decomp)  ICClose(decomp), decomp=0;

 if (srcfmt) delete [] srcfmt, srcfmt=0;

 if (dstfmt) delete [] dstfmt, dstfmt=0;

 if (rawdata) {

  TRACE("delete [] rawdata...\n");

  delete [] rawdata, rawdata=0;

 }

 if (finaldata) {

  TRACE("delete [] finaldata...\n");

  delete [] finaldata, finaldata=0;

 }

 if (avidialog) delete avidialog, avidialog=0;

 AVIFileExit();

}

Обратите внимание на вызов функции AviFileExit() в конце OnDestroy(). Это завершает работу VFW и освобождает все используемые им ресурсы.

Заключение 

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

И последнее замечание. По неизвестным мне причинам VFW отказывается работать с AVI-файлами, сжатыми кодеками IR32 и IR42 (возможно, есть и другие, но я заметил эти два). С другой стороны, AVI-файлы, использующие кодеки MS-CRAM и Cinepak, работают нормально.

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

Глава 9. Проверка столкновений               

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Функции проверки столкновений

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

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

for (int i=0;i<nsprites;i++) for (int j=0;j>nsprites;j++) if (SpritesCollide(sprite[i], sprite[j])) {

 sprite[i]->Hit(sprite[j]);

 sprite[j]->Hit(sprite[i]);

}

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

for (int i=0;i<nsprites;i++) for (int j=i+1;j>nsprites;j++) if (SpritesCollide(sprite[i], sprite[j])) {

 sprite[i]->Hit(sprite[j]);

 sprite[j]->Hit(sprite[i]);

}

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

Теперь давайте рассмотрим функцию SpritesCollide(). Как видно из кода, аргументами этой функции являются два спрайта. Функция SpritesCollide() возвращает TRUE, если спрайты сталкиваются, и FALSE в противном случае.

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

BOOL SpritesCollide(Sprite* sprite1, Sprite* sprite2) {

 ASSERT(sprite1 && sprite2);

 if (SpritesCollideRect(sprite1, sprite2)) if (SpritesCollidePixel(sprite1, sprite2)) return TRUE;

 return FALSE;

}

Обратите внимание на то, что функция SpritesCollide() должна получать два аргумента — два указателя на объекты Sprite (класс Sprite рассматривается ниже). Сначала функция проверяет, что оба указателя отличны от нуля, с помощью макроса ASSERT().

СОВЕТ

ASSERT() в DirectDraw

Хотя в библиотеку MFC входит макрос ASSERT(), он плохо подходит для полноэкранных приложений DirectDraw. В приложении А описана нестандартная версия ASSERT(), использованная в программах этой книги.

Затем функция SpritesCollide() проверяет, пересекаются ли ограничивающие прямоугольники двух спрайтов. Эта проверка выполняется функцией SpritesCollideRect(), которая, как и SpritesCollide(), получает два указателя на объекты Sprite и возвращает логическое значение. Если прямоугольники не пересекаются (то есть SpritesCollideRect() возвращает FALSE), дальнейшая проверка не нужна, и функция возвращает FALSE — это означает, что два спрайта не сталкиваются.

Если ограничивающие прямоугольники пересекаются, необходимо продолжить проверку. Мы вызываем функцию SpritesCollidePixel() и также передаем ей два указателя на объекты Sprite. Если эта проверка окажется неудачной, SpritesCollide() возвращает FALSE; в противном случае она возвращает TRUE, что говорит о столкновении спрайтов.

Перед тем как рассматривать процедуру проверки на уровне пикселей, давайте рассмотрим функцию SpritesCollideRect(), в которой проверяется пересечение ограничивающих прямоугольников:

BOOL SpritesCollideRect(Sprite* sprite1, Sprite* sprite2) {

 CRect rect1 = sprite1->GetRect();

 CRect rect2 = sprite2->GetRect();

 CRect r = rect1 & rect2;

 // Если все поля равны нулю, прямоугольники не пересекаются

 return !(r.left==0 && r.top==0 && r.right==0 && r.bottom==0);

}

Пересечение ограничивающих прямоугольников проверяется в функции SpritesCollideRect() с помощью класса MFC CRect. Сначала для каждого спрайта вызывается функция Sprite::GetRect(). Она возвращает объект CRect, определяющий текущее положение и размеры каждого спрайта. Затем третий объект CRect инициализируется оператором пересечения класса CRect (& ), который вычисляет область пересечения двух своих операндов. Если пересечения не существует (два прямоугольника не перекрываются), все четыре поля CRect обнуляются. Этот признак используется для возврата TRUE в случае пересечения прямоугольников, и FALSE — в противном случае.

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

Листинг 9.1. Функция SpritesCollidePixel()

BOOL SpritesCollidePixel(Sprite* sprite1, Sprite* sprite2) {

 CRect rect1=sprite1->GetRect();

 CRect rect2=sprite2->GetRect();

 CRect irect = rect1 & rect2;

 ASSERT(!(irect.left==0 && irect.top==0 &&   irect.right==0 && irect.bottom==0));

 CRect r1target = rect1 & irect;

 r1target.OffsetRect(-rect1.left, -rect1.top);

 r1target.right--;

 r1target.bottom--;

 CRect r2target = rect2 & irect;

 r2target.OffsetRect(-rect2.left, -rect2.top);

 r2target.right--;

 r2target.bottom--;

 int width=irect.Width();

 int height=irect.Height();

 DDSURFACEDESC desc1, desc2;

 ZeroMemory(&desc1, sizeof(desc1));

 ZeroMemory(&desc2, sizeof(desc2));

 desc1.dwSize = sizeof(desc1);

 desc2.dwSize = sizeof(desc2);

 BYTE* surfptr1; // Указывает на начало памяти поверхности

 BYTE* surfptr2;

 BYTE* pixel1; // Указывает на конкретные пиксели

 BYTE* pixel2; // в памяти поверхности

 BOOL ret=FALSE;

 LPDIRECTDRAWSURFACE surf1=sprite1->GetSurf();

 LPDIRECTDRAWSURFACE surf2=sprite2->GetSurf();

 if (surf1==surf2)  {

  surf1->Lock(0, &desc1, DDLOCK_WAIT, 0);

  surfptr1=(BYTE*)desc1.lpSurface;

  for (int yy=0;yy<height;yy++)  {

   for (int xx=0;xx>width;xx++)   {

    pixel1=surfptr1+(yy+r1target.top)*desc1.lPitch +(xx+r1target.left);

    pixel2=surfptr1+(yy+r2target.top)*desc1.lPitch +(xx+r2target.left);

    if (*pixel1 && *pixel2) {

     ret=TRUE;

     goto done_same_surf;

    }

   }

  }

done_same_surf:

  surf1->Unlock(surfptr1);

  return ret;

 }

 surf1->Lock(0, &desc1, DDLOCK_WAIT, 0);

 surfptr1=(BYTE*)desc1.lpSurface;

 surf2->Lock(0, &desc2, DDLOCK_WAIT, 0);

 surfptr2=(BYTE*)desc2.lpSurface;

 for (int yy=0;yy<height;yy++)  {

  for (int xx=0;xx>width;xx++)  {

   pixel1=surfptr1+(yy+r1target.top)*desc1.lPitch +(xx+r1target.left);

   pixel2=surfptr2+(yy+r2target.top)*desc2.lPitch +(xx+r2target.left);

   if (*pixel1 && *pixel2) {

    ret=TRUE;

    goto done;

   }

  }

 }

done:

 surf2->Unlock(surfptr2);

 surf1->Unlock(surfptr1);

 return ret;

}

Функция SpritesCollidePixel() состоит из четырех этапов. Она делает следующее:

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

2. Вычисляет области спрайтов, для которых потребуется проверка на уровне пикселей.

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

4. Снимает блокировку с обеих поверхностей и возвращает TRUE или FALSE.

На этапе 1 мы инициализируем два объекта CRect функцией Sprite::GetRect(). Функция GetRect() возвращает прямоугольник CRect, представляющий положение и размеры спрайта. Затем оператор & (оператор пересечения класса CRect) определяет область пересечения двух прямоугольников. Ниже снова приведен соответствующий фрагмент листинга 9.1:

CRect rect1=sprite1->GetRect();

CRect rect2=sprite2->GetRect();

CRect irect = rect1 & rect2;

ASSERT(!(irect.left==0 && irect.top==0 &&  irect.right==0 && irect.bottom==0));

Как мы узнали из функции SpritesCollideRect(), оператор пересечения класса CRect обнуляет все четыре поля CRect, если операнды не пересекаются. В этом случае функцию SpritesCollidePixel() вызывать не следует, поэтому о такой ситуации сообщает макрос ASSERT().

На этапе 2 мы вычисляем область каждого спрайта, для которой должна осуществляться проверка пикселей. Для этого снова используется оператор пересечения:

CRect r1target = rect1 & irect;

r1target.OffsetRect(-rect1.left, -rect1.top);

r1target.right--;

r1target.bottom--;

CRect r2target = rect2 & irect;

r2target.OffsetRect(-rect2.left, -rect2.top);

r2target.right--;

r2target.bottom--;

В прямоугольниках r1target и r2target хранятся области спрайтов, для которых потребуется проверка на уровне пикселей. После того как пересечение будет найдено, оба прямоугольника сдвигаются функцией CRect::OffsetRect() так, чтобы левый верхний угол имел координаты (0, 0). Это объясняется тем, что поля right и bottom объектов CRect будут использоваться для обращений к поверхностям обоих спрайтов, а это требует перехода к локальным системам координат этих поверхностей.

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

СОВЕТ

Кое-что о классе CRect

Класс MFC CRect реализован так, чтобы при вычитании поля left из поля right получалась ширина прямоугольника. Такой подход удобен, но смысл поля right несколько изменяется. Например, рассмотрим прямоугольник, у которого поле left равно 0, а полю right присвоено значение 4. В соответствии с реализацией класса CRect такой прямоугольник имеет ширину в 4 пикселя, но если использовать эти же значения для обращений к пикселям, ширина прямоугольника окажется равной 5 пикселям (поскольку в нее будут включены пиксели с номерами от 0 до 4). Такие же расхождения возникают и для полей top и bottom. Следовательно, чтобы использовать поля CRect для работы с пикселями, необходимо уменьшить на 1 значения полей right и bottom.

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

LPDIRECTDRAWSURFACE surf1=sprite1->GetSurf();

LPDIRECTDRAWSURFACE surf2=sprite2->GetSurf();

Если поверхности совпадают, проверка выполняется следующим фрагментом:

if (surf1==surf2) {

 surf1->Lock(0, &desc1, DDLOCK_WAIT, 0);

 surfptr1=(BYTE*)desc1.lpSurface;

 for (int yy=0;yy<height;yy++)  {

  for (int xx=0;xx>width;xx++)  {

   pixel1=surfptr1+(yy+r1target.top)*desc1.lPitch +(xx+r1target.left);

   pixel2=surfptr1+(yy+r2target.top)*desc1.lPitch +(xx+r2target.left);

   if (*pixel1 && *pixel2) {

    ret=TRUE;

    goto done_same_surf;

   }

  }

 }

done_same_surf:

 surf1->Unlock(surfptr1);

 return ret;

}

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

Если два спрайта находятся на разных поверхностях, проверка столкновений выполняется другим фрагментом функции SpritesCollidePixel(). Ниже снова приведен соответствующий фрагмент листинга 9.1:

surf1->Lock(0, &desc1, DDLOCK_WAIT, 0);

surfptr1=(BYTE*)desc1.lpSurface;

surf2->Lock(0, &desc2, DDLOCK_WAIT, 0);

surfptr2=(BYTE*)desc2.lpSurface;

for (int yy=0;yy<height;yy++) {

 for (int xx=0;xx>width;xx++) {

  pixel1=surfptr1+(yy+r1target.top)*desc1.lPitch +(xx+r1target.left);

  pixel2=surfptr2+(yy+r2target.top)*desc2.lPitch +(xx+r2target.left);

  if (*pixel1 && *pixel2) {

   ret=TRUE;

   goto done;

  }

 }

}

done:

surf2->Unlock(surfptr2);

surf1->Unlock(surfptr1);

return ret;

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

Класс Sprite 

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

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

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

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

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

Чтобы избежать подобных неприятностей, необходимо соблюдать два правила:

1. Положение спрайтов не должно изменяться до завершения цикла проверок.

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

Класс Sprite эти правила соблюдает и, следовательно, справляется со всеми проблемами. Для этого обработка каждого столкновения осуществляется за две стадии, которые мы назовем подтверждением (acknowledgment) и реакцией (reaction). На стадии подтверждения спрайт всего лишь сохраняет статус и положение другого спрайта — его собственное положение и статус остаются неизменными. Затем, на стадии реакции, по ранее сохраненным данным определяются дальнейшие действия, вызванные столкновением. На этой стадии положение и статус спрайта могут изменяться. Функция Hit() класса Sprite используется для подтверждения, а функция Update() — для реакции. Класс Sprite определяется так:

class Sprite {

public:

 Sprite(LPDIRECTDRAWSURFACE, int x, int y);

 LPDIRECTDRAWSURFACE GetSurf() {

  return surf;

 }

 operator LPDIRECTDRAWSURFACE() const {

  return surf;

 }

 int GetX() {

  return x;

 }

 int GetY() {

  return y;

 }

 int GetCenterX() {

  return x+w/2;

 }

 int GetCenterY() {

  return y+h/2;

 }

 void SetXY(int xx, int yy) {

  x=xx;

  y=yy;

 }

 void SetXYrel(int xx,int yy) {

  x+=xx;

  y+=yy;

 }

 CRect GetRect();

 virtual void Update();

 void Hit(Sprite*);

 void CalcVector();

private:

 LPDIRECTDRAWSURFACE surf;

 int x, y;

 int w, h;

 int xinc, yinc;

 BOOL collide;

 struct CollideInfo {

  int x, y;

 } collideinfo;

};

Конструктор класса Sprite получает три аргумента: указатель на поверхность DirectDraw, изображающую новый спрайт, и два целых числа, определяющих начальное положение спрайта. Так как конструктору передается поверхность DirectDraw, одна и та же поверхность может использоваться для нескольких спрайтов. Конструктор можно было бы написать так, чтобы в качестве аргумента он получал имя BMP-файла и сам создавал поверхность, но тогда каждый спрайт был бы связан с отдельной поверхностью — даже если для создания нескольких спрайтов используется один и тот же BMP-файл.

Две следующие функции делают одно и то же, но имеют разный синтаксис. Функция GetSurf() и оператор-функция operator LPDIRCETDRAWSURFACE() возвращают указатель на поверхность DirectDraw, которая используется данным спрайтом. Мы уже видели, как GetSurf() используется функцией SpritesCollidePixel(). Перегруженный оператор LPDIRECTDRAWSURFACE() создан для удобства, благодаря ему объекты Sprite можно использовать вместо указателей на поверхности DirectDraw. Как вы увидите позднее, этот перегруженный оператор используется в программе Bumper.

Функции GetX(), GetY(), GetCenterX(), GetCenterY(), SetXY(), SetXYRel() и GetRect() предназначены для работы с положением спрайта. Мы уже видели, как функция GetRect() применяется на практике. В программе Bumper функции GetCenterX() и GetCenterY() используются для определения центральной точки спрайта, по которой определяется новое направление движения после столкновения.

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

Две последние функции, Hit() и Update(), уже упоминались выше. Они обеспечивают подтверждение и реакцию на столкновения.

В закрытой (private) секции объявляются переменные класса Sprite. Первая из них, surf, — указатель на интерфейс DirectDrawSurface, используемый для работы с поверхностью данного объекта Sprite. В переменных x, y, w и h хранятся положение и размеры поверхности. Переменные xinc и yinc служат для анимации спрайта. Как вы вскоре увидите, они инициализируются случайными величинами. Эти две переменные определяют направление, в котором движется спрайт.

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

Сейчас мы подробно рассмотрим все функции класса Sprite. Конструктор класса выглядит так:

Sprite::Sprite(LPDIRECTDRAWSURFACE s, int xx, int yy) {

 DDSURFACEDESC desc;

 ZeroMemory(&desc, sizeof(desc));

 desc.dwSize=sizeof(desc);

 desc.dwFlags=DDSD_WIDTH | DDSD_HEIGHT;

 s->GetSurfaceDesc(&desc);

 surf=s;

 x=xx;

 y=yy;

 w=desc.dwWidth;

 h=desc.dwHeight;

 collide=FALSE;

 CalcVector();

}

Конструктор получает в качестве аргументов указатель на поверхность DirectDraw и исходное положение спрайта. Сохранить эти значения в переменных класса нетрудно, однако мы еще должны инициализировать переменные ширины и высоты (w и h). Для этого необходимо запросить у поверхности DirectDraw ее размеры. С помощью структуры DDSURFACEDESC и функции GetSurfaceDesc() мы узнаем размеры и присваиваем нужные значения переменным. Переменной collide присваивается значение FALSE (потому что столкновение еще не было обнаружено). Наконец, мы вызываем функцию CalcVector(), которая определяется так:

void Sprite::CalcVector() {

 xinc=(rand()%7)-3;

 yinc=(rand()%7)-3;

}

Функция CalcVector() инициализирует переменные xinc и yinc с помощью генератора случайных чисел rand(). Полученное от rand() значение преобразуется так, чтобы оно принадлежало интервалу от –3 до 3. Эти значения будут использоваться для перемещения спрайта при очередном обновлении экрана. Обратите внимание — одна или обе переменные вполне могут быть равны нулю. Если нулю равна только одна переменная, перемещение спрайта ограничивается осью X или Y. Если нулю равны обе переменные, спрайт вообще не двигается.

Функция GetRect() инициализирует объект CRect() данными о положении и размерах спрайта. Эта функция определяется так:

CRect Sprite::GetRect() {

 CRect r;

 r.left=x;

 r.top=y;

 r.right=x+w;

 r.bottom=y+h;

 return r;

}

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

void Sprite::Hit(Sprite* s) {

 if (!collide) {

  collideinfo.x=s->GetCenterX();

  collideinfo.y=s->GetCenterY();

  collide=TRUE;

 }

}

Функция Hit() реализует стадию подтверждения столкновений. В нашем случае она сохраняет положение каждого из столкнувшихся спрайтов и присваивает логической переменной collide значение TRUE. Обратите внимание — сохраняется лишь положение спрайта, а не указатель на сам спрайт. Это сделано намеренно, чтобы мы не смогли обратиться к спрайту во время реакции на столкновение (о ней говорится ниже). Следовательно, если вам потребуется другая информация о столкнувшемся спрайте, кроме его положения (например, тип спрайта или уровень его «здоровья» для компьютерной игры), ее необходимо сохранить в функции Hit(). Эту информацию следует получить немедленно, не дожидаясь стадии реакции, потому что к этому времени статус другого спрайта может измениться.

Функция Sprite::Update() выполняет две задачи: обновляет положение спрайта и, в случае столкновения, изменяет переменные, определяющие направление его перемещения (xinc и yinc). Функция Update() приведена в листинге 9.2.

Листинг 9.2. Функция Sprite::Update()

void Sprite::Update() {

 if (collide) {

  int centerx=GetCenterX();

  int centery=GetCenterY();

  int xvect=collideinfo.x-centerx;

  int yvect=collideinfo.y-centery;

  if ((xinc>0 && xvect>0) || (xinc<0 && xvect<0)) xinc=-xinc;

  if ((yinc>0 && yvect>0) || (yinc<0 && yvect<0)) yinc=-yinc;

  collide=FALSE;

 }

 x+=xinc;

 y+=yinc;

 if (x>640-w/2) {

  xinc=-xinc;

  x=640-w/2;

 }

 if (x<-(w/2)) {

  xinc=-xinc;

  x=-(w/2);

 }

 if (y>480-h/2) {

  yinc=-yinc;

  y=480-h/2;

 }

 if (y<-(h/2)) {

  yinc=-yinc;

  y=-(h/2);

 }

}

Сначала Update() проверяет состояние логической переменной collide. Если переменная равна TRUE, мы получаем данные о положении двух спрайтов (текущего и столкнувшегося с ним) и используем их для вычисления новой траектории текущего спрайта. При этом используется схема, очень далекая от настоящей физической модели — при столкновении каждый спрайт отлетает в направлении, противоположном направлению удара.

Затем переменные x и y обновляются с учетом значений xinc и yinc. Новое положение спрайта проверяется и при необходимости корректируется. Корректировка происходит, когда спрайт более чем наполовину уходит за край экрана.

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

Программа Bumper 

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

Рис. 9.4. Программа Bumper

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

Класс BumperWin 

Программа Bumper, как и все остальные программы в этой книге, построена на основе базового класса DirectDrawWin. Производный от него класс BumperWin определяется так:

class BumperWin : public DirectDrawWin {

public:

 BumperWin();

protected:

 //{{AFX_MSG(BumperWin)

 afx_msg void OnKeyDown(UINT nChar, UINT nRepCnt, UINT nFlags);

 afx_msg void OnDestroy();

 //}}

 AFX_MSG DECLARE_MESSAGE_MAP()

private:

 int SelectDriver();

 int SelectInitialDisplayMode();

 BOOL CreateCustomSurfaces();

 void DrawScene();

 void RestoreSurfaces();

 BOOL SpritesCollide(Sprite* s1, Sprite* s2);

 BOOL SpritesCollideRect(Sprite* s1, Sprite* s2);

 BOOL SpritesCollidePixel(Sprite* s1, Sprite* s2);

private:

 Sprite* sprite[MAX_SPRITES];

 int nsprites;

 LPDIRECTDRAWSURFACE text;

};

В нем объявляются два обработчика сообщений. Функция OnKeyDown() обрабатывает нажатия клавиш, а функция OnDestroy() освобождает спрайты в конце работы программы.

Функции SelectDriver(), SelectInitialDisplayMode(), CreateCustomSurfaces(), DrawScene() и RestoreSurfaces() наследуются от класса DirectDrawWin. Вскоре мы подробно рассмотрим каждую из этих функций. Функции SpritesCollide(), SpritesCollideRect() и SpritesCollidePixel() совпадают с одноименными функциями, описанными выше, однако на этот раз они принадлежат классу BumperWin. Поскольку эти функции уже рассматривались, мы не будем обсуждать их снова.

В классе объявлены три переменные: массив указателей на объекты Sprite, целая переменная для хранения общего количества спрайтов и указатель text на интерфейс DirectDrawSurface. Первые две переменные предназначены для хранения спрайтов и последующих обращений к ним. Указатель text используется для отображения меню, находящегося в левом нижнем углу экрана. 

Инициализация приложения 

При запуске программы Bumper прежде всего вызывается функция SelectDriver(). Чтобы добиться максимальной гибкости, при наличии нескольких драйверов DirectDraw программа Bumper выводит меню. Функция SelectDriver() выглядит так:

int BumperWin::SelectDriver() {

 int numdrivers=GetNumDrivers();

 if (numdrivers==1) return 0;

 CArray<CString, CString> drivers;

 for (int i=0;i<numdrivers;i++) {

  LPSTR desc, name;

  GetDriverInfo(i, 0, &desc, &name);

  drivers.Add(desc);

 }

 DriverDialog dialog;

 dialog.SetContents(&drivers);

 if (dialog.DoModal()!=IDOK) return -1;

 return dialog.GetSelection();

}

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

Функция SelectInitialDisplayMode() вызывается после функции SelectDriver(), но перед созданием поверхностей. Функция выглядит так:

int BumperWin::SelectInitialDisplayMode() {

 DWORD curdepth=GetDisplayDepth();

 int i, nummodes=GetNumDisplayModes();

 DWORD w,h,d;

 if (curdepth!=desireddepth) ddraw2->SetDisplayMode(640, 480, curdepth, 0, 0);

 for (i=0;i<nummodes;i++) {

  GetDisplayModeDimensions(i, w, h, d);

  if (w==desiredwidth && h==desiredheight && d==desireddepth) return i;

 }

 ddraw2->RestoreDisplayMode();

 ddraw2->Release(), ddraw2=0;

 AfxMessageBox("Can't find 8-bit mode on this device");

 return -1;

}

Функция SelectInitialDisplayMode() ищет конкретный видеорежим 640x480x8. Если этот режим не найден, она выводит сообщение и возвращает –1, говоря тем самым классу DirectDrawWin о том, что приложение следует завершить. Если режим будет найден, функция возвращает его индекс. По этому индексу класс DirectDrawWin узнает о том, какой видеорежим следует активизировать.

Если функция SelectInitialDisplayMode() находит нужный видеорежим, класс DirectDrawWin вызывает функцию CreateCustomSurfaces(). Она создает поверхности наших восьми спрайтов, а также поверхность меню. Функция CreateCustomSurfaces() приведена в листинге 9.3.

Листинг 9.3. Функция CreateCustomSurfaces()

BOOL BumperWin::CreateCustomSurfaces() {

 DDCOLORKEY ddck;

 ddck.dwColorSpaceLowValue = 0;

 ddck.dwColorSpaceHighValue = 0;

 LPDIRECTDRAWSURFACE surf;

 srand(time(0));

 CString msg="Can't find ";

 surf=CreateSurface("diamond.bmp", TRUE);

 if (surf==0) {

  msg+="diamond.bmp";

  Fatal(msg);

 }

 surf->SetColorKey(DDCKEY_SRCBLT, &ddck);

 sprite[nsprites++]=new Sprite(surf, 0, 0);

 sprite[nsprites++]=new Sprite(surf, 150, 0);

 surf=CreateSurface("triangle.bmp");

 if (surf==0) {

  msg+="triangle.bmp";

  Fatal(msg);

 }

 surf->SetColorKey(DDCKEY_SRCBLT, &ddck);

 sprite[nsprites++]=new Sprite(surf, 0, 150);

 sprite[nsprites++]=new Sprite(surf, 150, 150);

 surf=CreateSurface("rect.bmp");

 if (surf==0) {

  msg+="rect.bmp";

  Fatal(msg);

 }

 surf->SetColorKey(DDCKEY_SRCBLT, &ddck);

 sprite[nsprites++]=new Sprite(surf, 0, 300);

 sprite[nsprites++]=new Sprite(surf, 150, 300);

 surf=CreateSurface("oval.bmp");

 if (surf==0) {

  msg+="oval.bmp";

  Fatal(msg);

 }

 surf->SetColorKey(DDCKEY_SRCBLT, &ddck);

 sprite[nsprites++]=new Sprite(surf, 300, 0);

 sprite[nsprites++]=new Sprite(surf, 300, 150);

 text=CreateSurface("text.bmp");

 if (text==0) {

  msg+="text.bmp";

  Fatal(msg);

 }

 text->SetColorKey(DDCKEY_SRCBLT, &ddck);

 return TRUE;

}

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

Затем для каждой создаваемой поверхности готовится структура DDCOLORKEY. Для всех поверхностей этого приложения прозрачным является черный цвет (то есть нулевое значение).

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

Наконец, поверхность меню text инициализируется содержимым файла TEXT.BMP. Функция SetColorKey(), как и в случае спрайтовых поверхностей, определяет прозрачный цвет. Код возврата TRUE является признаком успешного завершения. 

Функция DrawScene() 

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

void BumperWin::DrawScene() {

 ASSERT(nsprites>0);

 ASSERT(text);

 for (int s1=0;s1<nsprites;s1++) for (int s2=s1+1;s2>nsprites;s2++) if (SpritesCollide(sprite[s1], sprite[s2])) {

  sprite[s1]->Hit(sprite[s2]);

  sprite[s2]->Hit(sprite[s1]);

 }

 for (int i=0;i<nsprites;i++) sprite[i]->Update();

 ClearSurface(backsurf, 0);

 for (i=0;i<nsprites;i++) {

  Sprite* s=sprite[i];

  BltSurface(backsurf, *s, s->GetX(), s->GetY(), TRUE);

 }

 BltSurface(backsurf, text, 0, 448, TRUE);

 primsurf->Flip(0, DDFLIP_WAIT);

}

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

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

После того как все столкновения будут обнаружены и обработаны, мы стираем вторичный буфер функцией DirectDrawWin::ClearSurface() и выводим каждый спрайт функцией BltSurface(). Обратите внимание на то, что вторым аргументом BltSurface() является указатель на сам объект Sprite. В данном случае оператор LPDIRECTDRAWSURFACE() преобразует объект Sprite в указатель на поверхность, соответствующую данному спрайту. Также стоит заметить, что координаты спрайтов определяются функциями GetX() и GetY(). После прорисовки всех спрайтов в левом нижнем углу вторичного буфера выводится поверхность меню. Функция Flip() переключает страницы и отображает кадр на экране. 

Функция OnKeyDown() 

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

void BumperWin::OnKeyDown(UINT nChar, UINT nRepCnt, UINT nFlags) {

 switch (nChar) {

 case VK_ESCAPE:

  PostMessage(WM_CLOSE);

  break;

 case VK_SPACE:

 case VK_RETURN:

  for (int i=0;i<nsprites;i++) sprite[i]->CalcVector();

  break;

 }

 DirectDrawWin::OnKeyDown(nChar, nRepCnt, nFlags);

}

Восстановление потерянных поверхностей 

Прежде чем расставаться с программой Bumper, мы должны посмотреть, как происходит восстановление потерянных поверхностей. Как обычно, для этого служит функция RestoreSurfaces():

void BumperWin::RestoreSurfaces() {

 for (int i=0;i<nsprites;i++) sprite[i]->GetSurf()->Restore();

 LoadSurface(*sprite[0], "diamond.bmp");

 LoadSurface(*sprite[1], "diamond.bmp");

 LoadSurface(*sprite[2], "triangle.bmp");

 LoadSurface(*sprite[3], "triangle.bmp");

 LoadSurface(*sprite[4], "rect.bmp");

 LoadSurface(*sprite[5], "rect.bmp");

 LoadSurface(*sprite[6], "oval.bmp");

 LoadSurface(*sprite[7], "oval.bmp");

 text->Restore();

 LoadSurface(text, "text.bmp");

}

Сначала область памяти каждой поверхности восстанавливается функцией Restore() (если поверхность не была потеряна, вызов Restore() игнорируется). Затем функция LoadSurface() восстанавливает содержимое поверхности. Обратите внимание — здесь, как и в функции DrawScene(), используется оператор LPDIRECTDRAWSURFACE(), позволяющий передавать объекты Sprite вместо указателей на поверхности. Работа функции завершается восстановлением поверхности меню (text).

Заключение 

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

Эта глава была последней — мы рассмотрели все программы. Тем не менее остались некоторые интересные темы, которые не обсуждались в книге. Мы поговорим о них в приложении А.

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

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

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

Отладка

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

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

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

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

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

Проблемы

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

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

Windows NT и Windows 95

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

Оборотная сторона заключается в том, что по возможностям DirectX NT часто отстает от 95. Поскольку в Windows NT нельзя установить стандартную runtime-часть DirectX, на поддержку новых возможностей у Microsoft уходит больше времени. Следовательно, если вам необходимы новейшие возможности DirectX, то для разработки неизбежно придется использовать Windows 95. Для DirectDraw это не вызывает особых проблем, потому что в последних версиях эта библиотека практически не изменялась. А вот другие DirectX API, напротив, заметно изменились в DirectX 5 (особенно это относится к DirectInput и DirectPlay).

Профессиональные разработчики для DirectX отдают явное предпочтение NT. Более того, некоторые будущие бета-версии DirectX могут предназначаться только для NT.

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

Visual C++ (как и многие другие среды разработки) содержит макросы, предназначенные специально для отладки. Например, макросы 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() определяется так:

#define ASSERT(f) \

 do \

 { \

 if (!(f) && AfxAssertFailedLine(THIS_FILE, __LINE__)) \

  AfxDebugBreak(); \

 } while (0) \

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

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

#define ASSERT(f) \

 do \

 { \

  if (!(f)) \

  { \

   if (GetDDWin()) \

   { \

    GetDDWin()->GetDDraw()->RestoreDisplayMode(); \

    GetDDWin()->GetDDraw()->Release(); \

   } \

   AfxAssertFailedLine(THIS_FILE, __LINE__); \

   AfxDebugBreak(); \

  } \

 } while (0) \

Для работы с объектом DirectDraw применяются функции GetDDWin() и GetDDraw() (которые соответственно возвращают указатели на объект DirectDrawWin и интерфейс DirectDraw). Помимо вызова функции RestoreDisplayMode() мы для приличия освобождаем объект DirectDraw. Также обратите внимание на перестановку, в результате которой наш код будет выполняться перед вызовом функции AfxAssertFailedLine().

Перейдем к макросу VERIFY(). Возвращаясь к заголовочным файлам MFC, мы находим, что в отладочной версии VERIFY() реализуется с помощью макроса ASSERT():

#define VERIFY(f)   ASSERT(f)

Вспомните — в отладочной версии ASSERT() и VERIFY() ведут себя одинаково. Раз ASSERT() и VERIFY() реализуются одним макросом, VERIFY() можно оставить без изменений. Сказанное относится и к окончательным версиям макросов ASSERT() и VERIFY(), потому что нам не потребуется изменять их поведение. При компиляции окончательной версии ASSERT() и VERIFY() определяются так:

#define ASSERT(f)   ((void)0)

#define VERIFY(f)   ((void)(f))

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

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

#ifdef _DEBUG#undef ASSERT#define ASSERT(f) \

 do \

 { \

  if (!(f)) \

  { \

   if (GetDDWin()) \

   { \

    GetDDWin()->GetDDraw()->RestoreDisplayMode(); \

    GetDDWin()->GetDDraw()->Release(); \

   } \

   AfxAssertFailedLine(THIS_FILE, __LINE__); \

   AfxDebugBreak(); \

  } \

 } while (0) \

#endif _DEBUG

Модифицированный макрос находится на CD-ROM и готов к работе, поэтому если вы захотите внести изменения в какую-нибудь программу, то можете свободно пользоваться макросами TRACE(), ASSERT() и VERIFY(). Кроме того, этот код автоматически генерируется и включается в проекты, создаваемые DirectDraw AppWizard.

Удаленная отладка

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

Для выполнения удаленной отладки вам понадобятся два компьютера, объединенных в локальную сеть. Конкретные параметры сети (количество узлов, тип кабеля, сетевые адаптеры и т. д.) не имеют значения; главное — чтобы на обоих компьютерах был установлен сетевой протокол TCP/IP. Кроме того, необходимо установить на обоих компьютерах Visual C++.

Затем вы должны выбрать, на каком компьютере будет работать отладчик Visual C++, а на каком — приложение. Мы будем называть компьютер, на котором работает Visual C++, хостовым компьютером (или хостом), а компьютер с отлаживаемым приложением — удаленным компьютером. Обычно хостом назначают более мощный из двух компьютеров.

Вам необходимо узнать адреса TCP/IP для обоих компьютеров. Проще всего получить этот адрес с помощью утилиты Winipcfg (WINIPCFG.EXE). Для Winipcfg не существует ярлыка (shortcut) или команды меню Start, поэтому придется либо создать ярлык или команду (утилита находится в каталоге Windows), либо запустить Winipcfg из окна DOS или диалогового окна Run меню Start. Окно утилиты Winipcfg изображено на рис. А.1. В поле IP Address приведено значение адреса TCP/IP . В нашем примере удаленный компьютер имеет адрес 128.128.128.1 (а хостовый компьютер будет иметь адрес 128.128.128.2).

Рис. А.1. Утилита Winipcfg

Также вам понадобится сетевое имя удаленного компьютера. Сетевое имя представляет собой неформальную строку, которая облегчает идентификацию сетевых компьютеров (при этом вам не придется запоминать адреса TCP/IP для всех компьютеров сети). Чтобы узнать сетевое имя компьютера, можно щелкнуть правой кнопкой мыши на значке Network Neighborhood (он находится на рабочем столе) и выбрать из контекстного меню команду Properties; откроется диалоговое окно Network. Перейдите на вкладку Identification. На рис. А.2 показано, как выглядит эта вкладка. В данном примере имя удаленного компьютера — remotemachine. Вероятно, вам не стоит менять сетевое имя, если только вы не являетесь сетевым администратором — просто воспользуйтесь именем, которое было назначено компьютеру при исходной настройке.

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

Рис. А.2. Диалоговое окно Network Identification

После того как вы создадите каталог для приложения и убедитесь в том, что оно может выполняться на удаленном компьютере, запустите отладочный монитор Visual C++ (MSVCMON.EXE). Для этой программы, как и для утилиты Winipcfg, не существует ярлыка, поэтому вам придется создать его самостоятельно. Отладочный монитор находится в каталоге bin Visual C++. Если вы собираетесь плотно заняться удаленной отладкой, вероятно, ярлык отладочного монитора следует поместить в удобное место. Окно отладочного монитора Visual C++ изображено на рис. А.3.

Теперь нужно указать адрес хостового компьютера. Убедитесь, что в отладочном мониторе выбрано соединение TCP/IP, и нажмите кнопку Settings — откроется диалоговое окно Win32 Network (TCP/IP) Settings. Введите адрес хоста в первом поле. На рис. А.4 показано, как выглядит диалоговое окно с введенным адресом.

Вводить пароль необязательно — я рекомендую оставить это поле пустым. После ввода адреса хоста нажмите кнопку OK. Вы возвратитесь к диалоговому окну Debug Monitor. Нажмите кнопку Connect. Появится маленькое окно, которое показывает, что отладочный монитор готов начать сеанс отладки. Теперь удаленный компьютер настроен для проведения отладки.

Рис. А.3. Диалоговое окно Visual C++ Debug Monitor

Рис. А.4. Диалоговое окно Network Settings

Теперь займемся настройкой хоста. Запустите Visual C++ и загрузите проект, который вы собираетесь отлаживать. В нашем примере используется проект с именем Sample. Выполните команду Project|Settings и перейдите на вкладку General. На ней задается каталог, в котором генерируется итоговый выполняемый файл. Для упрощения отладки мы будем генерировать его прямо на удаленном компьютере — это избавит нас от необходимости заново копировать выполняемый файл на удаленный компьютер после очередной компиляции. В поле Output files введите имя каталога, созданного ранее на удаленном компьютере. Имя начинается с условного обозначения сетевого файла (\\). На рис. А.5 показано, как выглядит поле Output files с указанным каталогом.

Задаваемая строка начинается с имени удаленного компьютера (remotemachine), за которым следует имя диска (в нашем примере каталог удаленной отладки находится на диске C) и имя каталога. Перейдите на вкладку Debug; здесь необходимо изменить все три поля. Вы должны задать местонахождение целевого выполняемого файла и рабочий каталог. На рис. А.6 показано, как заполняются поля вкладки Debug в нашем примере. Как и на рис. А.5, путь к выполняемому файлу включает имя удаленного компьютера.

Перед тем как приступать к удаленной отладке, остается сделать лишь один шаг. Выполните команду Debugger Remote Connection из меню Build. Эта команда открывает окно (похожее на окно отладочного монитора), предназначенное для активизации и настройки сеанса удаленной отладки. По умолчанию в списке Connection выбирается строка Local. Чтобы перейти к удаленной отладке, выберите строку Network (TCP/IP), как показано на рис. А.7.

Рис. А.5. Поле Output files подготовлено для генерации выполняемого файла на удаленном компьютере

Рис. А.6. Изменения на вкладке Debug

Рис. А.7. Окно Remote Connection

Нажмите кнопку Settings — появится окно, изображенное на рис. А.4. Задайте в нем адрес TCP/IP удаленного компьютера. Поле Debug monitor password оставьте пустым, если только вы не задали пароль при настройке отладочного монитора на удаленном компьютере.

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

Запустите отладчик. Если все параметры были настроены правильно, окно Debug Monitor на удаленном компьютере исчезнет — это говорит о том, что соединение установлено.

Удаленный компьютер попытается запустить программу, и вам будет предложено (на хостовом компьютере) указать местонахождение необходимых DLL. Для каждой DLL открывается окно Find Local Module. Вы должны ввести имя файла, включая сетевое имя компьютера. Окно Find Local Module изображено на рис. А.8 (в нем предлагается задать местонахождение файла WINMM.DLL). Часть введенной строки не поместилась на рисунке, но вы должны помнить о том, что кроме пути необходимо указать имя файла.

Рис. А.8. Окно Find Local Module

После того как вы укажете местонахождение всех DLL (как правило, они располагаются в каталоге windows\system), программа запускается на удаленном компьютере, однако ее отладочный вывод направляется в окно отладчика на хосте. Теперь вы можете отлаживать свою программу. Мы настроили Visual C++ так, что при каждой компиляции новый выполняемый файл будет автоматически копироваться на удаленный компьютер. Удаленная отладка почти ничем не отличается от обычной, разве что программа выполняется не на хосте, а на другом компьютере.

Напоследок я скажу еще несколько слов об удаленной отладке. Во-первых, как ее отключить? Хороший вопрос. Выполните команду Build|Debugger Remote Connection в Visual C++ (на хосте), затем выберите строку Local в списке Connection и нажмите кнопку OK.

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

Выполните команду Project|Settings и перейдите на вкладку Debug. Выберите из списка Category строку Additional DLL. Открывается список DLL, которые Visual C++ пытается загрузить при отладке вашей программы (независимо от того, включена удаленная отладка или нет). Чтобы отказаться от переназначения DLL (для нормальной отладки вам не потребуется ни один из элементов этого списка), выделите соответствующую строку и снимите флажок в левом верхнем углу. Список Additional DLLs с некоторыми DLL, необходимыми для типичных приложений MFC, изображен на рис. А.9.

Рис. А.9. Окно Additional DLLs

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

Вероятно, вы уже заметили, что при запуске приложений DirectX в окне вывода отладчика Visual C++ появляются диагностические сообщения. По умолчанию отладочные версии компонентов 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

DDraw:====> ENTER: DLLMAIN(baaa12c0): Process Attach: fff00c89, tid=fff04bf1

DDraw:Thunk connects

DDraw:Signalling DDHELP that a new process has connected

DDraw:====> EXIT: DLLMAIN(baaa12c0): Process Attach: fff00c89

DDraw:createDC(R3D)

DDraw:Enumerating GUID aba52f41-f744-11cf-b4-52-00-00-1d-1b-41-26

DDraw: Driver Name = R3D

DDraw: Description = Righteous 3D DirectX II Driver

DDraw:DeleteDC 0x179e

DDraw:createDC(mm3dfx)

DDraw:Enumerating GUID 3a0cfd01-9320-11cf-ac-a1-00-a0-24-13-c2-e2

DDraw: Driver Name = mm3dfx

DDraw: Description = 3Dfx Interactive DirectX Driver

DDraw:DeleteDC 0x179e

DDraw:Only one Display device in the current system.

DDraw:DirectDrawCreate entered

DDraw: GUID *:00000000, LPLPDD:0064f870, pUnkOuter:00000000

DDraw:Registry already scanned, not doing it again

DDraw:full name = C:\SAMPLE\DEBUG\SAMPLE.EXE

DDraw:name = SAMPLE.EXE

DDraw:DirectDrawCreate: pid = fff00c89

DDraw:Reading Registry

DDraw: ModeXOnly: 0

DDraw: EmulationOnly: 0

DDraw: ShowFrameRate: 0

DDraw: EnablePrintScreen: 0

DDraw: DisableMMX: 0

DDraw: DisableWiderSurfaces:0

DDraw: DisableNoSysLock:0

DDraw: ForceNoSysLock:0

DDraw:Signalling DDHELP to create a new DC

DDraw:createDC(display)

DDraw:DIRECTDRAW driver is wrong version, got 0x5250, expected 0x0100

DDraw:getDisplayMode:

DDraw: bpp=8, refresh=0

DDraw: dwHeight=600, dwWidth=800

DDraw: lStride=0

DDraw:Driver says nummodes=9

DDraw:Enum Display Settings says nummodes=9

DDraw:dwModeIndex = 1

DDraw:Masks for current mode are: 00000000 00000000 00000000

DDraw:DirectDrawObjectCreate: oldpdd == 00000000, reset=0

DDraw:DIRECTDRAW object passed in = 00000000

DDraw:oldpdd == 00000000, reset=0

DDraw:Driver Object: 2256 base bytes

DDraw:dwReserved3 of DDrawGbl is set to 0x0

DDraw:oldpdd == NULL || reset

DDraw:Driver can't blt

DDraw:pddd->lp16DD = 40cf0000

DDraw:Adding ModeX mode 320x200x8 (standard VGA flag is 0)

DDraw:Adding ModeX mode 320x240x8 (standard VGA flag is 0)

DDraw:Adding ModeX mode 320x200x8 (standard VGA flag is 1)

DDraw:All video memory heaps have been disabled. OS has no AGP support

DDraw:Current and Original Mode = 1

DDraw:@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ MODE INDEX = 1

DDraw:DDHALInfo contains D3D pointers: 00000000 00000000

DDraw:createDC(display)

DDraw:NOT Setting DDCAPS_BANKSWITCHED

DDraw:DeleteDC 0x179e

DDraw:Taking the Win16 lock may not be necessary for VRAM locks

DDraw:DirectDrawObjectCreate: Returning global object 82dc11f8

DDraw:createDC(display)

DDraw:createDC(display)

DDraw:DeleteDC 0x175e

DDraw:DeleteDC 0x179e

DDraw:Primary's rect is 0, 0, 800, 600

DDraw:HELInit for DISPLAY Driver: Reference Count = 1

DDraw:createDC(display)

DDraw:DeleteDC 0x179e

DDraw:createDC(display)

DDraw:createDC(display)

DDraw:DeleteDC 0x175e

DDraw:DeleteDC 0x179e

DDraw:***New local allocated 82dc1b1c for global pdrv 82dc11f8

DDraw:New driver object created, interface ptr = 82dc1b84

DDraw: DirectDrawCreate succeeds, and returns ddraw pointer 82dc1b84

DDraw:New driver interface created, 82dc1bb0

DDraw:DD_AddRef, pid=fff00c89, obj=82dc1bb0

DDraw:DD_AddRef, Reference Count: Global = 2 Local = 2 Int = 1

DDraw:DD_Release, pid=fff00c89, obj=82dc1b84

DDraw:DD_Release, Ref Count: Global = 1 Local = 1 Interface = 0

DDraw:*********** ALLOWING MODE X AND VGA MODES

DDraw:DD_GetDeviceRect: display [0 0 800 600]

DDraw:Subclassing window 00000aac

DDraw:StartExclusiveMode

DDraw:******** invalidating all surfaces

DDraw:Enumerating mode 0. 640x480

DDraw:Enumerating mode 1. 800x600

DDraw:Enumerating mode 2. 1024x768

DDraw:Enumerating mode 3. 1280x1024

DDraw:Enumerating mode 4. 640x480

DDraw:Enumerating mode 5. 800x600

DDraw:Enumerating mode 6. 1024x768

DDraw:Enumerating mode 7. 640x480

DDraw:Enumerating mode 8. 800x600

DDraw:Enumerating mode 9. 320x200

DDraw:Enumerating mode 10. 320x240

DDraw:Enumerating mode 11. 320x200

DDraw:Looking for 640x480x8

DDraw:Found 640x480x8x (flags = 1)

DDraw:Found 800x600x8x (flags = 1)

DDraw:Found 1024x768x8x (flags = 1)

DDraw:Found 1280x1024x8x (flags = 1)

DDraw:Found 640x480x16x (flags = 0)

DDraw:Found 800x600x16x (flags = 0)

DDraw:Found 1024x768x16x (flags = 0)

DDraw:Found 640x480x32x (flags = 0)

DDraw:Found 800x600x32x (flags = 0)

DDraw:Found 320x200x8x (flags = 3)

DDraw:Found 320x240x8x (flags = 3)

DDraw:Found 320x200x8x (flags = 11)

DDraw:Calling HEL SetMode

DDraw:width = 640

DDraw:height = 480

DDraw:bpp = 8

DDraw:WM_DISPLAYCHANGE: 640x480x8

DDraw:DD_GetDeviceRect: display [0 0 640 480]

DDraw:WM_SIZE hWnd=AAC wp=0000, lp=01E00280

DDraw:WM_SIZE: Window restored, NOT sending WM_ACTIVATEAPP

DDraw:createDC(display)

DDraw:DeleteDC 0x1712

DDraw:createDC(display)

DDraw:createDC(display)

DDraw:DeleteDC 0x179e

DDraw:DeleteDC 0x1712

DDraw:createDC(display)

DDraw:getDisplayMode:

DDraw: bpp=8, refresh=0

DDraw: dwHeight=480, dwWidth=640

DDraw: lStride=0

DDraw:Driver says nummodes=9

DDraw:Enum Display Settings says nummodes=9

DDraw:dwModeIndex = 0

DDraw:Masks for current mode are: 00000000 00000000 00000000

DDraw:DirectDrawObjectCreate: oldpdd == 82dc11f8, reset=1

DDraw:DIRECTDRAW object passed in = 82dc11f8

DDraw:oldpdd == 82dc11f8, reset=1

DDraw:Driver Object: 2256 base bytes

DDraw:dwReserved3 of DDrawGbl is set to 0x0

DDraw:oldpdd == NULL || reset

DDraw:Driver can't blt

DDraw:******** invalidating all surfaces

DDraw:All video memory heaps have been disabled. OS has no AGP support

DDraw:Current and Original Mode = 0

DDraw:@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ MODE INDEX = 0

DDraw:DDHALInfo contains D3D pointers: 00000000 00000000

DDraw:createDC(display)

DDraw:NOT Setting DDCAPS_BANKSWITCHED

DDraw:DeleteDC 0x179e

DDraw:Taking the Win16 lock may not be necessary for VRAM locks

DDraw:DirectDrawObjectCreate: Returning global object 82dc11f8

DDraw:createDC(display)

DDraw:createDC(display)

DDraw:DeleteDC 0x1776

DDraw:DeleteDC 0x179e

DDraw:Primary's rect is 0, 0, 640, 480

DDraw:DeleteDC 0x1712

DDraw:Looking for 640x480x16

DDraw:Found 640x480x8x (flags = 1)

DDraw:Found 800x600x8x (flags = 1)

DDraw:Found 1024x768x8x (flags = 1)

DDraw:Found 1280x1024x8x (flags = 1)

DDraw:Found 640x480x16x (flags = 0)

DDraw:Found 800x600x16x (flags = 0)

DDraw:Found 1024x768x16x (flags = 0)

DDraw:Found 640x480x32x (flags = 0)

DDraw:Found 800x600x32x (flags = 0)

DDraw:Found 320x200x8x (flags = 3)

DDraw:Found 320x240x8x (flags = 3)

DDraw:Found 320x200x8x (flags = 11)

DDraw:Calling HEL SetMode

DDraw:width = 640

DDraw:height = 480

DDraw:bpp = 16

DDraw:Window 00000ac4 is on top of us!!

DDraw:Window 00000ac4 is on top of us!!

DDraw:Window 00000ac4 is on top of us!!

DDraw:WM_DISPLAYCHANGE: 640x480x16

DDraw:DD_GetDeviceRect: display [0 0 640 480]

DDraw:createDC(display)

DDraw:DeleteDC 0x172a

DDraw:createDC(display)

DDraw:createDC(display)

DDraw:DeleteDC 0xc96

DDraw:DeleteDC 0x172a

DDraw:createDC(display)

DDraw:getDisplayMode:

DDraw: bpp=16, refresh=0

DDraw: dwHeight=480, dwWidth=640

DDraw: lStride=0

DDraw:Driver says nummodes=9

DDraw:Enum Display Settings says nummodes=9

DDraw:dwModeIndex = 4

DDraw:Masks for current mode are: 00007c00 000003e0 0000001f

DDraw:DirectDrawObjectCreate: oldpdd == 82dc11f8, reset=1

DDraw:DIRECTDRAW object passed in = 82dc11f8

DDraw:oldpdd == 82dc11f8, reset=1

DDraw:Driver Object: 2256 base bytes

DDraw:dwReserved3 of DDrawGbl is set to 0x0

DDraw:oldpdd == NULL || reset

DDraw:Driver can't blt

DDraw:******** invalidating all surfaces

DDraw:All video memory heaps have been disabled. OS has no AGP support

DDraw:Current and Original Mode = 4

DDraw:@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ MODE INDEX = 4

DDraw:DDHALInfo contains D3D pointers: 00000000 00000000

DDraw:createDC(display)

DDraw:NOT Setting DDCAPS_BANKSWITCHED

DDraw:DeleteDC 0xc96

DDraw:Taking the Win16 lock may not be necessary for VRAM locks

DDraw:DirectDrawObjectCreate: Returning global object 82dc11f8

DDraw:createDC(display)

DDraw:createDC(display)

DDraw:DeleteDC 0x179e

DDraw:DeleteDC 0xc96

DDraw:Primary's rect is 0, 0, 640, 480

DDraw:DeleteDC 0x172a

DDraw:82dc1bb0->CreateSurface

DDraw: DDSURFACEDESC->dwBackBufferCount = 1

DDraw: DDSURFACEDESC->lpSurface = 00000000

DDraw: DDSCAPS_COMPLEX

DDraw: DDSCAPS_FLIP

DDraw: DDSCAPS_PRIMARYSURFACE

DDraw:******** invalidating all primary surfaces

DDraw:#### Using GDI screen bpp = 16

DDraw:*** allocating primary surface

DDraw:createDC(display)

DDraw:createDC(display)

DDraw:DeleteDC 0x179e

DDraw:DeleteDC 0xc96

DDraw:#### Using GDI screen bpp = 16

DDraw:*** allocating a backbuffer

DDraw:HEL:About to allocate 614400 bytes for the surface

DDraw:DD_Surface_AddRef, Reference Count: Global = 1 Local = 1 Int = 1

DDraw:DD_Surface_AddRef, Reference Count: Global = 1 Local = 1 Int = 1

DDraw: CreateSurface returns 00000000 (0)

DDraw:DD_Surface_AddRef, Reference Count: Global = 2 Local = 2 Int = 2

DDraw:82dc1bb0->CreateSurface

DDraw: DDSURFACEDESC->dwHeight = 240

DDraw: DDSURFACEDESC->dwWidth = 320

DDraw: DDSURFACEDESC->lpSurface = 00000000

DDraw: DDSCAPS_OFFSCREENPLAIN

DDraw: DDSCAPS_VIDEOMEMORY

DDraw:No hardware support

DDraw: CreateSurface returns 88760233 (563)

DDraw:82dc1bb0->CreateSurface

DDraw: DDSURFACEDESC->dwHeight = 240

DDraw: DDSURFACEDESC->dwWidth = 320

DDraw: DDSURFACEDESC->lpSurface = 00000000

DDraw: DDSCAPS_OFFSCREENPLAIN

DDraw: DDSCAPS_SYSTEMMEMORY

DDraw:Forcing pixel format for explicit system memory surface

DDraw:#### Got surface pixel format bpp = 16

DDraw:*** allocating a surface 320x240x16

DDraw:HEL: About to allocate 153600 bytes for the surface of 640x240 with alignemnt 8

DDraw:DD_Surface_AddRef, Reference Count: Global = 1 Local = 1 Int = 1

DDraw: CreateSurface returns 00000000 (0)

DDraw:82dc1f74->Lock

DDraw: DDSURFACEDESC->dwHeight = 240

DDraw: DDSURFACEDESC->dwWidth = 320

DDraw: DDSURFACEDESC->lPitch = 640

DDraw: DDSURFACEDESC->lpSurface = 004b7118

DDraw:Flags:

DDraw: DDPF_RGB

DDraw: BitCount:16

DDraw: Bitmasks: R/Y:00007c00, G/U:000003e0, B/V:0000001f, Alpha/Z:00000000

DDraw: DDSCAPS_OFFSCREENPLAIN

DDraw: DDSCAPS_SYSTEMMEMORY

DDraw:WM_SIZE hWnd=AAC wp=0000, lp=01E00280

DDraw:WM_SIZE: Window restored, sending WM_ACTIVATEAPP

DDraw:WM_ACTIVATEAPP: BEGIN Activating app pid=fff00c89, tid=fff04bf1

DDraw:*** Already activated

DDraw:WM_ACTIVATEAPP: DONE Activating app pid=fff00c89, tid=fff04bf1

DDraw:Bringing window to top

DDraw:WM_ACTIVATEAPP: BEGIN Deactivating app pid=fff00c89, tid=fff04bf1

DDraw:*** Active state changing

DDraw:******** invalidating all surfaces

DDraw:INACTIVE: fff00c89: Restoring original mode (1)

DDraw:In RestoreDisplayMode

DDraw:Turning off DCI in mySetMode

DDraw:WM_DISPLAYCHANGE: 800x600x8

DDraw:DD_GetDeviceRect: display [0 0 800 600]

DDraw:WM_SIZE hWnd=AAC wp=0000, lp=02580320

DDraw:WM_SIZE: Window restored, NOT sending WM_ACTIVATEAPP

DDraw:WM_ACTIVATEAPP: BEGIN Deactivating app pid=fff00c89, tid=fff04bf1

DDraw:*** Already deactivated

DDraw:WM_ACTIVATEAPP: DONE Deactivating app pid=fff00c89, tid=fff04bf1

DDraw:createDC(display)

DDraw:createDC(display)

DDraw:DeleteDC 0x159a

DDraw:DeleteDC 0xa4a

DDraw:RestoreDisplayMode: Process fff00c89 Mode = 4

DDraw:createDC(display)

DDraw:getDisplayMode:

DDraw: bpp=8, refresh=0

DDraw: dwHeight=600, dwWidth=800

DDraw: lStride=0

DDraw:Driver says nummodes=9

DDraw:Enum Display Settings says nummodes=9

DDraw:dwModeIndex = 1

DDraw:Masks for current mode are: 00000000 00000000 00000000

DDraw:DirectDrawObjectCreate: oldpdd == 82dc11f8, reset=1

DDraw:DIRECTDRAW object passed in = 82dc11f8

DDraw:oldpdd == 82dc11f8, reset=1

DDraw:Driver Object: 2256 base bytes

DDraw:dwReserved3 of DDrawGbl is set to 0x0

DDraw:oldpdd == NULL || reset

DDraw:Driver can't blt

DDraw:******** invalidating all surfaces

DDraw:All video memory heaps have been disabled. OS has no AGP support

DDraw:Current and Original Mode = 1

DDraw:@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ MODE INDEX = 1

DDraw:DDHALInfo contains D3D pointers: 00000000 00000000

DDraw:createDC(display)

DDraw:NOT Setting DDCAPS_BANKSWITCHED

DDraw:DeleteDC 0x170a

DDraw:Taking the Win16 lock may not be necessary for VRAM locks

DDraw:DirectDrawObjectCreate: Returning global object 82dc11f8

DDraw:createDC(display)

DDraw:createDC(display)

DDraw:DeleteDC 0xaa2

DDraw:DeleteDC 0x170a

DDraw:Primary's rect is 0, 0, 800, 600

DDraw:DeleteDC 0x13ba

DDraw:Redrawing all windows

DDraw:DoneExclusiveMode

DDraw:Enabling error mode, hotkeys

DDraw:Mode was never changed by this app

DDraw:WM_ACTIVATEAPP: DONE Deactivating app pid=fff00c89, tid=fff04bf1

DDraw:DD_Surface_Release, Reference Count: Global = 0 Local = 0 Int = 0

DDraw:Deleting attachment from 82dc1e98 to 82dc1b84 (implicit = 1)

DDraw:DeleteOneAttachment: 82dc1b84,82dc1e98

DDraw:DD_Surface_AddRef, Reference Count: Global = 3 Local = 3 Int = 3

DDraw:Leaving AddRef early to prevent recursion

DDraw:DeleteOneLink: 82dc1e98,82dc1b84

DDraw:DeleteOneLink: 82dc1b84,82dc1e98

DDraw:DD_Surface_Release, Reference Count: Global = 2 Local = 2 Int = 2

DDraw:Leaving Release early to prevent recursion

DDraw:DD_Surface_Release, Reference Count: Global = 1 Local = 1 Int = 1

DDraw:DD_Surface_Release, Reference Count: Global = 0 Local = 0 Int = 0

DDraw:Freeing pointer 0042110c

DDraw:DD_Release, pid=fff00c89, obj=82dc1bb0

DDraw:DD_Release, Ref Count: Global = 0 Local = 0 Interface = 0

DDraw:Unsubclassing window 00000aac

DDraw:ProcessSurfaceCleanup

DDraw:Process fff00c89 had 1 accesses to surface 82dc1f74

DDraw:DD_Surface_Release, Reference Count: Global = 0 Local = 0 Int = 0

DDraw:Freeing pointer 004b7118

DDraw:Leaving ProcessSurfaceCleanup

DDraw:ProcessPaletteCleanup, ppal=00000000

DDraw:ProcessClipperCleanup

DDraw:Cleaning up clippers owned by driver object 0x82dc11f8

DDraw:Not cleaning up clippers not owned by a driver object

DDraw:ProcessVideoPortCleanup

DDraw:Leaving ProcessVideoPortCleanup

DDraw:Mode was never changed by this app

DDraw:FREEING DRIVER OBJECT

DDraw:Calling HEL DestroyDriver

DDraw:HEL DestroyDriver: dwHELRefCnt=0

DDraw:3 surfaces allocated - 768000 bytes total

DDraw:*********** DDHEL TIMING INFO ************

DDraw:myFlip: 30 calls, 1.365 sec (0.045)

DDraw:myLock: 1 calls, 0.000 sec (0.000)

DDraw:myUnlock: 1 calls, 0.000 sec (0.000)

DDraw:******************************************

DDraw:Frequency(cycles/second)(0) 1193180

DDraw:Blt16_SrcCopy(32): SUM = 264860

DDraw:Blt16_SrcCopy(32): COUNT = 30

DDraw:Blt16_SrcCopy(32): AVG = 8828

DDraw:Blt16_SrcCopy(32): MIN = 8572

DDraw:Blt16_SrcCopy(32): MAX = 9964

DDraw:Blt16_SrcCopy(32): Dst MB/sec = 17

DDraw:Blt16_ColorFill(47): SUM = 716435

DDraw:Blt16_ColorFill(47): COUNT = 32

DDraw:Blt16_ColorFill(47): AVG = 22388

DDraw:Blt16_ColorFill(47): MIN = 15855

DDraw:Blt16_ColorFill(47): MAX = 55858

DDraw:Blt16_ColorFill(47): Dst MB/sec = 27

DDraw:P6SrcCopy(Bypass Blt16_SrcCopy)(88): SUM = 263495

DDraw:P6SrcCopy(Bypass Blt16_SrcCopy)(88): COUNT = 30

DDraw:P6SrcCopy(Bypass Blt16_SrcCopy)(88): AVG = 8783

DDraw:P6SrcCopy(Bypass Blt16_SrcCopy)(88): MIN = 8528

DDraw:P6SrcCopy(Bypass Blt16_SrcCopy)(88): MAX = 9917

DDraw:P6SrcCopy(Bypass Blt16_SrcCopy)(88): Dst MB/sec = 17

DDraw:Driver is now FREE

DDraw:====> ENTER: DLLMAIN(baaa12c0): Process Detach fff00c89, tid=fff04bf1

DDraw:MemState

DDraw:Memory still allocated! Alloc count = 11

DDraw:Current Process (pid) = fff00c89

DDraw:82dc100c: dwSize=00000008, lpAddr=baaa1bbc (pid=fff1b349)

DDraw:82dc1054: dwSize=0000001d, lpAddr=baae5093 (pid=fff18e61)

DDraw:82dc1090: dwSize=00000019, lpAddr=baae5093 (pid=fff18e61)

DDraw:82dc10c8: dwSize=00000019, lpAddr=baae5093 (pid=fff18e61)

DDraw:82dc1100: dwSize=0000001d, lpAddr=baae5093 (pid=fff18e61)

DDraw:82dc113c: dwSize=00000018, lpAddr=baae5093 (pid=fff18e61)

DDraw:82dc1170: dwSize=00000019, lpAddr=baae5093 (pid=fff18e61)

DDraw:82dc11a8: dwSize=0000001c, lpAddr=baae52c8 (pid=fff18e61)

DDraw:82dc1030: dwSize=00000008, lpAddr=baaa1bbc (pid=fff04a0d)

DDraw:82dc1fc0: dwSize=00000008, lpAddr=baaa1bbc (pid=fff04a0d)

DDraw:82dc1c3c: dwSize=00000008, lpAddr=baaa1bbc (pid=fff00c89)

DDraw:Total Memory Unfreed From Current Process = 8 bytes

DDraw:====> EXIT: DLLMAIN(baaa12c0): Process Detach fff00c89

Замечания о Visual C++ 

Как бы вы ни относились к Visual C++, приходится признать: это чрезвычайно мощный пакет. В нем объединены компилятор, компоновщик, отладчик, профайлер и редактор ресурсов — я перечислил лишь основные компоненты. С каждой новой версией он становится все больше и мощнее. Однако сказанное относилось только к C++! Сам по себе Visual C++ является интегрированным компонентом Developer Studio — многоцелевой и многоязыковой платформы разработчика, с которой мне никогда не надоедает работать.

Visual C++ тоже не стоит на месте. Хорошо это или плохо, но в него постоянно вносятся изменения, а значит — возникают новые проблемы. К тому же Microsoft иногда стремится опередить события и под давлением маркетинговых и финансовых соображений выпускает продукты, которым полагалось бы находиться на стадии бета-тестирования. Трудно сказать, относится ли сказанное к Visual C++ 5.0. Впрочем, на момент написания книги уже существовало дополнение (service pack), исправляющее целый ряд багов. Чаще всего от ошибок страдают новые средства Visual C++ (например, говорят, что их хватает в новой библиотеке ActiveX Template Library (ATL)). К счастью, в данной книге эти новые возможности не используются.

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

С другой стороны, в Visual C++ появилось несколько хороших, хотя и запоздалых возможностей. Один из примеров — новые ключевые слова bool, true и false. В течение некоторого времени они уже входили в стандарт C++; хорошо, что мы наконец сможем ими пользоваться.

В этом разделе мы поговорим о Visual C++. Одни вопросы относятся к программам из этой книги, другие — ко всем проектам, написанным на Visual C++.

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

Лично я — горячий поклонник прекомпилированных заголовков. Настроить их нетрудно, а компиляция проектов 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.

Рис. А.13. Вкладка C/C++ окна Project Settings

После того, как вы создадите новый проект с помощью DirectDraw AppWizard, выполните команду Project|Settings и перейдите на вкладку C/C++. Затем выберите из списка Category строку Precompiled Headers. По умолчанию устанавливается переключатель Automatic use of Precompiled Headers, однако автоматическая настройка прекомпилированных заголовков намного уступает ручной. Стандартный вид вкладки C/C++ окна Project Settings изображен на рис. А.13.

Выберите из расположенного слева списка Setting For строку All Configurations. Благодаря этому мы сможем разрешить применение прекомпилированных заголовков как в окончательной, так и в отладочной конфигурации. Теперь установите переключатель Use precompiled header file и введите в поле Through header строку headers.h — имя файла, в котором будут храниться данные прекомпилированных заголовков.

Теперь раскройте в иерархическом дереве слева узел Sample — появятся три узла следующего уровня. Раскройте узел Source Files. Выберите файл Headers.cpp, один раз щелкнув на его строке. Затем установите переключатель Create precompiled header file и введите в поле Through header строку headers.h. Диалоговое окно после внесения всех необходимых изменений изображено на рис. А.14.

Рис. А.14. Вкладка C/C++ окна Project Settings после внесения изменений

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

И последнее замечание. Лучшими кандидатами для прекомпиляции являются заголовочные файлы MFC и DirectX (именно они включены в файл Headers.h во всех проектах на CD-ROM, а также в тех, что создаются DirectDraw AppWizard). Тем не менее, если эти файлы изменятся (например, из-за выхода новой версии Visual C++ или DirectX), вы должны обновить прекомпилированные заголовки командой Rebuild All.

Файлы DirectX SDK 

Начиная с версии 4.2, Visual C++ содержит DirectX SDK. К сожалению, обычно в Visual C++ входит относительно старая версия SDK (Visual C++ 4.2 поставляется с DirectX 2 SDK, а Visual C++ 5.0 — с DirectX 3 SDK). Скорее всего, из-за этого вы будете работать с версией DirectX SDK, полученной в другом месте (например, на Web-узле Microsoft).

Тем не менее при установке новой версии SDK часто возникают проблемы, потому что по умолчанию старые файлы DirectX не замещаются новыми. Это происходит из-за того, что Microsoft помещает файлы DirectX в стандартные каталоги include и lib (если файлы MFC хранятся в отдельных каталогах, почему Microsoft не могла сделать того же с файлами DirectX?).

Если вы столкнетесь с этой проблемой (это произойдет, когда программа, использующая новые возможности DirectX, откажется компилироваться), у вас есть два варианта:

• скопировать новые файлы DirectX SDK поверх старых;

• сделать так, чтобы новые каталоги SDK рассматривались раньше старых.

Первый вариант нежелателен, потому что стандартные файлы Visual C++ обычно не стоит изменять. Кроме того, вам придется заново копировать файлы с выходом каждой новой версии Visual C++ или DirectX SDK.

Лучше воспользоваться вторым вариантом. Для этого выполните команду Tools | Options и перейдите на вкладку Directories. Затем выберите каталог с файлами DirectX SDK и поместите его в списке над другими каталогами (с помощью кнопки­). На рис. А.15 показано, как может выглядеть список каталогов после внесения необходимых изменений.

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

Рис. А.15. Вкладка Directories окна Options 

Фокусы ClassView 

ClassView — древовидный элемент окна рабочей области, в котором отображается список классов, входящих в проект (он достаточно удобен для перемещения по проекту). Узлы дерева соответствуют классам; раскрывая их, вы можете просмотреть члены класса. Хотя на первый взгляд ClassView Visual C++ 5.0 ничем не отличается от предыдущих версий, на самом деле он ведет себя несколько иначе.

В Visual C++ 5.0 ClassView отображает лишь те классы, чьи заголовочные файлы были явно включены в проект (командой Project|Add to Project|Files). Если в проект не включено ни одного H-файла, в ClassView не будет ни одного класса. Этим он отличается от Visual C++ 4.x, где выводились все классы из файлов проекта и тех файлов, от которых зависят файлы проекта. Это может показаться шагом назад, но на самом деле это новое поведение позволяет управлять составом классов, отображаемых в ClassView (в предыдущих версиях такого выбора не было).

При импортировании старых проектов в Visual C++ 5.0 по умолчанию отображаются все классы. Класс отсутствует в ClassView лишь в том случае, если CPP-файл был включен в проект без соответствующего H-файла.

 Работа с Visual C++ 4.0 

Хотя Visual C++ 4.0 не используется в этой книге напрямую, ничто не помешает вам работать с ним. Но так как на CD-ROM находятся файлы проектов только для Visual C++ 5.0 (для которого обратная совместимость не предусмотрена), вам придется создать файлы рабочей области самостоятельно. Это делается так:

1. Создайте пустое приложение Win32.

2. Скопируйте CPP-, H- и RC-файлы из каталога с компилируемой программой в каталог с новой, пустой рабочей областью.

3. Включите файлы в пустой проект (командой Project|Add to project|Files).

Заодно можно настроить прекомпилированные заголовки (см. выше). Проект готов к компиляции.

Хотя пользователи Visual C++ 4.x смогут пользоваться программами из этой книги, DirectDraw AppWizard работать не будет. Если читатели проявят достаточный интерес, я могу создать соответствующую версию и поместить ее на Web-узел.

Варианты Visual C++ 

И последнее замечание о Visual C++. Поскольку этот продукт выпускается в трех вариантах (Learning, Professional и Enterprise), иногда читателям не удается скомпилировать проект. Для написания и тестирования программ этой книги я пользовался вариантом Professional, так что при работе с другими вариантами могут возникнуть проблемы. Впрочем, в основном это проблемы мелкие и легко излечимые. Если у вас возникнут трудности и вы решите обратиться ко мне, пожалуйста, укажите версию и вариант Visual C++.

Советы и рекомендации 

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

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

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

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

DDHEL: ChangeDisplaySettings LIED!!!

DDHEL: Wanted 640x480x16 got 1024x768x8

DDHEL: ChangeDisplaySettings FAILED: returned -1

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

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

int SampleWin::SelectInitialDisplayMode() {

 DWORD curdepth=GetDisplayDepth();

 int i, nummodes=GetNumDisplayModes();

 DWORD w,h,d;

 if (curdepth!=16) ddraw2->SetDisplayMode(640, 480, curdepth, 0, 0 );

 // Искать режим 640x480x16 после смены видеорежима

 for (i=0;i>nummodes;i++) {

  GetDisplayModeDimensions(i, w, h, d);

  if (w==640 && h==480 && d==16) return i;

 }

 return -1;

}

Мы проверяем глубину пикселей текущего видеорежима Windows функцией DirectDrawWin::GetDisplayDepth(). Нас интересует режим с 16-битными пикселями, поэтому при использовании другой глубины мы активизируем режим 640×480 с текущей глубиной, вызывая функцию SetDisplayMode() интерфейса DirectDraw. Затем можно переходить к поиску нужного режима в традиционном цикле.

Другой выход — просто воспользоваться той глубиной пикселей, которая в данный момент установлена в Windows. Этот вариант не подойдет в тех случаях, когда работа программы зависит от определенных параметров видеорежима, но неплохо работает, если приложение поддерживает видеорежимы с различными глубинами пикселей. В частности, он встречается в программе Switch (см. главу 4), разработанной специально для поддержки любого режима. Функция SelectInitialDisplayMode() в программе Switch выглядит так:

int SwitchWin::SelectInitialDisplayMode() {

 DWORD curdepth=GetDisplayDepth();

 int i, nummodes=GetNumDisplayModes();

 DWORD w,h,d;

 // Искать режим 640x480 с текущей глубиной пикселей

 for (i=0;i<nummodes;i++) {

  GetDisplayModeDimensions(i, w, h, d);

  if (w==640 && h==480 && d==curdepth) return i;

 }

 return 0;

}

Эта функция ищет режим 640×480 с текущей глубиной пикселей. Такой режим наверняка найдется, потому что 640×480 — «общий знаменатель» для всех видеорежимов и нам известно, что нужная глубина пикселей уже установлена в Windows.

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

Символическая константа INITGUID (устаревшая) 

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

Вы не встретите INITGUID в программах на CD-ROM, потому что, начиная с DirectX 3, появилось более удачное решение — вместо того, чтобы определять INITGUID, достаточно подключить к проекту файл DXGUID.LIB. На случай, если вы не знали…

Эмуляция версий 

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

К сожалению, в DirectX API часто используются структуры. Эти структуры являются «открытыми» — доступ к ним осуществляется непосредственно, а не через интерфейс, как для COM-объектов. Размер этих структур может изменяться (и часто изменяется) при переходе к новой версии DirectX. По этой причине каждая функция DirectX, которой в качестве аргумента передается указатель на структуру, должна обязательно получать и размер передаваемой структуры. Благодаря этому runtime-часть DirectX всегда может узнать, какая версия DirectX SDK применялась для компиляции приложения, и следовательно — какие поля входят в структуру. Проблема решена, не так ли?

А что вы скажете насчет программы, которая была откомпилирована в DirectX 5 SDK, но затем запущена с runtime-частью DirectX 3? Если одна или несколько структур DirectX 5 были дополнены новыми полями и флагами, runtime-часть не сможет обработать эту структуру, потому что ничего не знает о появившихся в ней расширениях.

К решению этой проблемы (которую мы ласково назовем «структурной ошибкой DirectX») можно подойти четырьмя способами:

• поставлять нужную runtime-часть DirectX вместе с продуктом и настаивать на том, чтобы она устанавливалась на компьютерах со старыми версиями;

• написать «умный» код, который проверяет версию установленных DLL и затем использует только структуры, поддерживаемые runtime-частью;

• выбрать самую старую версию runtime-части, поддерживаемую вашей программой, и написать код в расчете на нее;

• отказаться от технологии и всего, что с ней связано.

Коммерческие программы (особенно пакеты, распространяемые на CD-ROM) в основном используют первый вариант. Он прост и позволяет всегда работать с новейшими возможностями DirectX. С другой стороны, runtime-часть DirectX 5 занимает 135 Мбайт. Это значит, что для настоящего продукта на CD-ROM остается меньше места, или вам придется поставлять дополнительный диск с DirectX. Разумеется, этот вариант не подходит для приложений, распространяемых без CD-ROM или через Internet.

Второй вариант достаточно гибок и позволяет запустить приложение практически с любой runtime-частью, но дело это, мягко говоря, хлопотное. Обычно игра не стоит свеч — даже если вы сможете обнаружить старую runtime-часть, как компенсировать отсутствие новых возможностей? Кончится тем, что для старой версии вы будете выводить сообщение, предлагая пользователю достать новую версию DirectX.

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

Каждый компонент DirectX определяет номер версии и пользуется им в заголовочном файле. Для DirectDraw этой цели служит символическая константа DIRECTDRAW_VERSION. Например, в DirectX 3 SDK константа DIRECTDRAW_VERSION равна 0300 (завершающие нули обозначают младший номер версии).

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

#define DIRECTDRAW_VERSION 0x300

#include <ddraw.h>

то определяемые структуры будут идентичны тем, что определялись в DirectX 3 SDK, даже если на самом деле вы работаете с DirectX 5 SDK.

Вариант 4 выглядит соблазнительно (но я слишком люблю играть в Quake).

Где достать DirectX SDK 

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

Перед выходом DirectX я также предупреждал их, что файл SDK занимает 28 Мбайт.

Размер DirectX 3 SDK разочаровал многих читателей, а некоторые из-за этого даже не смогли работать с ним. 28 Мбайт — громадный объем для всех, у кого нет доступа к Internet через ISDN или T1, и при этом он мог бы быть и поменьше. Большую часть этих 28 Мбайт занимают примеры программ, без которых разработчик может обойтись. Строго говоря, действительно необходимы лишь H- и LIB-файлы, которые сжимаются до 100 Кб. Справочный файл сокращается до 4 Мбайт. Разумеется, эти компоненты можно было бы сделать доступными и по отдельности.

В августе 1997 года (на момент написания этой книги) Microsoft выпустила DirectX 5 и выложила его на свою Web-страницу. На этот раз ей значительно лучше удалось удержать размер файлов в разумных пределах. Эти файлы можно найти по адресу .

Оглавление

Предисловие

Введение

Для чего написана эта книга

Требования к читателю

Программные требования

Аппаратные требования

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

  Что такое DirectDraw?

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

  DirectDraw API

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

    Интерфейсы DirectDrawSurface  

    Интерфейс DirectDrawPalette  

    Интерфейс DirectDrawClipper  

    Дополнительные интерфейсы DirectDraw  

    Структуры DirectDraw 

  Создание приложений DirectDraw  

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

Глава 2. Проблемы быстродействия                 

Глава 3. За кулисами DirectDraw

  DirectDraw AppWizard

    Создание приложения Bounce

  Структура приложения

  Инициализация DirectDraw

  Создание поверхностей

  Графический вывод

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

Глава 4. Видеорежимы и частота смены кадров

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

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

  Вычисление FPS

  Графический вывод

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

  Частота смены кадров 

Глава 5. Поверхности и форматы пикселей     

  Поверхности

  BMP-файлы

  Программа BmpView 

Глава 6. DirectInput

  Что такое DirectInput?

  DirectInput API

  Программа Qwerty

  Инициализация DirectInput

  Управление версией DirectInput

  Программа Smear

Глава 7. Проблема курсора

  Частичное обновление экрана

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

  Решение проблемы курсора

  Программа Cursor

Глава 8. Воспроизведение видеороликов

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

  Программа AviPlay

Глава 9. Проверка столкновений               

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

  Функции проверки столкновений

  Класс Sprite 

  Программа Bumper 

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

  Отладка

  Замечания о Visual C++ 

  Советы и рекомендации 

Реклама на сайте