"DirectX 8. Начинаем работу с DirectX Graphics" - читать интересную книгу автора (, Ваткин Сергей, Dempski Kelly, Watson Johnny, Поздняков...)

#3: Каркас графического приложения

Создание каркаса графического приложения — это занятие достаточно простое с технической точки зрения, но очень (ну может не очень, но все равно) сложное с архитектурной точки зрения. Фактически, не было ни одного случая, чтобы первый каркас любого программиста в его жизни не был забракован по той или иной причине. Кроме того, причиной, по которой здесь рассмотрен каркас в числе первых элементов, можно считать, что создание каркаса — это отличный способ узнать тонкости как Direct3D программирования, так и программирования под Win32 API. А посмотреть на хорошо написанный каркас полезно не только для новичков, но и для вполне профессиональных программистов. Хотя бы для того, чтобы смело сказать: "Ха, да у меня лучше". И улыбнуться :). Будем считать, что тот каркас, который приводится здесь, относится как раз к хорошим. Ссылка в конце статьи. И я надеюсь, что мои предыдущие статьи заинтересовали вас в достаточной степени, чтобы вы скачали эти несколько сот килобайт архива.

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

Общедоступные реализации подобных задач были и от NVIDIA (NVToolkit, доступен на сайте http://developer.nvidia.com) и от Microsoft (CD3DApplication, поставляется в комплекте DirectX SDK). Кроме того, доступны различные игровые движки, в которых это тоже можно посмотреть. Но все эти реализации обладают несколькими минусами, которые сводят на нет их плюсы. Рассмотрим по порядку. NVToolkit рассчитана на разработку программ примеров. Поэтому реализованы только графические функции, а все, что должно быть в каркасе, но к графике не относится, они смело проигнорировали. Кроме того, структура очень запутана и явно не подходит на роль первого каркаса, который программист видит в своей жизни. CD3DApplication — Корпорация как всегда в своем репертуаре. Все написано очень правильно - в этом направлении не придраться. Единственный вопрос, который возникает — зачем так усложнять? Я мне кажется что для многих программистов, для которых класс CD3DApplication (ну или CD3DFramework, так он, по-моему, назывался в DirectX 7) стал первым, он же стал и последним. Но просто так ничего не бывает, поэтому подобной реализации есть оправдание: Класс — для переносимости кода и легкого встраивания в приложения со структурой Document/View. Все остальное — для гарантии того, что приложение запустится на любой машине. Самый спорный момент — енумерация и выбор REF, если функция аппаратно не поддерживается, увидеть все равно ничего нельзя (REF), но Microsoft смогла доказать что ее приложения запускаются на любой машине. (Те, кто видел Heroes 2 от NWC, запущенный на 486 SX-25/4 Mb под Windows 95, тот меня поймет, я видел :( ). Опять таки, все что превосходит графическую сторону приложения не было затронуто. Все коммерческие движки, во-первых — это уже движки, во-вторых. Полностью в них разобраться может только автор (а учитывая то, что написал он это давно, то и это под вопросом) и с десяток особо умных программистов, которые на это даже времени тратить не будут. Поэтому дерзайте в Сети достаточно ссылок - ищите, да найдете :). В любом случае, даже если вы посмотрите на то, что написал я и оно вам понравится, я бы советовал скачать какой-нибудь свободно распространяемый движок и просто посмотреть на него, там могут быть реализации, которые ни вам, ни мне просто не придут в голову (все мы думаем по-разному, даже если говорим одно и то же).

Итак, особенности реализации:

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

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

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

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

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

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

Распаковка ресурсов из файла ресурсов (ResourceManager). Я прекрасно понимаю, что реализация, которая есть в этом классе, неидеальна, но это лучше, чем отдельно лежащие ресурсы, пусть даже записанные не в общедоступном формате. А при необходимости реализацию можно дописать или переделать — было бы желание. Используется CFolder класс, основанный на реализации одной из олимпиадных задачек (задача про хакера Билла у которого накрылся жесткий диск). Он создает и удаляет дерево каталогов по названию файла, начиная с определенного пути (названия файлов должны быть относительными). Описание использования класса есть в main.cpp и мне кажется достаточно логичным.

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

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

В каркасе рисуется счетчик FPS, для его реализации были введены классы: ueFontD3D — это CD3DFont из DirectX SDK, переименован он был просто из соглашения об именовании. Под него написан класс Label, который заданным шрифтом выводит информацию на экран. Также строчку можно скрыть или сделать серой (dimmed). Им выводится счетчик FPS и некоторая дополнительная информация.

В каркасе реализовано перемещение по сцене и изменение направления взгляда (от первого лица). Используются следующие клавиши:

LEFT ARROW, A — стрейф влево.

RIGHT ARROW, D — стрейф вправо.

UP ARROW, W — вперед.

DOWN ARROW, S — назад.

C — вверх.

V — вниз.

Для изменения наклонов головы достаточно прижать правую клавишу мыши и передвигать ей — перемещение вдоль оси Y — голову вверх/вниз, перемещение вдоль оси X — голову влево/вправо. Направление вдоль оси Y инвертировано. Если вы хотите ввести возможность инвертировать мышку, то можно ввести в конфигурационный файл переменную inverty, которая будет принимать значение 1 или -1, и читать ее в программе. А в месте изменения параметра m_iFi на нее просто умножать.

Соглашения по использованию каркаса:

Используется MFC, статично подключенная к приложению. Часть определений занесена в файл STDAFX.h, а имплементаций в файл STDAFX.cpp. Они активно используются всеми классами, поэтому определены именно там. Все общие определения типов сделаны в common.h — файле с глобальными определениями, используемыми каркасом и графическими классами. Вспомогательные классы в нем ничего не хранят. Для именования функций используется система, в которой главное слово, по которому подразделяются классы функций, ставится перед остальной частью. Например, если функция относится к движку (каркасу), то она имеет префикс ueEngine*, если к событиям — ueAction* и т. д.

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

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

Следующая статья будет посвящена созданию нескольких стадий рендеринга (в ней мы сделаем главное меню). Поместим насколько экранных кнопок на экран в главном цикле рендеринга. И сделаем ландшафт (self-shadowing height-map based textured landscape with colored light map :) ). Попробуем его оптимизировать.

А сейчас о FeedBack'е: Мне очень интересно, что вы думаете обо мне и о проекте в целом, поэтому мне бы хотелось от всех вас получить письмо следующего содержания (это минимум, можно подробнее): мой литературный талант (категория L, 0-10, 0 — а может тебе чем другим заняться, 10 — неплохо), мое искусство программирования (категория P, 0-10, 0 — за такой кодинг в коляске убивать надо, 10 — неплохо ), заинтересованность проектом (категория I, 0-10, 0 — да я это даже не читал, 10 — обязательно буду следить за развитием, очень интересно). Ваш Возраст, опыт программирования на C/C++, опыт работы с графикой, предпочтительная библиотека (DX/OGL/Другое).