Загрузка процессора

← →
DillerXX © (2007-01-10 21:24) [0]

Пишу тут скриптсейвер. Если делать основной цикл без слипов, то картинка движется правно, всё хорошо. Но, загрузка проца 100%, это как-то не этично, да и вообще, делают же люди по-нормальному. В любых играх, например ElastoMania, в меню загрузка проца маленькая, хотя шарики там бегают. Если поставить хоть Sleep(1), загрузка уменьшается до 0%, но появляются дёрганья, слишком мало управления получает поток :( Как этого можно избежать? Изменение приоритета нити(потока) процесса никак не помогает...

← →
grisme © (2007-01-10 21:31) [1]

В Quake 3, например, загрузка 100%. ID Software - это не нормальные люди? :P

← →
@!!ex © (2007-01-10 21:40) [2]

варианты решения:
1) Фиксированный ФПС(VertSync отлично это дело правит)
2) Меньше приоритет.(Но если у тебя RAR в фоне пакутеся, не поиграеш)

← →
@!!ex © (2007-01-10 21:48) [3]

P.S.
Как вариант, если у тебя не сликшом динамичная сцена, то отрисовывать ее, только если что-то изменилось.

P.P.S.
Игрока обычно не особо напрягает, что гейма скушала 100% проца.
Главное что если окно в фоне, оно жрать не должно.

P.P.P.S
Изменения приоритета никак не сказывается, потому что нету других процессов жрущих проц, поэтому весь проц опять же отадется твоему низкоприоритетному потоку.

← →
@!!ex © (2007-01-10 21:48) [4]

*процессу.

← →
@!!ex © (2007-01-10 21:48) [5]

*процессу.

← →
DillerXX © (2007-01-10 21:50) [6]

> VertSync отлично это дело правит

Поподробнее? Ничего не нашёл по этой строчке

← →
DillerXX © (2007-01-10 21:51) [7]

> Пишу тут скриптсейвер

Просто не хочется чтобы все процессы выполняющиеся в фоне сильно тормозились...

← →
@!!ex © (2007-01-10 22:04) [8]

VSync
Вертикальная синхронизация
Синхронизирует вывод картинки с частотой монитора.

Если не хочешь, чтобы тормозились фоновые порцессы - уменьши приоритет.

← →
ors_archangel © (2007-01-10 22:06) [9]

> > Пишу тут скриптсейвер

Скрипт, извини, что?
Если ScreenSaver - то он ни в коем случае не должен жрать проц - я например, такие SS сразу удаляю: прикинь: пакуешь что-нить в WinRAR, отошёл попить кофе, запускается твой SS - всё, больше ничего не пакуешь - прорисовываешь картинки :( Соверменные vcrads позволяют делать low-cpu-load прораммы - это уж точно - нахрена же нам тогда шина AGP (правда теперь PEG, ну да ладно) и отдельная PCI-плата со своей памятью на борту! Обязательно что-нибудь придумай

← →
ors_archangel © (2007-01-10 22:08) [10]

> В Quake 3, например, загрузка 100%. ID Software - это не
> нормальные люди? :P

Не слышал про такой скринсейвер - Quake 3, может http дашь?

← →
DillerXX © (2007-01-10 22:10) [11]

> ors_archangel ©

Знаем знаем, именно поэтому и озаботился загрузкой

← →
ors_archangel © (2007-01-10 22:31) [12]

> Знаем знаем, именно поэтому и озаботился загрузкой

Делай фиксированный fps - и лучше чтобы настраивался :)
Рисуешь frame (кадр по-русски), при этом засекаешь, сколько времени на него ушло, в простейшем случае через GetTickCount (это WinAPI, в курсе, да?), дальше смотришь, какой Sleep нужно делать между кадрами, чтобы fps был такой-то. Можно ещё поэксперементировать с приоритетом: fps очень крутой получается - опускаем приоритет, подождём немного, проверяем, дальше корректируем время на frame через Sleep. Синхронизироваться с обновлением монитора вроде можно через OpenGl/DirectX, но имхо это слишком часто и ненастраивается

← →
@!!ex © (2007-01-10 22:39) [13]

> и ненастраивается

