3D Virtual Pool [Free Fall] :: Отчетные темы :: Форум

VanyaR1 написал:
я просмотрел кучу способов реализации циклов, но этот показался более правильным,
но MS_PER_UPDATE пока ставлю 1000/60, а рекомендуют устанавливать от возможностей системы, не не понятно как.

Чтоб разобраться надо понять какая именно задача решается.

Есть следующие подходы:
- Фиксированный шаг Physics (в большинстве случаев клиент-серверных приложух и в случаях когда хватает 20 обновлений физики в секунду)
- Плавающий шаг Physics (в однопользовательских играх где более частые обновления дают более качественную картинку и саму игру)
- Фиксированный шаг Renderer (обычно привязывается в vsynс, моменту когда можно обновлять страницы видеопамяти, и при этом не вызвать видимый разрыв из двух разных кадров) хорошо работает в казуалочках где fps даже на самых тупых компах редко бывает меньше 60. Нет смысла рисовать кадров больше чем можно отобразить на мониторе, это пустое сжигание энергии.
- Плавающий шаг Renderer вниз - для игр где нарисовать 30 кадров в секунду стабильно может быть большой проблемой даже на средних компах, там адаптивность рендера в нижнюю сторону может спасти от лагов физики;

Renderer может рисовать кадров больше чем обсчитывает физика за счет интерполяции анимции по скоростям (и ускорениям для настоящих маньяков)
Если физика и renderer жестко связаны - то рисовать больше кадров в renderer смысла нет.

Сделай самый простой вариант:
- Отсчитал время с момента окончания обработки последнего кадра, нашел дельту;
- Пересчитал физические величины с учетом дельты;
- Нарисовал кадр и остался ждать vsync;

Накопление времени для renderer это так себе идея, особенно в однопользовательской игре с самой простой физикой. Будут рывки при потере кадров.

Если хочешь по фен-шую то делай несколько потоков, и постарайся сделать так чтоб поток физики отрабатывал свой шаг за выделенное время, и умел в пределах от 20 до 100 physical frames per second жить нормально. Заведи поток отрисовки, научись с ним синхронизироваться и рисовать все доступное время но не больше чем реальных кадров монитора в секунду. Выставь приоритет потока физики над рендером и поиграйся с тяжелой графикой чтоб понять как потоки взаимодействуют и как сделать так чтоб рендерер не блочил физику. От этого будет несомненно больше пользы.

Опубликовано 18.12.2016 22:28 (9 лет назад) #

ZblCoder написал:
не лучше. sleep странная вещь, работает вроде не стабильно.
WaitForSingleObject - для ожидания,
QueryPerformanceFrequency - Количество итераций процессора в секунду
QueryPerformanceCounter - текущее число итераций процессора

QueryPerformanceFrequency в начале получаешь количество итераций. После в начале и конце таймера таймера вызываешь QueryPerformanceCounter. Разницу делишь на результат QueryPerformanceFrequency и получаешь время работы кода в секунду. И уже отдаешь в WaitForSingleObject рассчитанное время ожидания.

Есть два таймера: https://en.wikipedia.org/wiki/Time_Stamp_Counter и https://en.wikipedia.org/wiki/High_Precision_Event_Timer на какой сам сядешь... ? :)

редакция от Zer0, 20.12.2016 14:07

Страница 3 из 3

Перейти на форум: