DirectX 8. Начинаем работу с DirectX Graphics
Шрифт:
Эта статья ставит своей целью описать (по возможности наиболее полно) возможности игрового движка современного уровня. Я попытался классифицировать потребности в реализации, требуемой от программиста. Здесь не обсуждаются подробно реализации каждого конкретного элемента. Этому будут посвящены следующие статьи, а не этот обзор.
Современный игровой движок должен уметь:
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 в проекте, экран сохранения, экран восстановления, экран загрузки карты, игровой интерфейс — т. е. областей применения масса. Обычно для интерфейса используют трансформированные координаты с наложенной текстурой. Эта часть отвечает за презентабельность проекта, ведь именно ее увидит пользователь в первую очередь, за нее в основном отвечает команда художников и дизайнер.
Курсор — это мощная информативная система и при умелом использовании он может из тупого указателя превратится в незаменимый инструмент, облегчающий пользователю процесс взаимодействия с проектом. От программиста требуется поддержка анимированного курсора, независимость скорости передвижения от частоты кадров (передвижение не должно становится дерганным при падении частоты кадров), а также смены режима курсора, кроме того, курсор должен вести себя одинаково во всех режимах работы приложения. Плохо нарисованный неактивный курсор ухудшает внешний вид проекта и создает впечатления о халтуре, поэтому этой частью необходимо заниматься серьезно. Практически, вся работа ложится на плечи дизайнера (программистам нельзя позволять заниматься проектированием приложения, у них много другой важной работы, к тому же у них с дизайнером противоположная задача — программисты хотят сделать как можно проще (пусть даже хотят подсознательно, сами того не осознавая), а у дизайнера главное целостность концепции и внешнего вида проекта).
Сердце любого
Здесь все просто, все изменяемые параметры должны применяться при следующей загрузке, и тогда без применения инициализационного файла не обойтись. Инициализационный файл не погибает при переустановке системы, его можно легко перенести с машины на машину. Сложностей в его реализации нет, там все просто. Либо ждите, когда будет выложена моя статья с реализацией, либо реализуйте сами, либо обращайтесь прямо ко мне, я вышлю.
В текстовом инициализационном файле (редактируемом как программой, так и вручную) могут быть ошибки, поэтому мы должны контролировать состояние файла при загрузке и хранить твердую копию (жестко закрепленные параметры, хранящиеся в программе). Реализуется в любом движке и просто требует аккуратности.
Нет необходимости в изменении устройства из приложения, мы можем упростить эту часть, и направить усилия на другие более важные части. Пользователи привыкли, и могут безропотно выйти из программы, чтобы сменить режим с оконного на полноэкранный или изменить глубины цвета (все равно почти вся информация загружается заново). Это упрощение и скорее упрощает жизнь программистам. Вообще говоря, команда разработчиков единое целое, но у каждой части свои задачи (все помнят модель разработки Microsoft Solution Framework), поэтому ни одна из частей не должна идти на поводу у другой, но в тоже время должны вырабатываться разумные компромиссы (если дизайнером нужно рисовать по 200 KPolys за фрейм при 60 Hz на GeForce 2, то программисты должны обеспечить такую производительность, но если программистам нужно рисовать по 200+ за раз, то модели должны быть сделаны с этим расчетом).
В основном, это культура программирования, нет необходимости пользователям видеть структуру организации приложения (кроме того, при шифровании усложняется жизнь производителей контрафактной продукции и часто это требование издателя). Асинхронность необходима для одновременной работы с несколькими файлами (фоновое проигрывание музыки и загрузка сцены).