Поэкспериментировал с разными соотношениями частот симуляции и отрисовки, на девайсах разной мощности. Пришёл к выводу, что таки да, интерполяция имеет смысл, плавность отрисовки от этого выигрывает. Насчёт экстраполяции и просчитанных состояний ты тоже всё верно сказал.
(Приведённый в статье «цикл deWiTTER'а» мне всё равно не нравится, можно всё прозрачнее переформулировать.)
> В отвязке без интерполяции смысла очень мало как раз, как написал автор, движение объектов будет сильно дискретным ака рывками.
Не будет, если физический движок (управляющий движением тел в мире), шагает чаще, чем обновляется экран — как ему и положено.
> Для интерполяции не нужно детектирование коллизий. Интерполяция происходит между двумя просчитанными состояниями. Коллизии уже просчитаны. Экстраполяция отсутствует. Фиксед.
Печально пользователю играть в такую игру. Он пытается увернуться от летящего камня, но всё предрешено — камень в него попадёт. Точнее уже попал, хотя отрисовка всё интерполирует и интерполирует…
> Теорикрафтинг это хорошо, но если развязку игрового мира от фреймрейта придумали, то значит это кому то нужно.
В полезности отвязки от переменного фреймрейта сомнений нет. Есть сомнения в полезности ручной интерполяции.
> Никаких прохождений ракет сквозь самолеты не наблюдается.
Это прекрасно, что в движке SupremeCommander'а реализован continuous collision detection. В Box2d же (при отключенном CCD) таймстеп 1/10 приведёт к плачевным результатам.
> И каким образом вы с его помощью решите задачу максимально быстрого рендера?
Про максимально быстрый рендер не всё понятно. Частота рендера должна быть ограничена сверху (и, желательно, снизу). Если перерисовка выполняется 200 раз в секунду, то пользователь просто не заметит разницы по сравнению с 60, в силу физиологических возможностей (тем более, что ограничивать может сама платформа, refresh rate дисплея, etc). А если те же ресурсы пустить на более частый просчёт мира, то улучшение качества симуляции будет весьма заметно. «Пули» перестанут проходить сквозь стены, ragdoll'ы не будут дёргаться, etc.
> Причем тут вообще физический движок?
Я просто вместо обновления игровой логики в общем случае (AI, input, контакты, etc) рассматриваю только физическую симуляцию, для простоты. Согласно вашему подходу, очередной момент времени физического движка (оно дискретно, шаг фиксирован) может длиться в течении нескольких «отрисовочных» кадров (шаг не фиксирован, как получится). Вы пытаетесь сделать эти кадры разными, путём «фейкового» движения. Скажем, падает мяч. Вы знаете его скорость, считаете её фиксированной, линейно интерполируете. При этом, наткнувшись на стену, «образ» вашего мяча спокойно продолжит двигаться вглубь — ведь физический мир стоит, а вы самостоятельно констрейнты не рассчитываете, и столкновения не решаете. Равноускоренность движения и действующие силы тоже не моделируете — просто упрощённо и неточно «интегрируете» движение тела.
> Как раз чем чаще вы будете обсчитывать физику — тем меньше у вас останется времени на рендер.
Всё-таки ответьте на вопрос. Есть физ. движок (скажем, Box2D), который нельзя запускать реже 60 раз в секунду. Есть игровой фреймворк (скажем, Cocos2d-x), где можно задать максимальный fps. Но его нет смысла задавать более частым, чем 60 раз в секунду (человек не увидит разницы). 60 раз в секунду — желательный фреймрейт, но он в процессе игры будет проседать (может, из-за физики, может, из-за отрисовки); хорошо, если будет оставаться выше 30.
В этих условиях физический движок будет шагать не менее одного раза за кадр. Т.е. у вас в принципе не будет проблемы одинаковых кадров, которую пытается исправить ручная интерполяция. Так зачем она нужна?
> Только запрограммировав ее под 125 вы заставляете делать процессор напрасную работу
И наоборот. Занизив частоту, вы недогрузите процессор. Он будет простаивать, в то время как мог бы повысить точность обсчёта мира.
> А интерполяция — это относительно «недорогая» процедура.
Это ручной и неточный способ делать то, для чего предназначен физ. движок. Мы же прогнозируем новое положение без учёта столкновений.
Более или менее плотно я работал только с Box2d. Там втор настоятельно рекомендует «шагать» движком не менее 60 раз в секунду. И действительно, при уменьшении частоты (увеличении временного шага) точность симуляции быстро деградирует.
Следование этому ограничению фактически означает, что физика будет обсчитываться с большей частотой, чем обновляться картинка, а значит интерполяция избыточна.
Здесь time() вызывается на каждой итерации вложенного цикла. Такого быть не должно. В общем случае вместо одного вложенного цикла, оборачивающего вызов «updateGameState();» будет несколько последовательных циклов (со своими константами frameDuration и maxFrameSkip), оборачивающих «UpdatePhysics()», «UpdateInput()», «UpdateLogic()», «UpdateAi()», etc. Вызов time() исчерпает квант игрового времени уже на первом вложенном цикле.
Вообще-то, приведённые примеры «правильно» расходятся с тем что помечено как «correct» в упомянутой статье. В частности, это касается пробелов между ключевыми словами if, while перед скобкой с условием.
Понятно, что в этой штуке нет ничего революционного, это надстройка над давно и успешно используемым пакетным менеджером под Windows — NuGet (или, возможно, просто использует его формат описания пакетов NuSpec). Вот только в чём эта настройка заключается, что нового привносит? Вот что хотелось бы понять из этой статьи.
> Майкл Блейк присвоил нотам от до одной октавы до ноты до следующей октавы номера от 1 до 8.
Так ведь октава же делится на 12 частей (полутонов).
> Число Тау в два раза больше числа Пи и приближенно равно 6,283185. Майкл Блейк присвоил нотам от до одной октавы до ноты до следующей октавы номера от 1 до 8.
Чем было продиктовано решение взять разложение числа тау именно в неудобной для этих целей десятичной системе?
Только важно, чтобы их источником не было боговерство, иначе на выходе получаем не мораль, а её эрзац.
(Приведённый в статье «цикл deWiTTER'а» мне всё равно не нравится, можно всё прозрачнее переформулировать.)
Не будет, если физический движок (управляющий движением тел в мире), шагает чаще, чем обновляется экран — как ему и положено.
> Для интерполяции не нужно детектирование коллизий. Интерполяция происходит между двумя просчитанными состояниями. Коллизии уже просчитаны. Экстраполяция отсутствует. Фиксед.
Печально пользователю играть в такую игру. Он пытается увернуться от летящего камня, но всё предрешено — камень в него попадёт. Точнее уже попал, хотя отрисовка всё интерполирует и интерполирует…
В полезности отвязки от переменного фреймрейта сомнений нет. Есть сомнения в полезности ручной интерполяции.
> Никаких прохождений ракет сквозь самолеты не наблюдается.
Это прекрасно, что в движке SupremeCommander'а реализован continuous collision detection. В Box2d же (при отключенном CCD) таймстеп 1/10 приведёт к плачевным результатам.
Про максимально быстрый рендер не всё понятно. Частота рендера должна быть ограничена сверху (и, желательно, снизу). Если перерисовка выполняется 200 раз в секунду, то пользователь просто не заметит разницы по сравнению с 60, в силу физиологических возможностей (тем более, что ограничивать может сама платформа, refresh rate дисплея, etc). А если те же ресурсы пустить на более частый просчёт мира, то улучшение качества симуляции будет весьма заметно. «Пули» перестанут проходить сквозь стены, ragdoll'ы не будут дёргаться, etc.
> Причем тут вообще физический движок?
Я просто вместо обновления игровой логики в общем случае (AI, input, контакты, etc) рассматриваю только физическую симуляцию, для простоты. Согласно вашему подходу, очередной момент времени физического движка (оно дискретно, шаг фиксирован) может длиться в течении нескольких «отрисовочных» кадров (шаг не фиксирован, как получится). Вы пытаетесь сделать эти кадры разными, путём «фейкового» движения. Скажем, падает мяч. Вы знаете его скорость, считаете её фиксированной, линейно интерполируете. При этом, наткнувшись на стену, «образ» вашего мяча спокойно продолжит двигаться вглубь — ведь физический мир стоит, а вы самостоятельно констрейнты не рассчитываете, и столкновения не решаете. Равноускоренность движения и действующие силы тоже не моделируете — просто упрощённо и неточно «интегрируете» движение тела.
> Как раз чем чаще вы будете обсчитывать физику — тем меньше у вас останется времени на рендер.
Всё-таки ответьте на вопрос. Есть физ. движок (скажем, Box2D), который нельзя запускать реже 60 раз в секунду. Есть игровой фреймворк (скажем, Cocos2d-x), где можно задать максимальный fps. Но его нет смысла задавать более частым, чем 60 раз в секунду (человек не увидит разницы). 60 раз в секунду — желательный фреймрейт, но он в процессе игры будет проседать (может, из-за физики, может, из-за отрисовки); хорошо, если будет оставаться выше 30.
В этих условиях физический движок будет шагать не менее одного раза за кадр. Т.е. у вас в принципе не будет проблемы одинаковых кадров, которую пытается исправить ручная интерполяция. Так зачем она нужна?
И наоборот. Занизив частоту, вы недогрузите процессор. Он будет простаивать, в то время как мог бы повысить точность обсчёта мира.
> А интерполяция — это относительно «недорогая» процедура.
Это ручной и неточный способ делать то, для чего предназначен физ. движок. Мы же прогнозируем новое положение без учёта столкновений.
Более или менее плотно я работал только с Box2d. Там втор настоятельно рекомендует «шагать» движком не менее 60 раз в секунду. И действительно, при уменьшении частоты (увеличении временного шага) точность симуляции быстро деградирует.
Следование этому ограничению фактически означает, что физика будет обсчитываться с большей частотой, чем обновляться картинка, а значит интерполяция избыточна.
Здесь time() вызывается на каждой итерации вложенного цикла. Такого быть не должно. В общем случае вместо одного вложенного цикла, оборачивающего вызов «updateGameState();» будет несколько последовательных циклов (со своими константами frameDuration и maxFrameSkip), оборачивающих «UpdatePhysics()», «UpdateInput()», «UpdateLogic()», «UpdateAi()», etc. Вызов time() исчерпает квант игрового времени уже на первом вложенном цикле.
Шовинизм ещё: мужчины, женщины и т.д.</айрони>
BOOST_CURRENT_FUNCTION более переносимо.
Да, STL — клёвый чувак (здесь «STL» — инициалы упомянутого мейнтейнера STL'я). Было бы неплохо, если бы он книжку накатал.
Где об этом можно почитать подробнее? Какая ветка за что отвечает, как происходит расслоение настроек окружения, etc?
Математика-то прекрасна, но к данному случаю отношения не имеет: «Нумерология и нумерологические гадания… не считаются сейчас математическим знанием, как и в случае отделения алхимии от химии или астрологии от астрономии.» © Wikipedia
Так ведь октава же делится на 12 частей (полутонов).
> Число Тау в два раза больше числа Пи и приближенно равно 6,283185. Майкл Блейк присвоил нотам от до одной октавы до ноты до следующей октавы номера от 1 до 8.
Чем было продиктовано решение взять разложение числа тау именно в неудобной для этих целей десятичной системе?