DirectX 8. Начинаем работу с DirectX Graphics
Шрифт:
Для эффектов отражения используют пиксельные шейдеры, буфер шаблонов и кубические карты окружения, в реализации предлагаемой мной будут использованы пиксельные шейдеры для мелких деталей и кубические карты окружения для близких крупных объектов.
В статье будут рассмотрены различные реализации, их плюсы и минусы и реализованы тени с использованием буфера шаблонов (наиболее широко применимая технология), она обладает рядом преимуществ перед всеми остальными технологиями.
Главный вывод, который можно сделать — реализация игрового приложения — это комплексная задача, требующая работы всех подразделений.
Можно сказать о некоторых способах ускорения разработки игрового проекта: например, можно позволить художникам
Следующая статья будет посвящена особенностям оптимизации Direct3D8 приложений. Жду любых комментариев, пишите — пообщаемся.
#2: Оптимизация Direct3D приложений
Начнем, как обычно, издалека. Оптимизация любого приложения, а графического тем более, это процесс не только увлекательный и волнующий, но очень и очень полезный. Затратив немного усилий в момент, когда создается приложение можно избавить себя от кучи проблем в момент, когда приложению понадобится дополнительная производительность. К тому же, обычно, если программист задумывается об оптимизации, то у него есть немного время, и он может написать не только быстро, но и красиво. Большая часть советов, приводимых здесь общедоступна, но, к сожалению, не общеизвестна. А, учитывая, что чем больше хороших игровых проектов (это особенно актуально для России), тем больше платят зарубежные издатели за права на издание, тем больше в конечном итоге объем рынка игровых приложений в России, и тем привлекательнее этот рынок для инвестиций. Замкнутый круг, от расширения (но не разрыва), которого выигрывают все стороны — повышается престиж страны и конечный заработок разработчиков. Итак, немного напыщенных фраз закончены — пора перейти к советам.
Статья не ставит своей целью разработку качественного каркаса для графического движка современного уровня, а просто призвана объяснить и по возможности обосновать тонкие места и ошибки в большинстве современных разработок.
Оптимизация трехмерного приложения может вестись по нескольким ключевым позициям:
1. Оптимизация рендеринга.
2. Оптимизация процессорной части приложения.
3. Оптимизация алгоритмов.
Такой порядок обычно считается направлением, в котором оптимизируется приложение. Программисты с энтузиазмом берутся оптимизировать графическое ядро, в нем, естественно, вязнут (оптимизация — процесс итерационный, а потому бесконечный, к тому же переходить ко второму пункту не хочется, а про третий вообще стараются забыть). Но это обусловлено не отдачей от каждой конкретной части, а скорее нежеланием программистов думать о сложном и высоком, обращать внимание на мелкие детали и тщательно следить за качеством кода. Хотя математики давно знают, что никакое улучшение аппаратуры не может сравниться с оптимизацией (улучшением существующих, разработкой новых) алгоритмов. Оптимизация процессорной части важна, поскольку большинство приложений ограничиваются процессором и выигрыш в скорости расчета процессором специфических функций (начиная от поиска пути и заканчивая графикой) напрямую увеличивает производительность приложения. Графическая подсистема постоянно улучшается, но пределы производительности практически достигнуты и скоро будет произведена замена существующих способов рисования сцены новыми. Поэтому оптимизация графического ядра, это вещь важная, но не стоит уделять ей внимания больше, чем она того заслуживает (это относится только к Direct3D программистам).
Рассмотрим их по порядку, причем начнем с конца.
Мы интересуемся только графической частью приложения, поэтому здесь главное правило,
Если можно что-то сделать вне цикла — делай это вне цикла.
Если можешь создать таблицу с параметрами и ее использовать — создай и используй.
Если можешь что-то не считать — не считай это.
А главное, если есть возможность что-то ускорить, то эту возможность нельзя упускать.
Создание таблицы синусов и косинусов для быстрого преобразования Фурье (задачи распознавания образов и шифрования), вместо использования функций позволяет увеличить скорость расчета на порядки.
Если можно обновлять информацию не для каждого фрейма, а хотя бы для каждого второго, то рост производительности в этой части будет на 100%.
Если используются функции (для сглаживания пути или формирования волн на воде), то создание таблиц значений и интерполяция между ними может дать значительный прирост. Если вершина не попала на экран ее можно смело не рисовать (здесь нужна аккуратность — быстрый алгоритм отсечения и невидимые полигоны на сцене предпочтительнее, чем ни одного лишнего и чистый qsort для сортировки). С сортировкой вообще нужно быть осторожным — мы не можем предсказать разброс значений в массиве, а значит, не можем предсказать время выполнения сортировки методами типа "разделяй и властвуй" (qsort), поэтому возможен предварительный разброс значений и последующая быстрая сортировка, или сортировка маленьких массивов методами типа "Пузырек" (все знают как плохо работает qsort в случае обратной упорядоченности массива или массива с большим количеством повторяющихся значений).
Интересно, что для этой части предлагаются только методы оптимизации выполнения на уровне аппаратуры, но забывать про оптимизацию параллельности выполнения тоже не стоит. Мы имеет не один процессор, а два: CPU и GPU. В GPU работа хорошо распараллеливается, и мы за ней не следим, но есть ряд операций, выполнение которых заставляет процессор простаивать, поэтому ТАКИЕ операции нужно стараться уменьшать в количестве и следовать рекомендациям, приведенным в части статьи, посвященной непосредственно примерам. Кстати в этом процессе может помочь Statistical Driver от NVIDIA, но его нужно получать непосредственно от NVIDIA, а для этого необходимо стать регистрированным разработчиком на developer.nvidia.com.
Итак, самое главное
1 удаляем непосредственное преобразование типа float к типу long или int.
Каждый раз, когда вы пишите
Вместо:
Пишем:
Либо используем недокументированный переключатель оптимизации /QIfist чтобы избежать вызовов __ftol.
2 Не используем fsqrt — 79 циклов это слишком долго.
Достаточно качественная реализация приведена в NVToolkit (MUST HAVE для всех кто программирует графику, но не хочет лезть в математику). Полный архив NVToolkit можно скачать сКогда я ее выкачивал он лежал по адресу http://developer.nvidia.com/docs/IO/1208/ATT/NVTK_no_libs.zip.