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

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

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

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


multithreading real-time game-loop
person Klems    schedule 27.07.2011    source источник
comment
если не соблюдать правильный временной шаг, вы получите физику, которая зависит от частоты кадров.   -  person Dan D.    schedule 27.07.2011

Ответы (2)


arrow_upward
0
arrow_downward

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

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

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

person karmington    schedule 12.08.2011

arrow_upward
0
arrow_downward

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

НАСКОЛЬКО МНЕ ИЗВЕСТНО,

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

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

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

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

person eonil    schedule 09.05.2014