Движение при низком FPS

[GLEB]

Что бы объкты перемешались с одинаковой скоростью, независимо от fps, нужно увеличивать или уменьшать шаг перемешения.
Чем ниже fps, тем больше это значение.
Вот в чем проблема, при 30 - 40 кадрах заметно что все перемещается с большим шагом.
Запустил CS, поставил самое большое разрешение, и режим отображения fps.
Всего 27 кадров при 1024х768, но рывков особо незаметно.
У меня в проге на таком разрешении 45 fps, но рывки довольно большие.
Почему так?

[d3drm]

ты ограничиваешь fps?

[nekeda]

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

[Mikle]

nekeda

Что бы объкты перемешались с одинаковой скоростью, независимо от fps, движение надо осуществлять через равные промежутки времени

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

[GLEB]

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

[Mikle]

Ты себе противоречишь, сам же привел пример CS, где FPS ниже, а скачки незаметнее.
А "перемещению приращать большее значение" - это естественно, ты что, не так делал?

[nekeda]

Mikle

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

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

[d3drm]

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

[Mikle]

Все это верно, но я в четвертом посте имел ввиду даже не это. D3D выдает на экран картинку не сразу, а кэширует 3-4 кадра, а некоторые программы каким-то образом умудряются сбросить этот кэш. Это может проявиться не только в наших программах, а даже в солидных играх, например сам видел дерганье у NFS Underground 2, в то врямя как DOOM3, например, работал ровно. После выключения твикер от Gigabyte, NFS Underground 2 тоже стал ровно работать.

[nekeda]

d3drm
но функция которая будет "увеличивать или уменьшать шаг перемешения" тоже не будет работать с одинаковой частотой?

[Amed]

Надо делать функцию перемещения непрерывную (от времени), а не дискретную (от номера кадра).

[nekeda]

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

[Mikle]

Блин, что тут сложного. Знаешь позицию объекта и скорость, засекаешь точное время (QueryPerformance), рисуешь сцену, снова засекаешь время, ЗНАЯ СКОРОСТЬ, исходя из прошедшего времени вычисляешь новые координаты - и так до бесконечности.
Я поначалу подумал, что вопрос более сложен, а тут еще с простым не разобрались.