Настраваеться вроде, хотя я не помню, никогда не интересовался этим.
Sleep - не вариант. Слишком хреново он дейстует.

← →
DillerXX © (2007-01-10 22:55) [14]

На счёт VSync - ничего мне не дало, нашёл в модулях Studio упоминание, но никакого положительного эффекта не дало. Можно пример с его использованием? Если синхронизация в данном случае единственный выход

← →
@!!ex © (2007-01-10 23:00) [15]

Ставь приоритет ниже среднего и забей.

← →
@!!ex © (2007-01-10 23:00) [16]

Ставь приоритет ниже среднего и забей.

← →
DillerXX © (2007-01-10 23:04) [17]

Ок, в таком случае для 100% равномерного движения поставлю GetTickCount в while цикл без слипа.

← →
DillerXX © (2007-01-11 00:06) [18]

const myDelay = 1;
....
while (GetTickCount() - lastTime < myDelay) { }
lastTime = GetTickCount();

Это тормозит точно так же как Sleep(1), никаких отличий во времени, так же дёргается картинка.. Блин, что же делать?

← →
@!!ex © (2007-01-11 00:09) [19]

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

← →
DillerXX © (2007-01-11 00:41) [20]

Нашёл способ как регулировать фпсы вручную.
При Sleep(1) фпс = 65 (VSync"a нету, и видимо в обновление моника не попадаем, видна дискретность).

Без слипа фпс = 1071. Это наверное многовато (улыбка), и значение будет сильно колбасить на разных компутерах.

С применением следующего кода:
const myDelay = 15000000; .... QueryPerformanceCounter(&cur_time); while (cur_time.QuadPart - last_time.QuadPart < myDelay) QueryPerformanceCounter(&cur_time); last_time = cur_time;
С учётом понижения приоритета нити до THREAD_BASE_PRIORITY_IDLE стабильно даёт фпс 200. Видимо оптимальная частота обновления, правда проц грузит на 100%. Но с учётом PRIORITY_IDLE, это по идее не должно мешать другим процессам. Надо всё же будет раскопать VSync, и поставить Sleep(1) с 0% уровнем загрузки.. может всё же есть у кого кода для OpenGL, подкиньте пожалуйста. Или другая идея.

← →
ors_archangel © (2007-01-11 01:45) [21]

> while (cur_time.QuadPart - last_time.QuadPart < myDelay)

С учётом PRIORITY_IDLE в этом цикле нет смысла, в нём вообще нет смысла, потому что такой "холостой" цикл загружает систему так же как и прорисовка или даже больше, лучше тогда уж непрерывно рисовать - "дискретности" не будет. Sleep замораживает поток, полностью отбирая у него процессорное время, а любой цикл, в котором нет Sleep, GetMessage, WaitForXXX или подобных функций (+ некоторые другие) будет обязательно 100% грузить проц, причём не важно что за ерунда внутри этого цикла, твоё:
while (cur_time.QuadPart - last_time.QuadPart < myDelay) QueryPerformanceCounter(cur_time);
или
while (x < 10000000000) x++;
Вот такие мои замечания, имхо, просто цикл-ожидание - бессмысленен:
• Sleep(1000) = 0% CPU Load
• t=GetTickCount(); while (GetTickCount()-t < 1000); = 100% CPU Load
- но оба кода ничерта не делают

← →
rts111 © (2007-01-11 02:05) [22]

Вроде так надо:

...
QueryPerformanceCounter(&cur_time);
while (cur_time.QuadPart - last_time.QuadPart < myDelay) do
begin
Sleep(1); //Sleep(0); ?
QueryPerformanceCounter(&cur_time);
end;
last_time = cur_time;
...

или я вообще не о том?

← →
DillerXX © (2007-01-11 13:12) [23]

> ors_archangel

Тоесть ты предлагаешь мне вообще не пользоваться ожиданием, и рисовать картинку со скоростью 1000 кадров в секунду? Но ведь это значение будет очень сильно колбасить для различных компьютеров. Можно ввести конечно коэффициент прошедшего времени, и на него умножать все движения на экране... Но с помощью моего последнего кода мы стабилизируем прорисовку до 200 герц для любых компьютеров, что мне кажется очень удобно. Кстати, GetMessage окажет тот же эффект что и Sleep? Тоесть слишком сильную задержку?

← →
Da Stranger © (2007-01-11 15:44) [24]

> Можно ввести конечно коэффициент прошедшего времени, и на него умножать все движения на экране... Но с помощью моего последнего кода мы стабилизируем прорисовку до 200 герц для любых компьютеров, что мне кажется очень удобно.

Именно так все и делают, то есть домножают базовую скорость на время между прорисовками. Потому что, если у тебя рисуется в 200 FPS, ещё не значит, что на P3 Celeron будет рисоваться с той же скоростью.

← →
DillerXX © (2007-01-11 18:02) [25]

Хорошо. Сделаю так.

← →
@!!ex © (2007-01-11 22:05) [26]

> DillerXX © (11.01.07 18:02) [25]

Хм... Так у тебя нету привязки ко времени???
Не ожидал...
Не удивительно что при Слипе кадры дергаются...

← →
DillerXX © (2007-01-11 22:21) [27]

> @!!ex

Нету привязки. Я только потом про неё подумал, т.к. писать графические программы начал только позавчера. И об элементарных правилах этого дела не знал. Да и сейчас собственно не знаю, но изучаю :) Рабочая модель уже готова. Нужно исправить в ней выявившиеся деффекты, и затем перевести на динамический фпс (с привязкой ко времени естественно).

