Как сохранить данные моего мира в многопоточном игровом движке?

Question

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

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

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

У меня есть компоненты для передачи этих данных, только проблема его генерирует.

До сих пор я думал о двух различных подходах:

• скопировать всю структуру для каждого обновления - очень простой, но, возможно, времени и intensife памяти (у меня нет опыта работы с большими двигателями - бы это может быть жизнеспособной?)
• Отслеживайте, какие части сцены изменены путем маркировки узлов сцены с некоторыми флагами, а затем только копирование через измененных частей

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

Есть ли какой-то общий ответ, какой подход будет быстрее в типичной игровой среде?

Answer 1

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

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

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