Лимиты FPS?

[VintProg]

У тебя какая омега? на OGL или на DX......

Пишу на DX.

[VintProg]

А если так сделать в таймер установить на 5
в этом таймере обрабатывать все игровые процессы такие как персонажи физика, AI, Летяшии пули... а Draw; пускай будит самим собой.

[Kostia]

Такой вопрос, у меня очень слабый комп. и он не успевает за таймером в 5 миллисекунд, вследствие чего ход процесса игры замедляется, как с этим бороться?
Комп у меня
Intel 233
ATI Technology 2mb
32mb DRAM

PS: Вспомните "тормоза" в играх, почему они возникают?

[JTG]

А если так сделать в таймер установить на 5
в этом таймере обрабатывать все игровые процессы такие как персонажи физика, AI, Летяшии пули... а Draw; пускай будит самим собой.

2 таймера сделай. 1 с минимальной задержкой занимается расчётами, обработкой клавиатуры и т.п., а второй с интервалом n=1000/FPS ms выводит графику. Если рисовать "самим собой", т.е. тупо в цикле - загрузишь проц на 99%. Короче говоря зачем обновлять кадр, если в нём ничего не изменилось?

[pu4koff]

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

2 таймера сделай. 1 с минимальной задержкой занимается расчётами, обработкой клавиатуры и т.п., а второй с интервалом n=1000/FPS ms выводит графику. Если рисовать "самим собой", т.е. тупо в цикле - загрузишь проц на 99%. Короче говоря зачем обновлять кадр, если в нём ничего не изменилось?

1. Что делать, если в этот минимальный таймер не уложились?
2. Зачем обрабатывать кадр, который не выведется?
3. Как быть на пересечении этих кадров? Пока медленный комп будет долго и нудно выводить картинку на экран, расчитывать мы не сможем, т.е. чем быстрее комп выведет картинку на экран, тем быстрее кубик полетит. Можно конечно разбить это дело на 2 потока, но тогда появится проблема синхронизации.
4. Что делать, если в игре будут как "полупустые" сцены, так и насыщенные со сложными эффектами? Пусть простенькие сцены так же тормозят, как и сложные, т.е. одиночный кубик пусть так же дёргается, как и сотня кубиков?
4. Что не так в предложенном мной варианте? Лично я проблем никаких не вижу, зато "автоматически" качество движения будет подстраиваться под скорость компа. Один кубик полетит плавно, сотня будет тормозить, если комп не потянет. И реализация вроде бы несложная:

1. Определить текущее время
2. Определить дельту времени (текущее время - время предыдущего кадра)
3. Если дельта слишком маленькая (высокое ФПС), то можно какой-нибудь Sleep(0) (чтобы процессор мог на другую задачу переключиться пока) воткнуть и на пункт 1 вернуться. Если же дельта слишком большая, то можно автоматически настройки снизить (дальность прорисовки снизить и всё в этом духе). Это конечно всё по желанию, если нужно вообще будет.
4. Взаимодействие с пользователем (определение нажатых клавиш и т.п.)
5. Расчет кадра с учетом дельты и реакции пользователя (если юзверь нажал стрелку, то переместить кубик в соответствующем направлении на расстояние что-то вроде: скорость_кубика*дельта_времени)
6. Вывод кадра на экран

и это всё в бесконечный цикл обернуть и пусть себе рисуются картинки, как комп "потянет". На шустром компе просто плавная картинка будет, а на слабеньких - дёргаться будет.
Единственный "косяк", который я вижу: можно на низких ФПС сквозь стенку пролететь, например, но тут зависит от алгоритмов расчета физики и т.п.

[Kostia]

pu4koff, прямо в точку! Привязка ко времени, Sleep(0) засыпание потока для того чтобы винда могла переключиться на др. поток(процесс).

[JTG]

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

