У Рихтера:

Цитата

Процессы инертны Чтобы процесс что-нибудь выполнил, в нем нужно создать поток Именно потоки отвечаю за исполнение кодя, содержащегося в адресном про странстве процесса В принципе, один процесс может владеть несколькими потока ми, и тогда они "одновременно" исполняют код в адресном пространстве процесса. Для этого каждый поток должен располагать собственным набором регистров про цессора и собственным стеком В каждом процессе есть минимум один поток. Если бы у процесса не было ни одного потока, ему нечего было бы делать на этом свете, и система автоматически уничтожила бы его вместе с выделенным ему адресным про странством. Чтобы всс эти потоки работали, операционная система отводит каждому из них определенное процессорное время. Выделяя потокам отрезки времени (называемые квантами) по принципу карусели, она создает тем самым иллюзию одновременного выполненияпотоков

Под квантом понимается временной отрезок, в течении которого управление будет переданно процессу и не будет выполняться проверка о необходимости передачи управления другому процессу. Как расперделяется время медлу потоками внутри процесса - вопрос немножко другой. Неделимым может быть отрезок и в 2 кванта и более. Обычно квант - верменной промежуток, меньше которого квантовать время не отимально. Это все грубо и достаточно неточно, но как суме, так и сказал. ...

Почитал тут посты, возникло предложение (не пинайте ногами сильно): что мешает перерисовывать кадр только когда это надо ? Например, мышка не двигалась, объекты в сцене не изменили своё положение, эффекты "молчат" -- нафига рисовать "поверх" того же самого ?

З.Ы, можно простым способом сделать: глобальная статическая переменная типа HANDLE с каким-нибудь объектом синхронизации, и ждущий поток. Поток рендерит кадр, потом "засыпает" в WaitForSingleObject. Если другие потоки, к примеру, передвинули камеру или объект в сцене - они сигналят первому потоку, он просыпается и рендерит ещё один кадр .

Цитата(Tror @ 25.10.2005, 13:28)

Можно ли ограничивать fps каким то определённым значением, а всё оставшееся время использовать для расчётов. И, вообще, целесообразно ли исползовать многопоточность в графических приложениях. Если что не так поправьте.

Именно это и получится, если сделать как я предложил. Сигналить-то можно с любой требуемой скоростью.

Даа , я тут посмотрю придётся мне немног попотеть, чтоб разобраться во всём том, что
здесь написали. Большое всем спасибо -- дали пищу для размышлений. Всё, пошёл разбираться.

о распределении времени:
я просто представил себе два возможных способа распределения времени:
1. глобально между процессами (независимо от количества активных потоков) и внутри них уже свои локальные шедулеры, которые делят полученное время между потоками
2. просто между процессами

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

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

Цитата

Почитал тут посты, возникло предложение (не пинайте ногами сильно): что мешает перерисовывать кадр только когда это надо ? Например, мышка не двигалась, объекты в сцене не изменили своё положение, эффекты "молчат" -- нафига рисовать "поверх" того же самого ?

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

Цитата(mr @ 25.10.2005, 19:05)

Почитал тут посты, возникло предложение (не пинайте ногами сильно): что мешает перерисовывать кадр только когда это надо ?

Читаем внимательно пердыдущую страницу:

Цитата(DENNN @ 25.10.2005, 15:05)

сцена перерисовывается в двух случаях: 1)По требованию ОС перерисовать часть окна или все окно целиком. 2)Если изображение изменилось

В общем разобрался я в чем тут дело. Оказывается весь сыр-бор из-за того как мы выбираем
сообщения из очереди. Если использовать PeekMessage, то в таскмане отображается
использование проца на 100%, если же использовать GetMessage, то всё в порядке. Но тут возникает проблемка: при использовании PeekMessage всё в норме, а при GetMessage рабочая область программы закрашивается тем что было до нее на экране(окна, десктоп и тд). Посмотрел
в win32sdk help, там в ремарках к PeekMessage написано только то что он не ждёт окончания обработки сообщения в отличие от GetMessage. Глубже мне не удалось разобраться ввиду отсутствия MSDN(но вроде обещали подогнать), а пользоваься им в онлайне нет возможности.


То maxim1000:
С днём рождения

Это сообщение отредактировал(а) Tror - 26.10.2005, 21:01