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

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

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

Изменено: 18.01.2013

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

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

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





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

Приложение А. Схема примерного движка



Схема примерного движка
Рисунок 13. Схема примерного движка




Приложение Б. Схема связи движка и систем



Схема связи движка и систем
Рисунок 14. Схема связи движка и систем




Приложение В. Модель наблюдателя



Модель наблюдателя подробно описана в книге "Приемы объектно-ориентированного проектирования. Паттерны проектирования". Авторы Э. Гамма, Р. Хелм, Р. Джонсон, Дж. Влиссидес. Издательство "Питер" (серия "Библиотека программиста"), 2007 г.

Основной идеей данной модели является - любые элементы, заинтересованные в данных или изменениях состояний в других элементах, не обременяются задачей опроса элементов время от времени, чтобы посмотреть состоялись ли в них какие-либо изменения. Модель определяет субъект и наблюдателя, которые используются для уведомления об изменениях. Это работает так - наблюдатель наблюдает за субъектом на предмет каких-либо изменений. Контроллер изменений выступает в роли посредника между этими двумя данными компонентами. Следующая схема иллюстрирует данную связь:

Модель наблюдателя (observer design pattern)
Рисунок 15. Модель наблюдателя (observer design pattern)


Опишем поток событий:

1) Наблюдатель регистрируется в субъекте, за изменениями которого он планирует вести наблюдение при помощи контроллера изменений.

2) Контроллер изменений по сути является наблюдателем. Вместо регистрации наблюдателя в субъекте, он сам регистрируется в субъекте и ведёт свой собственный список, какой наблюдатели зарегистрированы в каких субъектах.

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

4) Когда субъект осуществляет изменение своих данных или состояния - он уведомляет наблюдателя посредством механизма обратного вызова и передает информацию о типах, которые были изменены.

5) Контроллер изменений выстраивает в очередь уведомления об изменениях и ждёт сигнала для их раздачи.

6) Во время раздачи контроллер изменений обращается к реальным наблюдателям.

7) Наблюдатели запрашивают субъект в отношении измененных данных или состояния (или получают данные из сообщений).

8) Когда наблюдатель более не заинтересован в субъекте (или он уничтожился), он снимает свою регистрацию из субъекта посредством контроллера изменений.



Приложение Г. Советы по реализации задач



Хотя распределение задач может быть реализовано различными путями, лучше всего поддерживать количество рабочих потоков равным количеству доступных логических процессоров платформы. Избегайте привязки задач к определенному потоку, поскольку задачи из различных систем не будут завершаться в одно время, что может привести к дисбалансу нагрузки между рабочими потоками - а это сокращает уровень параллелизма. Также стоит изучить библиотеки управления задачами, например библиотеку Intel Threading Building Blocks, которая может упростить этот процесс.

В менеджере задач возможно сделать некоторые оптимизации, чтобы центральный процессор качественно выполнял различные полученные задачи.
Например такие оптимизации:

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

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



Список рисунков



Рисунок 1. Выполнение в свободном пошаговом режиме
Рисунок 2. Выполнение в жестком пошаговом режиме
Рисунок 3. Высокоуровневая архитектура движка
Рисунок 4. Основной цикл игры
Рисунок 5. Расширение универсальной сцены и объекта
Рисунок 6. Пример пула потоков в менеджере задач
Рисунок 7. Уведомление о внутренних изменениях UObject
Рисунок 8. Пример работы менеджера службы
Рисунок 9. Системные компоненты
Рисунок 10. Инициализация менеджеров движка и системы
Рисунок 11. Инициализация универсальной сцены и объекта
Рисунок 12. Задачи и менеджер задач
Рисунок 13. Схема примерного движка
Рисунок 14. Схема связи движка и систем
Рисунок 15. Модель наблюдателя (observer design pattern)



Литература



Gamma, E., Helm, R., Johnson, R., Vlissides, J., (1995-2000). Design Patterns: Elements of Reusable
Object-Oriented Software. USA: Addison-Wesley.

Русский перевод:
Приемы объектно-ориентированного проектирования. Паттерны проектирования. Э. Гамма, Р. Хелм, Р. Джонсон, Дж. Влиссидес.
Издательство: Питер (серия "Библиотека программиста"), 2007 г.


Intel Threading Building Blocks (TBB):
http://threadingbuildingblocks.org

Оригинал данной статьи (на английском языке)


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