Когда я должен использовать фиксированный или переменный шаг по времени?

256

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

Переменный шаг по времени

Физическим обновлениям передается аргумент «истекшее время с момента последнего обновления» и, следовательно, они зависят от частоты кадров. Это может означать выполнение расчетов как position += distancePerSecond * timeElapsed.

Плюсы : гладкие, легче
кодируемые Минусы : недетерминированные, непредсказуемые на очень маленьких или больших шагах

Пример deWiTTERS :

while( game_is_running ) {
    prev_frame_tick = curr_frame_tick;
    curr_frame_tick = GetTickCount();
    update( curr_frame_tick - prev_frame_tick );
    render();
}

Фиксированный шаг по времени

Обновления могут даже не принимать «истекшее время», так как они предполагают, что каждое обновление имеет фиксированный период времени. Расчеты могут быть сделаны как position += distancePerUpdate. Пример включает в себя интерполяцию во время рендеринга.

Плюсы : предсказуемый, детерминированный (проще для синхронизации по сети?), Более четкий код расчета.
Минусы : не синхронизируется для мониторинга v-синхронизации (вызывает дрожание графики, если вы не интерполируете), ограниченная максимальная частота кадров (если вы не интерполируете), трудно работать в рамках, которые предположить переменные временные шаги (например, Pyglet или Flixel )

Пример deWiTTERS :

while( game_is_running ) {
    while( GetTickCount() > next_game_tick ) {
        update();
        next_game_tick += SKIP_TICKS;
    }
    interpolation = float( GetTickCount() + SKIP_TICKS - next_game_tick )
                    / float( SKIP_TICKS );
    render( interpolation );
}

Некоторые ресурсы

Ник Сонневелд
источник
6
Используйте переменные временные шаги для своей игры и фиксированные шаги для физики
Даниэль Литтл
7
Я бы не сказал, что переменный шаг по времени проще кодировать именно потому, что с фиксированным шагом по времени вам «не нужно везде путать все вычисления с переменной timeElapsed». Не то чтобы это было так сложно, но я бы не стал добавлять «проще в программировании» как профессионал.
пекин
Правда, я думаю, что я имел в виду, что вам не нужно интерполировать переменные временные шаги.
Ник Сонневелд
@pek Я согласен с тобой. Переменный временной шаг имеет более простой кодированный игровой цикл, но вам нужно больше кодировать в своих сущностях, которые имеют дело с этой изменчивостью, чтобы «ускорить ее». Фиксированный временной шаг имеет более сложный для кодирования игровой цикл (потому что вы должны точно компенсировать дисперсии аппроксимации по времени и пересчитать, какую дополнительную задержку добавить или сколько обновлений пропустить, чтобы сохранить ее фиксированной), но имеет более простое кодирование для объектов, которые будут всегда приходится иметь дело с одним и тем же интервалом времени. В целом ни одно из подходов не является проще, чем другое.
Шиван Дракон
Вы можете проверить их с помощью этого инструмента: s3.amazonaws.com/picobots/assets/unity/jerky-motion/… хотя это не дает вам представления о том, как они будут выглядеть при различной частоте кадров
Buddy

Ответы:

134

Есть два вопроса, связанных с этим вопросом.

  • Должна ли физическая скорость шага быть привязана к частоте кадров?
  • Должна ли физика идти с постоянными дельтами?

В «Исправлении вашего временного шага» Глен Филдер говорит «Освободи физику». Это означает, что ваша частота обновления физики не должна быть привязана к вашей частоте кадров.

Например, если частота кадров дисплея составляет 50 кадров в секунду, а симуляция рассчитана на работу со скоростью 100 кадров в секунду, то нам необходимо выполнять два шага по физике при каждом обновлении дисплея, чтобы синхронизировать физику.

В рекомендациях Эрин Катто для Box2D он также выступает за это.

Так что не привязывайте временной шаг к вашей частоте кадров (если вам действительно не нужно).

Должна ли скорость физического шага быть привязана к вашей частоте кадров? Нет .


Мысли Эрин о фиксированном шаге и переменном шаге:

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

Мысли Глена о фиксированном и переменном степпинге:

