Бесплатная реклама

Автор: Джефф Эндрюс (Jeff Andrews)

Опубликовано: 18.01.2013

Изменено: 18.01.2013

Постоянная ссылка

Комментарии [0]

Проектирование архитектуры параллельного игрового движка





Страницы: 1 2 3 4

6. Связываем всё вместе



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

6.1. Инициализация


Работа движка начинается с инициализации менеджеров и фреймворка.

• Фреймворк обращается к загрузчику сцен для загрузки сцены.

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

• Менеджер платформы загружает соответствующие модули и передает их менеджеру интерфейсов, затем вызывает их для создания новой системы.

• Модуль возвращает загрузчику указатель на систему, которая содержит системный интерфейс.

• Системный модуль также регистрирует любые службы, предоставляемые им в менеджере служб.

Системные компоненты
Рисунок 10. Инициализация менеджеров движка и системы


6.2. Загрузка сцены


Управление возвращается загрузчику, который загружает сцену.

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

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

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

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

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

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

Системные компоненты
Рисунок 11. Инициализация универсальной сцены и объекта


6.3. Игровой цикл


Главный игровой цикл начинает работу (для наглядного представления смотрите рисунок 4 "Основной цикл игры").

• Менеджер платформы вызывается для обработки всех оконных сообщений и (или) других платформенно-специфичных вещей, необходимых для работы на текущей платформе.

• Затем исполнение передается планировщику, который ждет окончания такта для продолжения работы.

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

• Теперь планировщик определяет, какие задачи будут завершены в текущем такте, и ждет их завершения.

• Для жесткого пошагового режима планировщик выдаёт менеджеру все задачи и ждет их выполнения в каждом такте.

6.3.1. Исполнение задач



Далее управление передаётся менеджеру задач.

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

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

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

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

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

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

Задачи и менеджер задач
Рисунок 12. Задачи и менеджер задач


6.3.2. Раздача изменений



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

• Менеджер состояний обращается к каждому из своих контроллеров изменений для распространения накопленных изменений. Это осуществляется посредством прогона каждого изменения субъекта и проверки какой наблюдатель отслеживает данный субъект.

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

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

6.3.3. Проверка выполнения и выход



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


7. Заключительные соображения



Ключевым моментом всего вышесказанного является раздел 2 "Режим параллельного выполнения". Проектирование систем для функциональной декомпозиции в сочетании с декомпозицией данных позволит добиться значительного распараллеливания, а также обеспечит масштабируемость и поддержку будущих процессоров с ещё большим количеством ядер. Не забывайте использовать менеджеры состояний вместе с механизмом сообщений, для того чтобы все данные были синхронизированы с минимально возможными издержками.

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

Управление задачами играет важную роль в правильном регулировании нагрузки. Следуя советам из приложения Г, вы сможете создать эффективный менеджер задач для своего движка.

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


8. Об авторе



Джефф Эндрюс (Jeff Andrews) занимает должность программного инженера в компании Intel. Он работает над оптимизацией кода для разработчиков программ и в настоящее время сосредоточен на компьютерных играх. Он также исследует различные технологии для улучшения производительности или для добавления новых фич в игры. Джефф Эндрюс являлся также ведущим архитектором демонстрационного фреймворка "Smoke".


Страницы: 1 2 3 4