Нередко оптимальное решение заключается в том, чтобы организовать в приложении поддержку как палитровых, так и беспалитровых видеорежимов и предложить пользователю выбрать нужный режим. Конечно, такой вариант требует дополнительных хлопот, но зато он устроит больше пользователей.
Долой аппаратную зависимость!
Если в приложении используются возможности, поддерживаемые лишь некоторыми видеокартами, такое приложение называется аппаратно-зависимым (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 (и, возможно, легкая головная боль).
Если вы работали с 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.