Исправьте свой временной шаг или взорвитесь

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

Должна ли физика идти с постоянными дельтами? Да.


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

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

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

deft_code
источник
1
Я играл в «The Floor is Jelly» до и после обновления моей машины, и это было глупо: это было не то же самое, потому что физика действительно вызывалась из игрового цикла (и так привязана к частоте кадров), а не из таймер Моя старая машина была очень плохой, поэтому она постоянно переключалась между медленным и слишком быстрым движением, и это имело большое влияние на игровой процесс. Теперь это просто очень быстрое движение. В любом случае, эта игра - прекрасный пример того, насколько проблемной может быть эта проблема (хотя игра все еще симпатичная).
MasterMastic
55

Я думаю, что есть действительно 3 варианта, но вы перечисляете их как только 2:

Опция 1

Ничего не делать. Попытка обновления и рендеринга с определенным интервалом, например, 60 раз в секунду. Если он отстает, пусть это и не волнуйтесь. Игры замедлятся до резких замедлений, если процессор не поспевает за вашей игрой. Эта опция не будет работать вообще для многопользовательских игр в реальном времени, но подходит для однопользовательских игр и успешно используется во многих играх.

Вариант 2

Используйте дельта-время между каждым обновлением, чтобы варьировать движение объектов. Прекрасно в теории, особенно если в вашей игре ничего не ускоряется и не замедляется, а просто движется с постоянной скоростью. На практике многие разработчики плохо это реализуют, и это может привести к непоследовательному обнаружению столкновений и физике. Кажется, некоторые разработчики считают, что этот метод проще, чем есть. Если вы хотите использовать эту опцию, вам нужно значительно улучшить свою игру и вывести некоторые математические и алгоритмы с большим оружием, например, используя физический интегратор Verlet (а не стандартный Euler, который используют большинство людей) и используя лучи для обнаружения столкновений. а не простые проверки расстояния Пифагора. Я задал вопрос об этом в Stack Overflow некоторое время назад и получил несколько отличных ответов:

https://stackoverflow.com/questions/153507/calculate-the-position-of-an-accelerating-body-after-a-certain-time

Вариант 3

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

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

Iain
источник
Относительно варианта 2: я не уверен, что лучевая трансляция когда-либо может быть быстрее, чем проверки расстояния Пифагора, за исключением случаев, когда вы используете очень грубую силу при применении пифагора, но лучевая передача также будет очень дорогой, если вы не добавите широкофазную фазу.
Кадж
4
Если вы используете Verlet с неравными временными шагами, вы выбрасываете ребенка с водой. Причина, по которой Verlet так же стабилен, как и она, заключается в том, что ошибки устраняются в последующих временных шагах. Если временные шаги не равны, этого не произойдет, и вы снова взорвётесь на физике земли.
drxzcl
Вариант 3 - звучит как описание подхода XNA Джоэла Мартинеса.
topright
1
Это действительно хороший ответ. Все три варианта имеют свое место, и важно понимать, когда они уместны.
Адам Нейлор
Во всех ММО, над которыми я работал (EQ, Landmark / EQNext [cry], PS2 [кратко] и ESO), мы всегда использовали переменное время кадра. Я никогда не был участником этого конкретного решения, просто появился после факта и использовал то, что решили другие.
Марк Сторер
25

Мне действительно нравится, как XNA Framework реализует фиксированный временной шаг. Если заданный вызов отрисовки занимает слишком много времени, он будет вызывать update несколько раз, пока не «догонит». Шон Харгривз описывает это здесь:
http://blogs.msdn.com/b/shawnhar/archive/2007/11/23/game-timing-in-xna-game-studio-2-0.aspx

В 2.0 поведение Draw изменилось:

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

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

примечание: xna также поддерживает переменный временной шаг, это просто настройка.

