|
Демонстрация попиксельной физики
|
|
| DivES | Дата: Среда, 17 Июня 2020, 07:34 | Сообщение # 21 |
заслуженный участник
Сейчас нет на сайте
| puksus4, 
Ну в играх как? В видео настройках нам дают возможность выбрать, включать вертикальную синхронизацию или нет.
Вот, а я спрашиваю о том, как думаешь, есть ли такие проекты, в которых разработчики зарахдкодили vsync = true; так, что вертикальная синхронизация включена изначально и не может быть выключена. И всё строится вокруг этих стабильных шестидесяти (не берём в расчёт современные мониторы) кадров.
Сообщение отредактировал DivES - Среда, 17 Июня 2020, 07:34 |
|
|
| |
| puksus4 | Дата: Среда, 17 Июня 2020, 07:42 | Сообщение # 22 |
|
частый гость
Сейчас нет на сайте
| DivES, Ну игры щас кто попало делает. Уверен есть даже те, кто лочат фпс с целью избавиться от зависимости от дельта тайма))
Либо исходя из нагрузки на комп вырубают, или чтоб избавиться от разрывов картинки. Кароч скока игроделов - столько и игр. Найдутся всякие. Ктото просто посчитает что вот я уверен что всинк нужен\не нужен и мне пофиг чо думаешь ты, дорогой мой пользователь, так что хрен отключишь\включишь)
Да и важно ли это? Серьёзные дядьки обычно дают возможность нажать галку)
|
|
|
| |
| DivES | Дата: Среда, 17 Июня 2020, 07:45 | Сообщение # 23 |
|
заслуженный участник
Сейчас нет на сайте
| puksus4, а delta time — это?
|
|
|
| |
| puksus4 | Дата: Среда, 17 Июня 2020, 07:48 | Сообщение # 24 |
|
частый гость
Сейчас нет на сайте
| длительность кадра.
Простейшее использование:
speed += acceleration * dt;
pos += speed * dt;
Это не абсолютно полностью верно наверн, но достаточно точно. За полной точностью надо проинтегрировать. Возможно то же самое выйдет.
Я использую в качестве этой величины длительность предыдущего кадра по той простой причине что длительность текущего неизвестна
Даже если хотите юзать константное капнутое время кадра - лучше юзайте дельта тайм. Иначе поменяете кап - получите другую игру.
Сообщение отредактировал puksus4 - Среда, 17 Июня 2020, 07:51 |
|
|
| |
| DivES | Дата: Среда, 17 Июня 2020, 07:56 | Сообщение # 25 |
|
заслуженный участник
Сейчас нет на сайте
| puksus4, а я от количества кадров отталкиваюсь.
В случае с тайловой анимацией, например. На цикл анимации уходит, например, 16 кадров. Всего 4 тайла, значит 4 кадра на тайл.
Если отталкиваться от длительности кадра, то может случаться так, что на цикл анимации будет уходить или 15 (в случае, если кадры по длительности оказались короче ожидаемого) или 17 (если оказались длиннее) кадров.
Так что я решил отталкиваться именно от количества кадров, а не от длительности кадра. Обсуждал этот вопрос с несколькими людьми, так к общему мнению и не пришли. Сам что скажешь?
|
|
|
| |
| puksus4 | Дата: Среда, 17 Июня 2020, 08:04 | Сообщение # 26 |
|
частый гость
Сейчас нет на сайте
| DivES, Анимация длится некоторое время. Оттолкнётесь от количества кадров - получите что длительность анимации будет варьироваться. Получите просадку фпс относительно капа - весь мир замедлится.
С дельтатаймом высчитываете какой кадр отобразить сейчас. Если фреймтайм слишком большой и некоторые кадры из анимации пропустились - это абсолютно нормально.
Есть правда такие штуки как физика. Она скорее всего будет работать с константным фреймрейтом по схеме: ждём пока не накопится 1\60 секунды. Накопилось - при вызове делаем шаг симуляции и сбрасываем счётчик, иначе не делаем ничего вообще.
Отсюда следует что если вы допустим закапите фпс на 100, будете при этом иметь физику работающую на 60 фпс - то в пределах от 60 до 100 кадров в секунду у вас мир будет абсолютно одинаково себя вести
А если у вас скажем 30 кадров в секунду, то воизбежание взрыва перфоманса (как бы если у нас проблемы с перфомансом - нелогично нагружать его ещё больше), физика сделает только 1 шаг симуляции а не 2 за кадр. Тут уже пойдут несостыковки. Либо учитывайте это в своём дельта тайме и замедляйте всё, либо миритесь что при просадках физика может работать медленнее чем ваши другие расчёты.
В буллет физике можно врубить и динамичный фреймтайм, но сие не рекомендуют.
Сообщение отредактировал puksus4 - Среда, 17 Июня 2020, 08:05 |
|
|
| |
| DivES | Дата: Среда, 17 Июня 2020, 08:09 | Сообщение # 27 |
|
заслуженный участник
Сейчас нет на сайте
| Цитата puksus4 (  ) ждём пока не накопится 1\60 секунды
У меня таким образом кап и устроен. И всё: физика (будущая  ), анимация и движение, — происходит в одном кадре. Затем выжидаем оставшееся до 1/60 время и новый кадр.
|
|
|
| |
| puksus4 | Дата: Среда, 17 Июня 2020, 08:12 | Сообщение # 28 |
|
частый гость
Сейчас нет на сайте
| Цитата puksus4 ( ) Даже если хотите юзать константное капнутое время кадра - лучше юзайте дельта тайм. Иначе поменяете кап - получите другую игру.
Как я уже сказал 2 проблемы:
1) А вот захотите 75 вместо 60 - и у вас всё что в мире есть - ускорится.
2) при просадке фпс весь мир замедлится
Введите делтьтатайм - мороки с ним не особо много, зато с большего подобные проблемы решаются. И с этого момента вам с точки зрения игровой логики становится пофиг, есть кап фпс или нету и какая его величина.
Сообщение отредактировал puksus4 - Среда, 17 Июня 2020, 08:13 |
|
|
| |
| DivES | Дата: Среда, 17 Июня 2020, 08:23 | Сообщение # 29 |
|
заслуженный участник
Сейчас нет на сайте
| Я делал так: сначала реализовывал ту же анимацию, например, при 60 fps. Вот у меня длительность тайла была равна 8-ми кадрам при 60 кадрам в секунду.
1) Тогда, если бы я выставил кап в 75 fps, произошёл бы перерасчёт длительности тайла по формуле tileDuration = 8 * 75 (а вообще — текущий fps) / 60.0.
2) И исходя из пункта (1) мир не замедлялся бы, а просто становился бы менее плавным, чем дальше значение текущего fps уходило бы от нужного.
Но вообще да, теперь я, кажется, понял, почему следует попробовать оттолкнуться от дельта тайма:
Цитата puksus4 ( ) И с этого момента вам с точки зрения игровой логики становится пофиг, есть кап фпс или нету и какая его величина.
Поэкспериментирую, в общем, спасибо!
|
|
|
| |
| puksus4 | Дата: Среда, 24 Июня 2020, 14:30 | Сообщение # 30 |
|
частый гость
Сейчас нет на сайте
| Сделяль дымочек. Это правда уже не относится к пиксельной физике, ну да ладно))
ВеДос
Как сделано:
1) Дым испускают частицы
2) Для дыма есть сетка с размером ячейки 4х4 пикселя покрывающая весь экран и даже чучуть больше
3) каждый кадр в отдельном компут шейдере частицы фигачат чучуть дыма в сий буфер в нужной позиции
4) периодически вызывается компут шейдер отвечающий за распространение дыма.
Берём дым из соседних тайлов, из текущего, смешиваем и также уменьшаем его плотность чтоб он пропадал. Пишем в отдельный буфер
5) свапаем буфера (двойная буферизация для дыма, поскольку писать "по месту" здесь не получится)
Рендер.
6.1) При инициализации создаём вертексный буфер по вертексу на каждую точку сетки дыма. Но при этом в вертексы ничего не кладём вообще. Вертексы как бы есть, но они виртуальные чтоли.
6.2) Фигачим индексный буфер, для того чтобы описать каждый треугольник сетки. У меня получилось что в индексном буфере лежит ~700000 значений
6.3) В вертексном шейдере поскольку вертексы у нас описывают вертексы сетки, а не ячейки, берём из буфера дыма соседние для точки вершины и усредняем. Поскольку в вертексах у нас ничо нет, определяем позицию точки через SV_VertexId
6.4) В пиксельном шейдере тупо выводим цвет как есть исходя из количества дыма и его цвета с полупрозрачным блендом.
Кстати дым может быть произвольного цвета в каждой точке. Можно спамить зелёный, красный, любой дым, и он будет смешиваться и растворяться друг в друге.
Сообщение отредактировал puksus4 - Среда, 24 Июня 2020, 14:41 |
|
|
| |
