Сергей Ваткин - DirectX 8. Начинаем работу с DirectX Graphics

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

27. Не используйте пару функций BeginScene(), EndScene() более одного раза на кадр.

Рис 1. Производительность видеокарты в зависимости от размера передаваемого за раз фрагмента.

Рис 2. Пропускная способность AGP шины в зависимости от размера FVF и фрагмента.

На этом мы закончим общую часть, если вам стало интересно — прекрасно, значит я достиг своей цели. Дополнительная информация может быть найдена на сайте http://developer.nvidia.com/

Следующая статья будет посвящена созданию рабочего каркаса игрового графического движка.

Пишите — мне интересно Ваше мнение, Ваши предложения и Ваши комментарии. В споре рождается истина и разбиваются головы.

Создание каркаса графического приложения — это занятие достаточно простое с технической точки зрения, но очень (ну может не очень, но все равно) сложное с архитектурной точки зрения. Фактически, не было ни одного случая, чтобы первый каркас любого программиста в его жизни не был забракован по той или иной причине. Кроме того, причиной, по которой здесь рассмотрен каркас в числе первых элементов, можно считать, что создание каркаса — это отличный способ узнать тонкости как 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) во всех критических местах приложения. То есть любая ошибка ведет к корректному завершению программы с выдающимся после завершения работы приложения сообщением.