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

#1: Введение

Константин Поздняков заканчивает Кемеровский Государственный Университет на кафедре ЮНЕСКО по НИТ. Его диплом достаточно тесно связан с трехмерной графикой и Direct3D в частности. Разрабатывает свой собственный движок. Недавно получил статус MCP (Microsoft Certified Professional) по Visual C++ 6 Desktop. Разработкой игр занимается очень серьезно, планирует связать свою карьеру именно с игровым трехмерным программированием. 

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

Современный игровой движок должен уметь:

1. Рисовать интерфейс.

2. Рисовать курсор.

3. Рисовать сцену.

Это те пункты, которые касаются графической части, а кроме того:

4. Использовать файл настроек для инициализации.

5. Проводить проверку состояния устройства и выдавать ошибку при их несоблюдении.

6. Современный графический движок не должен в реальном времени изменять параметры устройства или режим работы (оконный/полноэкранный).

7. Уметь загружать файлы из сжатого файла, причем делать это асинхронно.

8. Вести файл протокола.

9. Уметь в реальном времени изменять параметры, не требующие изменения устройства.

10. Контролировать ошибки и правильно их обходить.

11. Корректно чистить после себя при загрузке дополнительной информации.

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

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

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

Технические возможности движка:

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

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

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

18. Ландшафт.

19. Объекты.

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

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

 a. Туман

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

 c. Небо

 d. Облака

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

 f. Вода

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

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

23. Трава.

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

25. Тени.

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

Это одна из самых главных частей игрового проекта, именно она делает из программы демонстрирующей графические возможности игру. Кроме того, единственная возможность движка позволяет отображать Main Menu в проекте, экран сохранения, экран восстановления, экран загрузки карты, игровой интерфейс — т. е. областей применения масса. Обычно для интерфейса используют трансформированные координаты с наложенной текстурой. Эта часть отвечает за презентабельность проекта, ведь именно ее увидит пользователь в первую очередь, за нее в основном отвечает команда художников и дизайнер.

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

Сердце любого графического движка — его сцена, набор объектов, взаимодействующих с пользователем. Обычно, сложнее подобрать реалистичные параметры сцены, а не реализовать требуемые возможности. Движок может быть мощным по скорости прорисовки, с качественным выходным изображением, но плохая команда трехмерных художников, команда сопровождения и недостаточная проработка параметров реалистичности может свести на нет все усилия программистов. При этом рисование сцены должно быть масштабируемым, то есть добавить треугольников в модель персонажа достаточно просто, но переделать модель рисования неба, эффектов и теней может быть затруднительно. Пример — вода в Mamp;M IX, по-моему, если говорить об убогости реализации LithTech + Mamp;M IX это сладкая парочка, там, где движок не глючит — там недоработки художников и дизайнеров, а там где у них это все более-менее прилично, вылезает ущербность реализации LithTech. Я думаю назвать конкретные места нет никакой необходимости, все прекрасно их видели.

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

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

Нет необходимости в изменении устройства из приложения, мы можем упростить эту часть, и направить усилия на другие более важные части. Пользователи привыкли, и могут безропотно выйти из программы, чтобы сменить режим с оконного на полноэкранный или изменить глубины цвета (все равно почти вся информация загружается заново). Это упрощение и скорее упрощает жизнь программистам. Вообще говоря, команда разработчиков единое целое, но у каждой части свои задачи (все помнят модель разработки Microsoft Solution Framework), поэтому ни одна из частей не должна идти на поводу у другой, но в тоже время должны вырабатываться разумные компромиссы (если дизайнером нужно рисовать по 200 KPolys за фрейм при 60 Hz на GeForce 2, то программисты должны обеспечить такую производительность, но если программистам нужно рисовать по 200+ за раз, то модели должны быть сделаны с этим расчетом).

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

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

Скорее приведен как пример правильного поведения устройства. Движок должен предоставлять широкий набор параметров для изменения, касающихся как внешнего вида, так и производительности. Игровые проекты двигают рынок аппаратуры, а не наоборот. Мы должны предоставить человеку веский довод для улучшения аппаратуры, и слабая аппаратура это не повод лишать себя и "смежников" дополнительного заработка. Игрок, он как девушка — нет игроков, которые не играют, есть игроки, которые не играют в твою игру (это твоя вина).

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

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

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

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

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

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

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

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

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

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

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

 a. Туман

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

 c. Небо

 d. Облака

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

 f. Вода

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

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

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

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

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

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

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

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

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