Должны ли игры полагаться только на частоту кадров?

Question

Я бы хотел, чтобы ваше предложение по этой проблеме ...

Чтобы сделать это простым, я рассмотрю только ось x.

Изображение объекта в позиции 10, а его ширина также 10 единиц, которая движется вперед 100 единиц в секунду, и из-за низкого кадра при каждом обновлении он должен перемещать 80 единиц.

После первого обновления называется, его позиция теперь 90, и есть еще один объект того же размера в позиции 120.

Следующее обновление будет переместить объект позиции 170. Учитывая, что мне нужно осуществлять обнаружение столкновения, вычислять столкновение до или после обновления, никто не будет работать.

Теперь приходит простой вопрос ...

Что делать в этом случае?

ли что-то вроде:

Position start = destinationPos - currentPos; 
for (int i; i < start; i++) 
    if (IsColliding(movingObj.Position + i, staticObj)) 
     //do the colliding stuff here 

Мне не нравится это решение, оно может быть хорошо для этого случая, но что, если у вас есть х, у, г и много движущихся объектов?

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

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

Что вы, ребята, думаете?

Answer 1

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

Если вы не особенно заинтересованы в реализации алгоритмов столкновения deteciton себя, я хотел бы посмотреть в использовании библиотеку, которая уже делает такую ​​вещь:

• Bullet physics engine
• G3D
• Geometric Tools

Один из многих хороших книг по теме - Real Time Collision Detection.

Answer 2

Майк Дэниелс коснулся этого, но ваш ответ отрицательный: вы не хотите, чтобы ваши объекты перемещались в дискретных «всплесках». Приведем пример в 1d: Автомобиль начинается с x = 0 и ускоряет 2 единицы/сек^2 в прямом направлении. Вы не пересчитали скорость и положение на каждом кадре.Вместо этого вы использовали бы простое исчисление: скорость - это интеграл от ускорения, а положение - интеграл от ускорения. Таким образом, v = 2*t и p = t^2. Все, что вы могли бы сделать, это заменить t на то, сколько времени прошло с момента начального условия.

Теперь предположим, что у вас есть второй объект в положении 100, ускоряющийся на -3 единицы/сек^2. Тогда его скорость равна -3*t, а ее позиция 100 - (3/2)*t^2. Решая, когда 2 позиции равны друг другу, мы можем видеть, что они сталкиваются, когда t = 40.

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

Answer 3

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

Glenn Fiedler's site имеет пример игрового цикла, который работает таким образом. Лично я всегда бывал с фиксированными обновлениями с учетом выбора. Это просто упрощает так много вещей, особенно вокруг физики.