> Не удивительно что при Слипе кадры дергаются...

А вот это для меня не очевидно, почему не удивительно? Слип позволяет делать лишь 65 фпс, что недостаточно. Дерганий не будет либо при синхронизации с монитором, либо при уменьшении скорости движения. Но последнее неприятно. А первое так вообще даже не знаю, на сколько я понял это cв-во драйверов конкретной видюхи, а значит ненастраиваемо для меня.

← →
@!!ex © (2007-01-11 22:54) [28]

> Нету привязки. Я только потом про неё подумал, т.к. писать
> графические программы начал только позавчера. И об элементарных
> правилах этого дела не знал. Да и сейчас собственно не знаю,
> но изучаю :) Рабочая модель уже готова. Нужно исправить
> в ней выявившиеся деффекты, и затем перевести на динамический
> фпс (с привязкой ко времени естественно).

Как привязку ко времени делать - в курсе?

> вот это для меня не очевидно, почему не удивительно? Слип
> позволяет делать лишь 65 фпс, что недостаточно. Дерганий
> не будет либо при синхронизации с монитором, либо при уменьшении
> скорости движения. Но последнее неприятно. А первое так
> вообще даже не знаю, на сколько я понял это cв-во драйверов
> конкретной видюхи, а значит ненастраиваемо для меня.

Чтож у тебя за задача, что 65 фпс не достаточно? :))
Вспомни любую игру. Как она себя ведет при 30 кадрах в секунду?
Видно дискретность? Нифига.
Что за проекто делаеш? Хоть скин кинь.
Интересно ж.

> Как привязку ко времени делать - в курсе?

Да потом уже догадался что надо и как, так что вкурсе. Проблема будет при проверке коллизий, т.к. при большом фпсе фактическое передвижение объектов за квант времени будет очень мало, а значит столкновение может просчитаться ещё раз... Я тебе даже могу ехе"s скинуть с 65 фпс и 300 фпс. Заметна разница будет.
http://dillerator.chat.ru/circles_fps_diff.rar скачивать либо качалкой либо FireFox"om или Oper"oй, а то IE что-то глючит на это серве. Там будет вестись output.txt файл с фпс за каждую секунду. Если кому интересно можете посмотреть. Потом добавлю разные красивости, расчёт трения-вращения, текстуру с альфа-каналом, фон, может быть звуки ну и так далее.. очки двойных столкновений, бонусный шарик )) или управление мышкой.
Модель пока начальная, погоняйте примерно 2-3 минуты файл с 300 фпс, там 2 шарика в конце сцепятся и будут вальс танцевать... :)) Кстати прикольно, сотая доля начального угла полёта одного шарика в корне поменяет всю дальнейшую судьбу системы. Терия Хаоса прям...

