- Aroch
- Постоялец
Daniil Petrov
> А как популярные движки в этой ситуации? Нормально себя ведут?
Популярные движки прошлого timeGetTime старались использовать, а не QueryPerformanceCounter, "во избежание". Как сейчас - не знаю.
Плюс, мониторили постоянно расхождение времени для сетевой игры и дополнительно синхронизировались на ходу, при необходимости.
Для сингл игр рваный ритм работы таймеров можно было игнорировать, визуально оно не заметно.
timeGetTime тоже не 100% надежен, тоже тики пропадают, но все же более стабилен в плохих случаях.
Геймер в любом случае прав, не свойственно человеку считать виноватым себя, во что бы не вляпался. Перебрехиваться с ним из-за этого?
Zab
> Для сингл игр рваный ритм работы таймеров можно было игнорировать, визуально оно не заметно.
Так а в чём тогда проблема? Причём я у себя даже скачков не заметил, часы ровно идут, дельта компенсирует скачки FPS, жизнь налаживается :)
Daniil Petrov
> Так а в чём тогда проблема?
Проблема когда нужна экстраполяция. Ты же не можешь знать где находятся сейчас симулируемые на других компах объекты, знаешь где они находились на указанное время и пытаешься рассчитать их нынешние положение. Тогда они не будут скакать на твоем компе. А для этого чужой замер времени тебе должен что-то говорить, время приходится синхронизировать.
Zab
> Ты же не можешь знать где находятся сейчас симулируемые на других компах объекты
Меня интересует исключительно сингл плейер, так что это уже не мой головняк :)
Daniil Petrov
> Причём я у себя даже скачков не заметил, часы ровно идут
Они и должны идти ровно, если это часы. Сейчас на мамках есть соответствующая аппаратура, но она недостаточно стандартизована, не обязана быть везде. Установленные драйвера обеспечивают к ней доступ. Если же доступа нет, высокоточный таймер работает через rdtsc, со всеми вытекающими последствиями. На современных компах это неприемлемо, по сути, ибо ядер несколько, получаешь ты один из нескольких независимых счетчиков попеременно. Плюс, частота может прыгать более чем в десяток раз, при переходе нотбуков в режим экономии.
Скачки на via-чипсетах имели другую природу. Предполагаю что кривой виавский dma так разрешал конфликты по доступу к памяти, блокируя тактовую частоту процессору.
Zab
> На современных компах это неприемлемо
На "современных компах", уже лет 5 точно, rdtsc возвращает монотонно увеличивающийся счётчик вне зависимости от ядра и режима процессора (во всех C и P состояниях).
Ghost2
Т.е. проблем с высокоточными таймерами не должно быть, да?
Ghost2
А если два слота под процессоры? Тоже один счетчик?
Да и в одном слоте обычно слоеный пирог из независимых кристаллов процессоров. Они как-то объединяют свои счетчики?
И зачем им счетчики объединять, если чипсеты материнских плат содержат высокоточные таймеры? С доступом к ним какие-то проблемы?
Честно говоря, я ожидал что новые версии винды опознают при установке типовые таймеры и задействуют драйвера из своего дистрибутива, тем самым снимая проблемы в большинстве случаев. Но это все предположения, я не знаю так ли это.
Zab
> А если два слота под процессоры? Тоже один счетчик?
Думаю, что ты можешь сам догадаться. Есть ОС, она должна абстрагировать уровень приложений от этих тонкостей.
> обычно слоеный пирог из независимых кристаллов процессоров
Можно пример?
> Они как-то объединяют свои счетчики?
Если ты про ядра, то так же, как объединяют шину памяти, линии PCI Express и всю остальную периферию на кристалле.
> С доступом к ним какие-то проблемы?
Проблема состоит хотя бы в том, что нужно лезть за пределы процессора.
Daniil Petrov
> Т.е. проблем с высокоточными таймерами не должно быть, да?
Проблемы могут быть всегда с чем угодно. Используй QueryPerformanceCounter и не думай об этих проблемах.
Zab
Да не было с квериПерформансКаунтер никогда проблем. Получаешь афинити маску текущего потока, вызываешь сетТхреадАффинитиМаск на требуемое ядро, вызываешь счётчик перформанса, восстанавливаешь афинити маск текущего потока.
*Lain*
> Да не было с квериПерформансКаунтер никогда проблем.
Когда-то были точно. Но сейчас даже в SDL (с версии 2) его заюзали. Написали комментарий, что штучка стрёмная, но раз используется во многих играх, то чем мы хуже.
*Lain*
> Да не было с квериПерформансКаунтер никогда проблем. Получаешь афинити маску
> текущего потока, вызываешь сетТхреадАффинитиМаск на требуемое ядро, вызываешь
> счётчик перформанса, восстанавливаешь афинити маск текущего потока.
Я больше скажу, скорее всего проблем с QueryPerformanceCounter не будет даже если с масками ничего не делать, потому как QueryPerformanceCounter работать будет не через rdtsc.
Вот и хотелось бы знать, на винде семерке и старше проблем никогда не будет или все же там надо следить чтобы драйвера были установлены, как на старых системах...
*Lain*
> вызываешь сетТхреадАффинитиМаск на требуемое ядро, вызываешь счётчик перформанса
И что по твоему при этом происходит, если поток выполняется на другом ядре?
Aroch
> мало кому нужна именно точная дельта между кадрами, обычно усредняют за последние n-цать милисекунд.
А я использую именно точную дельту для компенсации скачков FPS, пока это касается только управления, но, как я понимаю, это будет нужно и для анимации.
Daniil Petrov
и чем тебе поможет точная дельта? Если дельта будет скакать то и всё остальное у тебя будет заметно дергаться, анимации как самый наглядный пример. Точная дельта нужна при воспроизведении звука, но звук по хорошему в отдельный поток выносят поэтому там рывков особо и нет.
Тема в архиве.