Навигация
Поддержать материально
Steam Greenlight

Логотипы
Медальки
Гость
Имя

Пароль



Вы не зарегистрированны?
Нажмите здесь для регистрации.

Забыли пароль?
Запросите новый здесь.
Темы форума
185 - RPG
9.02.2024
 Vaskrol
В каком банке открыт…
24.01.2024
 Darthman
185 - ?
30.12.2023
 Mefistofel
TESTAMENT - Тактичес…
15.11.2023
 KregHek
WoL
13.10.2023
 Darthman
RES - Движок для пик…
27.09.2023
 rimush
177 - One Button Str…
20.09.2023
 VoroneTZ
JS 13k contest
13.09.2023
 Mefistofel
184 - Arcade II
14.08.2023
 tiger1025
184 - ?
14.07.2023
 Kaps
Сейчас на сайте
Гостей: 1
На сайте нет зарегистрированных пользователей

Пользователей: 1,788
новичок: svetalebedeva199
Обсуждение «3D Virtual Pool [Free Fall]»
Страница 3 из 3 < 1 2 3
Zer0
Avatar пользователя

Опубликовано 18.12.2016 22:21 (7 лет назад)    #
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 жить нормально. Заведи поток отрисовки, научись с ним синхронизироваться и рисовать все доступное время но не больше чем реальных кадров монитора в секунду. Выставь приоритет потока физики над рендером и поиграйся с тяжелой графикой чтоб понять как потоки взаимодействуют и как сделать так чтоб рендерер не блочил физику. От этого будет несомненно больше пользы.
Zer0
Avatar пользователя

Опубликовано 18.12.2016 22:28 (7 лет назад)    #
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 < 1 2 3
Перейти на форум:
Конкурсы
Открытые конкурсы:
Активных нет
Недавние конкурсы:
 185 - RPG XII
 184 - Arcade II
 183 - Novel
 182 - RPG XI
 181 - Pixel Craft 128
 Все конкурсы
Случайная игра
Мини-чат
Вам необходимо залогиниться.

Архив чата

25,321,732 уникальных посетителей

Создано на базе русской версии PHP-Fusion copyright © 2003-2006 by Nick Jones.
Released as free software under the terms of the GNU/GPL license.