Пишу простенькую игрушку, через DirectX. При падении ФПС движок просчитывает всё так, что объекты даже при низком ФПС перемещаются на то же расстояние, что и при нормальном. Т.е. если объект должен за 3 секунды долететь от одного края экрана до другого то он и долетит. Вот только при низком ФПС он как бы перескакивает через большие расстояния. В итоге не всегда срабатывает коллизия, да и выглядит не очень красиво.
Естественно это наблюдается только на слабых машинах и только при большом количестве объектов. Хотя в любом случае бывают ситуации когда ФПС разово падает.

Как сделать так, чтобы при падении ФПС события в игре притормаживались, а не перескакивали?

Имеется: значение текущего фпс (вычисляется движком), значение interval таймера, величина задержки (LagCount - вычисляется движком).

Это сообщение отредактировал(а) Агрох - 4.2.2014, 16:02

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

Ситуация, которую я описал, это что то вроде стресс-теста. Когда объектов заведомо больше, чем надо.

Опишу немного по другому. Летит пуля, из за описанного выше события она пролетает сквозь объект, т.к. фактически её координаты не пересекались с координатами объекта. Координаты, по оси X, пули меняются от 0 до 100, объект стоит в координатах 50. При нормальном ФПС координата пули меняется на 1 и она нормально сталкивается с объектом. При низком уровне ФПС её координаты меняются за раз на 3-6 и она может пролететь сквозь объект (по крайней мере визуально).

Хотел попробовать, может искусственное затормаживание поможет. Не хотелось бы усложнять расчёты.

Хотя ещё надо покопаться. Может надо поменять что то в событиях вызова коллизии и смены координат объектов.

Коллизия пули это всегда проблема номер 1. А что если у вас пуля должна лететь со скоростью три экрана в секунду? Тут вам никакой ФПС не поможет. Коллизия пули рассчитывается не пересечением точки и фигуры, а пересечением отрезка и фигуры. Отрезок это расстояние которое прошла пуля за интервал времени

Добавлено через 3 минуты и 34 секунды
В некоторых физ движках (например в Box2D) вы можете задать объекту специальный флаг isBullet, в таком случае физика такого объекта рассчитывается на основе отрезка пройденного объектом с момента последнего расчета. Для объектов без такого флага, физика рассчитывается как обычно.

Bitter, спасибо за совет.

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

Правильная последовательность вызова событий смены координат и коллизии помогла не полностью (у меня стояло сначала проверка коллизии, а потом смена координат. Надо наоборот). Вроде стало лучше, но всё равно проскакивают. При этом, естественно, чаще через тонкие объекты (толщина 1-2 пикселя). Для чистоты эксперимента проверю ещё на слабой машине, или на виртуалке.

Попробую описать поведение пуль самостоятельно.

  Сразу говорю, что я физическими движками не занимался, но мне в голову приходит такое решение. Во первых физику считать безотносительно графики, можно даже с меньшим fps. Представим себе замкнутый полигональный меш, который движется с некоторой скоростью V (вектор V функция от t) . Будем исследовать коллизии через некоторые дискретные промежутки времени dt . В физике обычно позиция тела вычисляется как решение дифференциального уравнения движения. В простейших случаях когда ускорение не меняется со временем, то получаем школьное решение уравнения (например для координаты X) получается такое X=X0+V0x*t+(ax*t^2)/2 ; Т.е. если на тело действует гравитация или еще какая сила с постоянным вектором и модулем.
  Нам это дает, то что через произвольный интервал времени dt мы будем абсолютно точно знать координаты тела X,Y,Z . Т.е. если X0 это исходная координата X, то через момент времени dt X1, будет иметь значение X1= X0+V0x*(t+dt)+(ax*(t+dt)^2)/2 .
  Но знание позиции еще не дает нам информации о коллизии, поскольку координата X0 может находиться с одной стороны стены, а X1 уже через стенку. Чтобы проверить соударение нам нужно сначала посчитать вектор изменения позиции. Тут все просто (x1-x0,y1-y0,z1-z0). В 3D графике при помощи матриц можно задавать операцию масштабирования (4й столбец). Вот мы и делаем масштабирование модели в направлении сдвига. Т.е. пуля будет вытягиваться в длинный пруток(быстро летит), а детский мячик вытянется в небольшой цилиндр. Теперь, очевидно, чтобы проверить коллизию для пули, нужно проверить пересечение не исходной модели, а именно этого получившегося длинного прутка, поскольку он описывает все позиции тела за интервал времени dt . Мячик, соответственно будет вытянут меньше. 
  В заключении оговорюсь, что тут описана физика материальной точки, т.е. объекта чьими размерами можно пренебречь. Для правильного описания твердого тела потребуется решение уравнения для вращательного движения (но суть дискретизации та же). Т.е. к трем координатам добавятся еще 3 угла. Вместо сил считаем вращательный момент, а вместо массы фигурирует момент инерции. Это может понадобиться для описания физики вытянутых объектов. Например, 2 ребенка катаются на качелях (перекладина с фиксацией посередине). Движение перекладины будет чисто вращательным. Или к примеру кубик падает с большой горизонтальной скоростью и начинает катиться.

Проблему решил.

На всякий случай уточню. Делаю всё в 2D.

Убрал встроенную проверку коллизии. Именно она давала сильное падение ФПС. Т.к. проверка на пересечение пикселей (не рамки) в принципе ресурсоёмкая, плюс осуществлялась для всех со всеми, в т.ч. пули с другими пулями, фоном, кнопками, текстом. 2 объекта - 2 проверки, 3 объекта - 6 проверок 4 объекта - 12 проверок ... 100 объектов - 9900 проверок. Т.е. количество проверок росло лавинообразно. Может, если найти способ проверять два конкретных объекта, определяя предварительно какие находятся примерно в одной области и надо ли вообще для них осуществлять проверку, то можно снизить падение ФПС.

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

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

Bitter, да, я это уже понял.
Проблема в том, что просто так в движке нет функции проверки коллизии между двумя конкретными объектами, или хотя бы группами объектов. Есть вызов коллизии, без параметров, для конкретного объекта, которая проверяет, пересекается ли этот объект с другими.

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

Плюс это не решит проблему поиска пересечения траекторий пули и цели.