HLFX.Ru Forum (https://hlfx.ru/forum/index.php)
- Paranoia 2:Savior (https://hlfx.ru/forum/forumdisplay.php?forumid=38)
-- Полный исходный код P2:Savior 1.51, включая компиляторы и модельвьювер (https://hlfx.ru/forum/showthread.php?threadid=5552)
Отправлено ncuxonaT 29-03-2021 в 14:59:
Просто выкинуть ACT_RESET нельзя?
Отправлено Ku2zoff 29-03-2021 в 15:16:
Цитата:
Дядя Миша писал:
Потому что 10 - маловато. А 20 хорошо делится и на 60 и на 100. Без остатка.
ЕМНИП, то в халфе как раз сервер тчинкает 10 раз в секунду, отсюда 10 серверных фпс.
Дядя Миша насколько вважно, чтобы герцовка монитора (клиентский фпс) была кратной серверному фпс? И как себя в теории поведут физика и AI при клиентских фпс свыше 100? 120, 144, например? Не за горами момент, когда такие матрицы массово войдут в обиход. Я уже где-то видел зависимость pev->yaw_speed от фпс - чем выше, тем медленнее монстр поворачивается. Из-за умножения на gpGlobals->frametime.
Отправлено Aynekko 29-03-2021 в 15:39:
Цитата:
Ku2zoff писал:
Я уже где-то видел зависимость pev->yaw_speed от фпс - чем выше, тем медленнее монстр поворачивается.
В стим-версии халфы это уже пофиксили. Вроде благодаря Солокиллеру - брал код с гитхаба.
Помимо этого обратил внимание на пару других вещей - на высоких фпс функция Draw в худе быстрее выполняется (я там двигаю один спрайт с помощью y +=1, поэтому обратил внимание). Повороты trigger_camera так же стали быстрыми - и там все тот же фреймтайм.__________________
Мой мод на Xash
Отправлено Дядя Миша 29-03-2021 в 15:58:
Цитата:
ncuxonaT писал:
Просто выкинуть ACT_RESET нельзя?
Из энумератора - конечно нельзя. Из механизма смены анимаций думаю можно, если ориентироваться на его устройство в хл2. Они там много багов посадили, но в хл2 это уже исправлено. С Кутузовым попробуй объединится, он много работал над монстрами, наверняка кое-что знает.
Цитата:
Ku2zoff писал:
ЕМНИП, то в халфе как раз сервер тчинкает 10 раз в секунду, отсюда 10 серверных фпс.
в халфе клиент-сервер тикают одинаково.
Цитата:
Ku2zoff писал:
насколько вважно, чтобы герцовка монитора (клиентский фпс) была кратной серверному фпс?
меньше ошибок накапливаться будет в дробной части. Хуже всего периодическая дробь.
Цитата:
Ku2zoff писал:
Из-за умножения на gpGlobals->frametime.
Ну вот был бы там чисто серверный фреймтайм, так и не было бы проблемы.
Добавлено 29-03-2021 в 18:58:
Цитата:
Aynekko писал:
я там двигаю один спрайт с помощью y +=1, поэтому обратил внимание
у тебя код не time-based.__________________
My Projects: download page
F.A.Q по XashNT
Блог разработчика в телеграме
Цитата:
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено Aynekko 29-03-2021 в 16:09:
Цитата:
Дядя Миша писал:
Ну вот был бы там чисто серверный фреймтайм, так и не было бы проблемы.
Сейчас залез в код камеры и заменил ->frametime на 0.01
C++ Source Code:
vecAvel.x = dx * SnapSpeed * 0.01; |
vecAvel.y = dy * SnapSpeed * 0.01; |
Скорость камеры стала одинаковой (кажись) на всех фпс (сверял 60 и 240). Надо было раньше так сделать.
До этого еще смотрел, чему равен этот самый frametime. На 60 фпс он 0.0167, на 240 кажется 0.0045. Отсюда все эти разности в поведении…__________________
Мой мод на Xash
Отправлено Ku2zoff 29-03-2021 в 16:24:
Цитата:
Aynekko писал:
я там двигаю один спрайт с помощью y +=1
Цитата:
Дядя Миша писал:
у тебя код не time-based.
Aynekko умножай значение на клиентский фреймтайм или gHUD.m_flTimeDelta. Тогда при разных фпс спрайт будет проходить одинаковое расстояние за одинаковое время. Это типичная ошибка - что-то анимировать, считать или перемещать, используя фиксированные значения. Умножение на фреймтайм компенсирует погрешность при разной частоте кадров.
Добавлено 29-03-2021 в 23:22:
Цитата:
Aynekko писал:
Скорость камеры стала одинаковой (кажись)
Где-то на гитхабе был фикс avelocity для камеры, погугли. Это из той же оперы, что и фикс yaw_speed для монстряков.
Добавлено 29-03-2021 в 23:24:
Цитата:
Aynekko писал:
сверял 60 и 240
На 240 фпс матриц нет в природе. Они выдают 120-144, значения выше - фикция, матрица отвечает видимокарте и системе, что рисует 240, но по факту в два раза меньше. Чтобы нарот покупал "игровые" недобуки за космические ценники. Может быть, ситуация уже изменилась, и есть мониторы, которые выдают реальные 240 герц, но тут надо смотреть на тип матрицы. Цем лучше цветопередача - тем выше время отклика пикселя.
Отправлено Aynekko 29-03-2021 в 16:35:
Цитата:
Ku2zoff писал:
Тогда при разных фпс спрайт будет проходить одинаковое расстояние за одинаковое время.
Ага, спасибо, сейчас помимо этого еще пофиксил плавный зум арбалета у себя. Несмотря на то, что у меня стоял nexthink = gpGlobals->time + 0.01, зум все равно был быстрее на больших фпс. Задал временную переменную, а think поставил просто каждый кадр и все пришло в норму.
Цитата:
Ku2zoff писал:
Где-то на гитхабе был фикс avelocity для камеры, погугли.
Видел я его, это этот что ли?
https://github.com/ValveSoftware/halflife/issues/2924
Однако ж, там Солокиллер сделал то же самое 
C++ Source Code:
pev->avelocity.x = dx * 40 * 0.01; |
pev->avelocity.y = dy * 40 * 0.01; |
Цитата:
Ku2zoff писал:
На 240 фпс матриц нет в природе. Они выдают 120-144, значения выше - фикция
Это хорошая новость, ящитаю. А я задал этот порог на случай, если у кого-то будет такой моник. У меня так-то 75 Гц, но все равно тестирую очень высокий фпс на предмет всяких косяков.__________________
Мой мод на Xash
Отправлено Ku2zoff 29-03-2021 в 16:43:
Цитата:
Aynekko писал:
помимо этого еще пофиксил плавный зум арбалета у себя
Плавный зум - устаревшая тема. Это было в Инвазионе, в XDM и ещё в нескольких модах. Намного интереснее комбинация ступенчатый зум (как в кс) с плавным изменением FOV. Типа как в первой Паранойе, но не на одно значение и ещё с возможностью приближать и отдалять колесом мыши.
Странно, что никто этого ещё не сделал. Если интересует, напишу тутор.
Отправлено ncuxonaT 29-03-2021 в 16:56:
Ku2zoff давай объединяться по анимациям. И ИИ.
Цитата:
Ku2zoff писал:
Это типичная ошибка - что-то анимировать, считать или перемещать, используя фиксированные значения. Умножение на фреймтайм компенсирует погрешность при разной частоте кадров.
Не надо умножать на фреймтайм, это же будет переменный шаг интегрирования. Лучше считать с постоянным шагом, а промежуточные значения интерполировать. Кажется, мы это уже обсуждали.
Отправлено Дядя Миша 29-03-2021 в 17:23:
Цитата:
ncuxonaT писал:
Не надо умножать на фреймтайм, это же будет переменный шаг интегрирования.
надо менять саму архитектуру движка значит. Иначе никак.
Изменения не особенно сложные, но потом долгое время будет лезть всякое мелкое говно.__________________
My Projects: download page
F.A.Q по XashNT
Блог разработчика в телеграме
Цитата:
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено ncuxonaT 29-03-2021 в 18:55:
Сейчас разве не с постоянным шагом состояния обновляются? Кармак не всегда на 60фпс тикал? Или это с дума3 началось?
Отправлено Дядя Миша 29-03-2021 в 20:27:
Ну какой может быть постоянный шаг, если фпс зависит от нагруженности кадра, например. Его можно сверху ограничить конечно.
__________________
My Projects: download page
F.A.Q по XashNT
Блог разработчика в телеграме
Цитата:
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено ncuxonaT 29-03-2021 в 20:50:
Ну здрасьте, приехали. https://gafferongames.com/post/fix_your_timestep/
Отправлено Дядя Миша 29-03-2021 в 21:46:
Ну вот в ку3 как раз аккумулятор.
__________________
My Projects: download page
F.A.Q по XashNT
Блог разработчика в телеграме
Цитата:
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено Crystallize 30-03-2021 в 06:31:
Цитата:
ncuxonaT писал:
Не надо умножать на фреймтайм, это же будет переменный шаг интегрирования.
Как интегрирование связано с физикой-движением? Этому где-то учат? У меня после института осталось впечатление что интегрирование-дифференцирование суть математический фокус поприколу.
