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

5. Стараемся использовать как можно меньшее количество буферов вершин. Смена буфера очень "тяжелая" операция и дорого нам стоит. Поэтому

6. Загружаем модели в сцене в минимальное количество буферов.

7. Используем минимальное количество разновидностей FVF, если возможно — то один общий FVF (Максимального размера).

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

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

10. Если вам необходимо восстанавливать состояние буфера, храните две копии.

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

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

13. Разделяйте буфер на потоки, если вам необходимо обновлять только часть информации, и.

14. Всегда обновляйте данные подряд. (процессор передает данные по 32 байта, 64 байта — Pentium IV).

15. Старайтесь использовать кэш вершин видеокарты. Если данные в кэше они не пересчитываются (экономится T&L шаг).

16. Всегда старайтесь использовать FVF кратный 32 байтам.

17. Не используйте примитивы высокого уровня — NVIDIA признает, что это рекламный ход и рекомендует подождать карт смещения (Displacement maps в DirectX9).

18. Производите грубое отсечение частей, не попадающих на экран, и не посылайте их в видеокарту (CPU или ProcessVertices).

19. Рисуйте за раз не менее, чем по 200+ вершин. См. иллюстрации в конце статьи.

20. Всегда используйте индексированный рендеринг. Это единственный случай, когда используется кэширование в кэш вершин видеокарты.

21. Отдавайте предпочтение Indexed Strips, после этого Indexed Lists, после этого Indexed Fans. Грамотное использование Indexed Strips может дать большой прирост скорости (кэш + отсутствие копирования лишней информации). Размер кэша — 18 вершин для GeForce 3/4 Ti, 10 — для GeForce 1/2/4 MX.

22. Для многопроходного рендеринга используйте первый Z-only проход — это экономит расчет следующих проходов.

23. Используйте уровни детализации для всего, чего только возможно — для текстур (для удаленных объектов можно не накладывать Detailed Map), для объектов в части геометрии (количество полигонов) и скиннинга (уменьшаем количество костей (bones) при удалении объекта), отключаем дальние источники освещения, отключаем туман для объектов, на которых он не сказывается.

24. Всегда отдавайте предпочтение большему разрешению перед FSAA (Full Scene Antialiasing) — это бесплатный антиалиазинг.

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

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

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

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

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

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

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

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

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