Некоторые вопросы, касающиеся игрового цикла, тиков и программирования в реальном времени

Question

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

• Я запускаю процедуру рендеринга в потоке.Это хорошая идея?Обычно процедура рендеринга довольно медленная и не должна замедлять процедуру обновления мира (тик), что гораздо важнее.Поэтому я думаю, что использование потока здесь является хорошей идеей (за исключением сложностей, связанных с использованием потока).
• В процедуре обновления мира я обновляю список объектов с текущим временем.Затем каждый объект может рассчитать свой собственный deltaTime, соответствующий последнему времени их обновления.Это отличается от обычного цикла обновления, который обновляет каждый объект в списке с тем же deltaTime.Это казалось уместным из-за многопоточного рендеринга.Это хорошая идея?Должен ли я использовать второй метод вместо?Если да, то нужен ли многопоточный рендеринг?Если да, нужно ли добавлять максимальное значение deltaTime?
• В общем, стоит ли иметь максимальное значение deltaTime?

Спасибо за ваше время!

Answer 1

Хотя этому вопросу несколько лет…

AFAIK,

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

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

Если вы можете хранить отдельные неизменяемые данные для рендеринга, вы можете получить некоторую выгоду от рендеринга в отдельном потоке. Но в остальном я не рекомендую это.

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

Answer 2

1. Это хорошая идея? Отдельные потоки - довольно продвинутые вещи, я не вижу причин для начала многопоточности. Все мобильные игры, над которыми я работал до сих пор, не нуждались в нескольких потоках, даже если они «в реальном времени». В хардкорных ПК и консольных играх многопоточность действительно начинает играть роль. Вот ссылка на недавний разговор на эту тему, если вы заинтересованы: http://archive.assembly.org/2011/seminars/adventures-in-multithreaded-gameplay-coding.

2. Похоже, что это может вызвать некоторые странные вещи, если физика не обрабатывается за один раз. Не уверен насчет этого. Сопоставление объекта, который уже был обновлен до другой позиции, с объектом, который приходит в другой раз, например, исправление такого рода ситуации может стать проблематичным? Быстро движущиеся коллизии могут нуждаться в подразделении, поэтому, возможно, у вас есть отдельный поток обновлений, но почему бы не рассчитать их все одновременно?

3. «Переменный временной шаг» и «Фиксированный временной шаг» - это параметры, доступные для рендеринга. Большинство игр в настоящее время, похоже, выбирают фиксированный временной интервал 30 кадров в секунду. Рендеринг должен быть ограничен, поэтому не нужно его догонять. Одна проблема с переменным временным шагом заключается в том, что вы вынуждены передавать deltaTime во все зависимые от времени области. Фиксированный временной шаг удобен, поскольку вы можете предположить, что вы работаете со скоростью, например, 30 кадров в секунду, и использовать это значение везде. Насколько я знаю, на данный момент это предпочтительный метод.