DirectX 8. Начинаем работу с DirectX Graphics - [17]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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