Delta timing

[Nikich]

Проблема с дельта таймингом. При скачках в 3-4 миллисекунды заметны рывки при перемещении. Без дельта таймнига все отлично. Есть ли смысл его использовать, если фпс точно меньше 60?
UPD
Рывки оказались из-за округлений Теперь беда в другом.
Допустим герой прыгнул в момент времени, в котором dt(время с предыдущего обновления игры) было 40 миллисекунд. Сила его прыжка увеличилась сильно увеличилась по сравнению с нормой. Затем, dt опять пришло к нормальным 16.6666 миллисекундам. Поэтому коэффицент G, который отвечает за ускорение свободного падения опять нормальный. В результате получаем гигантский прыжок. Как этого избежать?

[pax]

Если это Unity, то для физики есть FixedUpdate и Time.fixedDeltaTime

Но по сути если провести аналогию с твинингом в блице, то тебе просто надо вызывать логику только допустим 30 раз в секунду и если с предыдущего обновления прошло времени в два раза больше, то выполнить логику два раза.

[Nikich]

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

[pax]

Да в чем проблема я не понимаю?

float ellipsedTime = 0;
public float timeStep = 1000f / 60f;

void Update()
{
    ellipsedTime += Time.deltaTime * 1000f;

    while(ellipsedTime >= timeStep)
    {
         ellipsedTime -= timeStep;
         UpdateLogic();
    }
}

void UpdateLogic()
{
   // обновление логики с фиксированным шагом времени в timeStep мс

} 


[KCEPOKC]

Что эта тема делает в болтовне?

[Nikich]

В данном способе 2 проблемы.
Если таки у игрока больше 60 фпс - цикл вообще не запустится.
Если у игрока 29 фпс, разницы с 30 фпс почти не должно быть, однако update() будет выполнено 3 раза, в то время как при 30 фпс - 2 раза.

[Samodelkin]

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

[pax]

Сообщение от Nikich

В данном способе 2 проблемы.
Если таки у игрока больше 60 фпс - цикл вообще не запустится.
Если у игрока 29 фпс, разницы с 30 фпс почти не должно быть, однако update() будет выполнено 3 раза, в то время как при 30 фпс - 2 раза.

Ты верно код читал не внимательно или его не попробовал.

[moka]

Исходя из первого поста, почему сила прыжка зависит от dt? Она не должна, при прыжке персонаж получит ускорение в 100 единиц. Далее при применении ускорения - применяешь dt.

[Nikich]

moka
Сейчас так и делаю. Но баланса все равно нету: игрок с маленьким фпс не может прыгнуть так же высоко, как игрок с нормальным.
PAX

public float timeStep = 1000f / 60f;

Известные 16(6) мс.

ellipsedTime += Time.deltaTime * 1000f;

Допустим у пользователя супер мощный конфиг, и у него игра идет со 120 ФПС, то бишь 8(3) мс.

while(ellipsedTime >= timeStep)

Никогда не произойдет, так как 8(3) точно меньше чем 16(6).

[pax]

А теперь посмотри на эту строку внимательно:

ellipsedTime += Time.deltaTime * 1000f; 


Время накапливается (оператор += тебе ничего не сказал?), за два отрисованных кадра будет 2 * 8(3) и сработает логика. Я ж говорю, невнимательно код смотрел и не пробовал.

В твоем примере 29 FPS будет 30 раз срабатывать логика, она даже с 15 FPS будет 30 раз срабатывать. И даже имея 128 FPS с шагом в 1000f / 60f логика будет срабатывать 60 раз в секунду в среднем.

[Nikich]

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

[pax]

Не хочешь признать, что был не прав. Ладно.

Сообщение от Nikich

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

Что такое рекурсивный проигрыш производительности? Ты хочешь замедлять игры при FPS меньше нормы или чтобы игра работала нормально? Твоя логика (за 30 FPS) работает столько же или больше, сколько и вывод одного кадра на экран?

[Nikich]

Я был не прав, да, не заметил "+=". И не спорю, что при слабой логике это было бы отличным решением.
Но решение с обычным домножением скоростей на deltaTime кажется более верным и логичным, разве нет?

[pax]

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