Процесс общения в реальном времени в разработке игр

Question

Если вы создаете игровую архитектуру, которая разделяет компоненты системы (IE, рендеринг, физику, логику, ввод данных, скрипты и т. Д.) На разные потоки, как вы обрабатываете случаи, когда необходимо общение в реальном времени?

Например, если сценарий хочет нарисовать прямоугольник на экране, он в идеале сделал бы это, когда компонент рендеринга выдает событие «FrameDrawn», чтобы прямоугольник отображался в верхней части экрана в конце каждый кадр рисует. Как это возможно, если компонент сценариев и компонент рендеринга находятся в разных потоках друг от друга?

Answer 1

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

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

Answer 2

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

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

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

Answer 3

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