Sleep, ну давайте ещё yield вспомним Хорошо работает лишь в теории, на самом деле если в очереди нет потоков, ожидающих выполнения и с более высоким приоритетом (а система 95% времени именно нифига не делает), то планировщик тут же вернёт управление вызывавшему и процессор всё-равно будет загружен по самое не хочу, в том числе резко участившимся переключением задач, а если передать в качастве параметра 0, то при вызове поток ещё и не уберут из очереди

[pu4koff]

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

pu4koff, нет, имеется ввиду, что используется мультимедийный таймер. Работает он фактически в отдельном потоке, отрисовка и расчёты не обязаны ждать друг друга. А вот если делать всё линейно - то тормоза на загруженной сцене завесят всю игру.

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

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

Sleep, ну давайте ещё yield вспомним

Ну Sleep я так чисто для галочки привёл.

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

Хорошо работает лишь в теории, на самом деле если в очереди нет потоков, ожидающих выполнения и с более высоким приоритетом (а система 95% времени именно нифига не делает), то планировщик тут же вернёт управление вызывавшему и процессор всё-равно будет загружен по самое не хочу в том числе резко участившимся переключением задач

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

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

а если передать в качастве параметра 0, то при вызове поток ещё и не уберут из очереди

Ну единичку передавайте. Какая разница. Это вообще мелочь в данном случае не принципиальная.

И всёже что будет, если неправильно выставим скорость мультимедийного таймера? Тики там в очередь не встают вроде как, т.е. на старом компе обработается 20 тиков, а на современном, за то же время, положенные 30. Как от этого уберечься?

Да и вообще как ни крути, а все программы в циклах крутятся и ничего страшного с процем не происходит. В виндовых прогах в основе лежит цикл обработки сообщений. Для OpenGL в glut есть glutMainLoop. и т.д.
Тут конечно свои проблемы будут: Вдруг на каком-то кадре вдруг расчеты сложные резко стали или еще какая фигня, но это всё дотачивается. И кубик скорее всего будет итерациями смещаться, а не тупо по формуле: скорость_кубика * дельта_кадров. По хорошему нужно принять, что за одну итерацию кубик упадёт, допустим, на 2 позиции, а итерация длится 0.05 секунды. Разность кадров, например, составила 0.12с, за это время можно выполнить 2 итерации падения кубика, что в обычном for'е можно будет и сделать. Если же кадр новый отрисовался за 0.03с, то кубик и шевелиться не будет, т.к. по времени в одну итерацию не укладываемся.
Возникает только вопрос как определять эту дельту. А тут либо QueryPerformanceCounter (самый быстрый счетчик времени, но свои грабли у него в многопроцессорных системах и если процессор частоту на лету меняет с целью экономии энергии), либо тот же самый мультимедийный таймер (выставляем его на какой-нибудь достаточно короткий промежуток времени, считаем в тиках сколько кадров было прорисовано и по этой информации получаем приближенную дельту для отрисовки кадров).
В общем я на все 100% за расчеты кадров на основе дельты, а не каждый тик таймера. Никаких расчетов в таймере и т.п. операций. Таймер может понадобится только для получения дельты, но тут уже кому как нравится.

[Kostia]

Да, реализовать это довольно сложно, при том что, если использовать QueryPerformanceCounter, дельта будет не всегда положительная!
Можно почитать на gamedev http://www.gamedev.ru/code/forum/?id=80205
В MSDN http://msdn.microsoft.com/en-us/libr...8VS.85%29.aspx
Можно реализовать все одним таймером, он копит время, которое потом используется как delta. Посмотрите во вложении, там конечно грубо все сделано, но это работает.

[JTG]

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

Посмотрите во вложении, там конечно грубо все сделано, но это работает.

Не работает, виснет через 2-3 секунды после запуска, в колбеке напрямую работать с переменными нельзя
и с параметрами не всё в порядке
timeSetEvent(1,0,@Timer,DWORD(self),TIME_PERIODIC);