Джоэл Мартинес
источник
Это самый распространенный способ прохождения игрового цикла. Однако при работе с мобильными устройствами он не очень подходит для работы от батареи.
knight666
1
@ knight666; Вы предполагаете, что при использовании более длинного временного шага уменьшенное количество итераций спасет аккумулятор?
Фальстро
Это все еще переменное обновление - дельта обновления изменяется в зависимости от того, сколько времени потребовалось на рендеринг кадра, а не на какое-то фиксированное значение (т. Е. 1/30 секунды).
Деннис Манси
1
@Dennis: насколько я понимаю, функция Update вызывается с фиксированной дельтой ...
RCIX
3
@ knight666 Э-э, как ты это понял? Если у вас включен vsync и вы не заикаетесь - эти методы должны быть идентичны! И если у вас есть Vsync от вы обновляете более часто , чем вам нужно, и , вероятно , тратить CPU (и , следовательно , батареи), не позволяя ему на холостом ходу!
Эндрю Рассел
12

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

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

Это не тривиально для реализации, но может оказаться доказательством будущего.

Кая
источник
8

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

Мои игровые циклы рассчитывают количество кадров для обновления (назовем это F), а затем выполняем F дискретных обновлений логики. Каждое обновление логики предполагает постоянную единицу времени (которая в моих играх часто составляет 1/100 секунды). Каждое обновление выполняется последовательно, пока не будут выполнены все обновления F дискретной логики.

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

Плохая реализация этого просто сделает F = текущее время - последние обновления времени кадра. Но если расчеты слишком сильно отстают (иногда из-за не зависящих от вас обстоятельств, например, из-за того, что другой процесс крадет процессорное время), вы быстро увидите ужасный пропуск. Быстро, тот стабильный FPS, который вы пытались поддерживать, становится SPF.

В моей игре я допускаю «плавное» (своего рода) замедление, чтобы ограничить количество логического захвата, которое должно быть возможно между двумя розыгрышами. Я делаю это, зажимая: F = min (F, MAX_FRAME_DELTA), который обычно имеет MAX_FRAME_DELTA = 2/100 * с или 3/100 * с. Таким образом, вместо того, чтобы пропускать кадры, когда они слишком далеко отстают от игровой логики, отбросьте любую значительную потерю кадров (что замедляет ход событий), восстановите несколько кадров, сделайте рисование и попробуйте снова.

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

Конечный псевдокод продукта выглядит примерно так (дельта F упоминается ранее):

// Assume timers have 1/100 s resolution
const MAX_FRAME_DELTA = 2
// Calculate frame gap.
var delta = current time - last frame time
// Clamp.
delta = min(delta, MAX_FRAME_RATE)
// Update in discrete steps
for(i = 0; i < delta; i++)
{
    update single step()
}
// Caught up again, draw.
render()

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

Overkill
источник
Полностью согласен с этим последним пунктом; почти во всех играх ввод должен «замедляться», когда частота кадров падает. Хотя это невозможно в некоторых играх (например, в мультиплеере), было бы лучше, если бы это было возможно. : P Это просто лучше, чем иметь длинный кадр, а затем заставить игровой мир «прыгнуть» в «правильное» состояние.
Ipsquiggle
Без фиксированного оборудования, такого как аркадная машина, аркадные игры замедляют симуляцию, когда аппаратное обеспечение не успевает за игрой, заставляет играть на более медленной машине.
Джо, это имеет значение, только если мы заботимся о "обмане". Большинство современных игр на самом деле не о конкуренции между игроками, это просто забавный опыт.
Иэн
1
Иэн, мы говорим конкретно об аркадных играх здесь, которые традиционно основаны на списке рекордов / списке лидеров. Я играю кучу шмупов и знаю, что если я найду кого-то, кто публикует результаты с искусственным замедлением в списках лидеров, я бы хотел, чтобы их результаты были стерты.
Не пытаясь приуменьшить ваш ответ, но я бы интерпретировал это как фиксированный шаг, при котором рендеринг не привязан напрямую к частоте обновления физики, за исключением того, что догоняющая физика имеет приоритет над рендерингом. Это определенно имеет хорошие качества.
AaronLS
6

Это решение не применимо ко всему, но есть другой уровень переменного временного шага - переменный временной шаг для каждого объекта в мире.

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

Рендеринг полностью отделен от очереди событий. Механизм отображения интерполирует точки между временем начала / окончания события по мере необходимости и может быть настолько точным или неаккуратным в этой оценке, насколько это необходимо.

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

