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

Нельзя допускать забивание памяти видеокарты и системной памяти, для этого можно использовать программы типа NUMEGA Bounds Checker, или встроенные в API средства контроля, они будут рассмотрены отдельно.

12. Контролировать состояние сцены.

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

13. Пройти отладку в VTune.

Отладка в VTune может добавить до 300 % производительности, поэтому не стоит ей пренебрегать.

14. Должен знать свои "тонкие" места.

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

15. Экранные меню.

Необходимо реализовать быстро и точно, для этого достаточно пользоваться рекомендациями, даваемыми, например, Ричардом Хадди (Richard Huddy, NVidia) — как он говорит: "Вам необходимо поверить, во все те плохие вещи, которые я вам говорю". Следующая статья будет полностью посвящена оптимизации Direct3D8 приложений, а после этого будет приведен класс, реализующий эти рекомендации применительно к экранным меню.

16. Остановка сцены (без остановки рендеринга).

Мы должны иметь возможность поставить паузу, не останавливая цикл рендеринга, этого требуют фактически все экранные элементы (экран загрузки, сохранения, пауза, инвентарь и т. д.). Нам нужно оставить обновление сцены в некотором необходимом объеме, но остановить рендеринг, в оконном режиме мы должны восстанавливать состояние экрана, рисовать курсор. Поэтому, это не такое простое действие, чтобы не останавливать на нем внимание.

17. Игровой интерфейс.

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

18. Ландшафт.

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

19. Объекты.

Главное в реализации объектов — это сортировка и обрезка. Мы должны сортировать объекты по дальности, по текстуре и определять видимые и невидимые объекты. Сортировка по дальности позволяет использовать уровни детализации (отключать освещение объекта, тень от объекта и т. д.), правильно рисовать прозрачные объекты, сортировка по текстуре сильно увеличивает производительность, невидимые объекты самые быстрые (потому что мы их не рисуем). Кроме того, необходимо контролировать загрузку объектов и текстур (не допускать излишнего копирования информации). Реализацию такого вида объектов мы тоже подробно рассмотрим.

20. Модели (со скелетной анимацией).

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

21. Окружение.

 a. Туман

 b. Слоеный туман

 c. Небо

 d. Облака

 e. Погодные эффекты

 f. Вода

Я думаю, что все согласны, что эти пункты нуждаются в рассмотрении, но достаточно мелкие, для того чтобы им посвящать отдельные статьи, поэтому, мы рассмотрим их все вместе.

22. Солнце, луна, звезды.

Возможны различные реализации, в настоящий момент в основном, солнце и луна — это спрайты с засветкой экрана, а звезды - обыкновенная точечная система. Точечным системам посвящена следующая глава, поэтому реализацию солнца, луны и звезд мы будем рассматривать в статье посвященной точечным эффектам.

23. Точечные эффекты.

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

24. Трава.

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

25. Эффекты отражения.

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

26. Тени.

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

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

Можно сказать о некоторых способах ускорения разработки игрового проекта: например, можно позволить художникам и дизайнерам разрабатывать трехмерные модели в программах для трехмерного моделирования (например, Discreet 3D Studio Max), а когда игровой фрейм с набором редакторов будет реализован, написать конвертор в собственный формат и релиз выпускать с собственным форматом.

Следующая статья будет посвящена особенностям оптимизации Direct3D8 приложений. Жду любых комментариев, пишите — пообщаемся.

Автор: Константин "Dreaddog" ПоздняковАвтор: Константин "DreadDog" Поздняков

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

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

Оптимизация трехмерного приложения может вестись по нескольким ключевым позициям:

1. Оптимизация рендеринга.

2. Оптимизация процессорной части приложения.

3. Оптимизация алгоритмов.

Такой порядок обычно считается направлением, в котором оптимизируется приложение. Программисты с энтузиазмом берутся оптимизировать графическое ядро, в нем, естественно, вязнут (оптимизация — процесс итерационный, а потому бесконечный, к тому же переходить ко второму пункту не хочется, а про третий вообще стараются забыть). Но это обусловлено не отдачей от каждой конкретной части, а скорее нежеланием программистов думать о сложном и высоком, обращать внимание на мелкие детали и тщательно следить за качеством кода. Хотя математики давно знают, что никакое улучшение аппаратуры не может сравниться с оптимизацией (улучшением существующих, разработкой новых) алгоритмов. Оптимизация процессорной части важна, поскольку большинство приложений ограничиваются процессором и выигрыш в скорости расчета процессором специфических функций (начиная от поиска пути и заканчивая графикой) напрямую увеличивает производительность приложения. Графическая подсистема постоянно улучшается, но пределы производительности практически достигнуты и скоро будет произведена замена существующих способов рисования сцены новыми. Поэтому оптимизация графического ядра, это вещь важная, но не стоит уделять ей внимания больше, чем она того заслуживает (это относится только к Direct3D программистам).