Войти
ПрограммированиеФорумОбщее

Высокоточный таймер на std::chrono (2 стр)

Страницы: 1 2 3 4 5 Следующая »
#15
21:48, 30 янв 2018

Daniil Petrov
> А как популярные движки в этой ситуации? Нормально себя ведут?
Популярные движки прошлого timeGetTime старались использовать, а не QueryPerformanceCounter, "во избежание". Как сейчас - не знаю.
Плюс, мониторили постоянно расхождение времени для сетевой игры и дополнительно синхронизировались на ходу, при необходимости.
Для сингл игр рваный ритм работы таймеров можно было игнорировать, визуально оно не заметно.

timeGetTime тоже не 100% надежен, тоже тики пропадают, но все же более стабилен в плохих случаях.

Геймер в любом случае прав, не свойственно человеку считать виноватым себя, во что бы не вляпался. Перебрехиваться с ним из-за этого?

#16
3:11, 31 янв 2018

Zab
> Для сингл игр рваный ритм работы таймеров можно было игнорировать, визуально оно не заметно.
Так а в чём тогда проблема? Причём я у себя даже скачков не заметил, часы ровно идут, дельта компенсирует скачки FPS, жизнь налаживается :)

#17
3:38, 31 янв 2018

Daniil Petrov
> Так а в чём тогда проблема?
Проблема когда нужна экстраполяция. Ты же не можешь знать где находятся сейчас симулируемые на других компах объекты, знаешь где они находились на указанное время и пытаешься рассчитать их нынешние положение. Тогда они не будут скакать на твоем компе. А для этого чужой замер времени тебе должен что-то говорить, время приходится синхронизировать.

#18
5:14, 31 янв 2018

Zab
> Ты же не можешь знать где находятся сейчас симулируемые на других компах объекты
Меня интересует исключительно сингл плейер, так что это уже не мой головняк :)

#19
5:52, 31 янв 2018

Daniil Petrov
> Причём я у себя даже скачков не заметил, часы ровно идут
Они и должны идти ровно, если это часы. Сейчас на мамках есть соответствующая аппаратура, но она недостаточно стандартизована, не обязана быть везде. Установленные драйвера обеспечивают к ней доступ. Если же доступа нет, высокоточный таймер работает через rdtsc, со всеми вытекающими последствиями. На современных компах это неприемлемо, по сути, ибо ядер несколько, получаешь ты один из нескольких независимых счетчиков попеременно. Плюс, частота может прыгать более чем в десяток раз, при переходе нотбуков в режим экономии.

Скачки на via-чипсетах имели другую природу. Предполагаю что кривой виавский dma так разрешал конфликты по доступу к памяти, блокируя тактовую частоту процессору.

#20
9:32, 31 янв 2018

Zab

> На современных компах это неприемлемо
На "современных компах", уже лет 5 точно, rdtsc возвращает монотонно увеличивающийся счётчик вне зависимости от ядра и режима процессора (во всех C и P состояниях).

#21
9:57, 31 янв 2018

Ghost2
Т.е. проблем с высокоточными таймерами не должно быть, да?

#22
10:02, 31 янв 2018

Ghost2
А если два слота под процессоры? Тоже один счетчик?
Да и в одном слоте обычно слоеный пирог из независимых кристаллов процессоров. Они как-то объединяют свои счетчики?
И зачем им счетчики объединять, если чипсеты материнских плат содержат высокоточные таймеры? С доступом к ним какие-то проблемы?

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

#23
11:03, 31 янв 2018

Zab

> А если два слота под процессоры? Тоже один счетчик?
Думаю, что ты можешь сам догадаться. Есть ОС, она должна абстрагировать уровень приложений от этих тонкостей.

> обычно слоеный пирог из независимых кристаллов процессоров
Можно пример?

> Они как-то объединяют свои счетчики?
Если ты про ядра, то так же, как объединяют шину памяти, линии PCI Express и всю остальную периферию на кристалле.

> С доступом к ним какие-то проблемы?
Проблема состоит хотя бы в том, что нужно лезть за пределы процессора.

Daniil Petrov

> Т.е. проблем с высокоточными таймерами не должно быть, да?
Проблемы могут быть всегда с чем угодно. Используй QueryPerformanceCounter и не думай об этих проблемах.

#24
11:04, 31 янв 2018

Zab
Да не было с квериПерформансКаунтер никогда проблем. Получаешь афинити маску текущего потока, вызываешь сетТхреадАффинитиМаск на требуемое ядро, вызываешь счётчик перформанса, восстанавливаешь афинити маск текущего потока.

#25
11:58, 31 янв 2018

*Lain*
> Да не было с квериПерформансКаунтер никогда проблем.
Когда-то были точно. Но сейчас даже в SDL (с версии 2) его заюзали. Написали комментарий, что штучка стрёмная, но раз используется во многих играх, то чем мы хуже.

#26
12:05, 31 янв 2018

*Lain*
> Да не было с квериПерформансКаунтер никогда проблем. Получаешь афинити маску
> текущего потока, вызываешь сетТхреадАффинитиМаск на требуемое ядро, вызываешь
> счётчик перформанса, восстанавливаешь афинити маск текущего потока.
Я больше скажу, скорее всего проблем с QueryPerformanceCounter не будет даже если с масками ничего не делать, потому как QueryPerformanceCounter работать будет не через rdtsc.
Вот и хотелось бы знать, на винде семерке и старше проблем никогда не будет или все же там надо следить чтобы драйвера были установлены, как на старых системах...

#27
12:31, 31 янв 2018

*Lain*

> вызываешь сетТхреадАффинитиМаск на требуемое ядро, вызываешь счётчик перформанса
И что по твоему при этом происходит, если поток выполняется на другом ядре?

#28
2:51, 1 фев 2018

Aroch
> мало кому нужна именно точная дельта между кадрами, обычно усредняют за последние n-цать милисекунд.
А я использую именно точную дельту для компенсации скачков FPS, пока это касается только управления, но, как я понимаю, это будет нужно и для анимации.

#29
3:40, 1 фев 2018

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

Страницы: 1 2 3 4 5 Следующая »
ПрограммированиеФорумОбщее

Тема в архиве.