while (game_is_running)
{
   world.draw_to_screen(); 
   world.get_player_input(); 
   world.consume_events_until(current_time + time_step); 
   current_time += time_step; 
}

Основной причиной использования одного в космическом симуляторе является необходимость обеспечения произвольного ускорения времени без потери точности. Некоторые миссии в EXOFLIGHT могут занимать годы игры, и даже 32-кратного ускорения будет недостаточно. Вам понадобится более 1 000 000 раз ускорения для пригодного для использования сима, что трудно сделать в модели с временным интервалом. С помощью модели, основанной на событиях, мы получаем произвольные значения времени от 1 с = 7 мс до 1 с = 1 год.

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

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

Минусы: сложность и отсутствие каких-либо готовых физических движков, которые поддерживают эту модель :)

sehugg
источник
5

Фиксированный временной шаг полезен, если учитывать точность с плавающей запятой и согласованность обновлений.

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

now = currentTime
frameTime = now - lastTimeStamp // time since last render()
while (frameTime > updateTime)
    update(timestep)
    frameTime -= updateTime     // update enough times to catch up
                                // possibly leaving a small remainder
                                // of time for the next frame

lastTimeStamp = now - frameTime // set last timestamp to now but
                                // subtract the remaining frame time
                                // to make sure the game will still
                                // catch up on those remaining few millseconds
render()

Основная проблема с использованием фиксированного временного шага заключается в том, что игроки с быстрым компьютером не смогут использовать скорость. Рендеринг со скоростью 100 кадров в секунду, когда игра обновляется только со скоростью 30 кадров в секунду, аналогичен рендерингу со скоростью 30 кадров в секунду.

При этом может быть возможно использовать более одного фиксированного временного шага. 60fps можно использовать для обновления тривиальных объектов (таких как пользовательский интерфейс или анимированные спрайты), а 30fps для обновления нетривиальных систем (таких как физика и т. Д.) И даже более медленных таймеров для управления за кулисами, таких как удаление неиспользуемых объектов, ресурсов и т. Д.

Ник Бедфорд
источник
2
Если игра тщательно сделана, метод рендеринга может выполнить интерполяцию, чтобы обновления 30fps фактически не совпадали с рендерингом при 30fps.
Рикет
3

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

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

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

identitycrisisuk
источник
5
Вы обязательно должны прочитать ссылку Gaffer on games в оригинальном посте. Я не думаю, что это плохой ответ сам по себе, поэтому я не буду голосовать против него, но я не согласен ни с одним из ваших аргументов .
Фальстро
Я не думаю, что замедление в игре из-за фиксированного временного шага может быть преднамеренным, потому что это из-за отсутствия контроля. Отсутствие контроля по определению предается случайности и поэтому не может быть преднамеренным. Может быть, это то, что вы имели в виду, но это то, что я хотел бы пойти на это. Что касается фиксированного временного шага в сети, то здесь есть определенный плюс, поскольку синхронизировать физические движки на двух разных машинах без одного временного шага практически невозможно. Поскольку единственная опция для синхронизации - отправка всех преобразований сущностей, это будет слишком большой пропускной способностью.
Кадж
0

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

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


источник
Если ты собираешься украсть ответы, хотя бы зачитай этого человека!
PrimRock
0

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

Переменные временные шаги не подходят для VR. Посмотрите на некоторые примеры Unity VR, которые используют переменные временные шаги. Это неприятно.

Правило гласит: если ваша 3D-игра плавная в режиме VR, она будет отличной в режиме без VR.

Сравните эти два (приложения Cardboard VR)

(Переменные временные шаги)

(Фиксированные временные шаги)

Ваша игра должна быть многопоточной, чтобы достигать согласованного временного шага / частоты кадров. Физика, интерфейс и рендеринг должны быть разделены на отдельные потоки. Это ужасная PITA, чтобы синхронизировать их, но в результате вы получите тот зеркально-плавный рендеринг, который вам нужен (особенно для VR).

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

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

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

Доминик Черизано
источник
0

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

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

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

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

Все остальное можно обрабатывать асинхронно, что делает спорным моментом времени.

Ян Янг
источник