Забыл добавить :) Особая гордость - расчёт столкновений делал полностью сам, не пользуясь формулой которая валяется на каждом углу (понять её так и не смог, поэтому расчитал сам). Курс векторной алгебры не прошёл напрасно ;)

> > вот это для меня не очевидно, почему не удивительно?
> Слип > позволяет делать лишь 65 фпс, что недостаточно. Дерганий
> > не будет либо при синхронизации с монитором, либо при
> уменьшении > скорости движения. Но последнее неприятно.
> А первое так > вообще даже не знаю, на сколько я понял это
> cв-во драйверов > конкретной видюхи, а значит ненастраиваемо
> для меня.
> Чтож у тебя за задача, что 65 фпс не достаточно?

Присоединяюсь - 30 fps всегда хватало с головой

Проверку столкновений, движение и прочую физику можно делать чаще чем текущий FPS. То есть выбираешь минимальный нужный FPS, обычно это 30, можно 60, помню мне как-то нужна была точность в 1000 FPS для расчёта FPS-независимой инерции, а дальше делаешь так (в процедуре прорисовке кадра):

procedure Proceed(DeltaTime: Single); const MIN_DELTA = 0.1; //10 FPS begin while DeltaTime > MIN_DELTA do begin DoMove(MIN_DELTA); DoCollisionCheck(..); DoSmthElse(MIN_DELTA); DeltaTime := DeltaTime - MIN_DELTA; end; DoMove(DeltaTime); DoCollisionCheck(..); DoSmthElse(DeltaTime); end;

Вы посмотрите файлы, невооружённым глазом с двух метров видно что 65 фпс слишком мало.

1) Запустил версию с 65 фпс. ИМХо все замечательно. Движение плавное, никаких дерганий не заметил.
варианта три:
а) со зрением проблемы(врядли, в своем проекте вроде даже дергание отдельных пикселей вижу)
б) проблемка в разнице оборудования.
в) автор гонит.

2) Версия с 300 фпс благополучно отрисовывала 1 кадр в секунду(по показаниям Fraps"a).

3) пересечение двух сфер - этож вроде банальность, нафиг курс векторной алгебры? Если расстояние между центрами меньше суммы радиусов - значит коллизия есть, сила тож вродь не сложно считается...

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

5) Это вообще что подразумевается?

> [33] DillerXX © (12.01.07 17:11)

circles_fps65 - хорошо работает, плавное движение
circles_fps300 - FPS менее единицы на взгляд...
65FPS - для плавного движения более чем достаточно, ТВ хватает 25FPS. Рывки наверняка из-за нестабильности временных интервалов между кадрами.
А по теме - используй вертикальную синхронизацию. В openGL она вполне управляема. Работает естественно только при двойной или более буферизации.
Сама вертикальная синхронизация у меня сделана так:
if WGL_EXT_swap_control and (FVSync<>wglGetSwapIntervalEXT) then wglSwapIntervalEXT(FVSync); SwapBuffers(FDC);
Это в конце отрисовки. FVSync - целочисленная, при 1 вертикальная синхронизация включена, при 0 - выключена.

А зафиг ее каждый кадр трогать?
Вроде достаточно один раз установиьт в начале работы приложения.

> [36] @!!ex © (13.01.07 09:42)

У меня такие же сомнения... Зачем сделал именно так уже и сам не помню... Вроде какая-то причина была.

Sleep(0) попробуйте еще

я что-то не понял, CIRCLES_fps300.exe дает нагрузку от нуля до двух процентов на проц, CIRCLES_fps65.exe от нуля до единицы. Что за проблему вы обсуждаете?

> circles_fps300 - FPS менее единицы на взгляд...

> Версия с 300 фпс благополучно отрисовывала 1 кадр в секунду(по
> показаниям Fraps"a).

Я не понял, тоесть 1 обновление экрана за секунду?! Ужас... Как это вообще может быть...

> Sleep(0) попробуйте еще

Не помогает.

> я что-то не понял, CIRCLES_fps300.exe дает нагрузку от нуля
> до двух процентов на проц

Фигасе, как это как может быть... Там же не слипов, должна быть загрузка 100%. Как у тебя с движением в обоих программах?

Загрузка процессора Найти похожие ветки