Дядя Миша писал: Потому что 10 - маловато. А 20 хорошо делится и на 60 и на 100. Без остатка.
ЕМНИП, то в халфе как раз сервер тчинкает 10 раз в секунду, отсюда 10 серверных фпс. Дядя Миша насколько вважно, чтобы герцовка монитора (клиентский фпс) была кратной серверному фпс? И как себя в теории поведут физика и AI при клиентских фпс свыше 100? 120, 144, например? Не за горами момент, когда такие матрицы массово войдут в обиход. Я уже где-то видел зависимость pev->yaw_speed от фпс - чем выше, тем медленнее монстр поворачивается. Из-за умножения на gpGlobals->frametime.
Ku2zoff писал: Я уже где-то видел зависимость pev->yaw_speed от фпс - чем выше, тем медленнее монстр поворачивается.
В стим-версии халфы это уже пофиксили. Вроде благодаря Солокиллеру - брал код с гитхаба.
Помимо этого обратил внимание на пару других вещей - на высоких фпс функция Draw в худе быстрее выполняется (я там двигаю один спрайт с помощью y +=1, поэтому обратил внимание). Повороты trigger_camera так же стали быстрыми - и там все тот же фреймтайм.
Из энумератора - конечно нельзя. Из механизма смены анимаций думаю можно, если ориентироваться на его устройство в хл2. Они там много багов посадили, но в хл2 это уже исправлено. С Кутузовым попробуй объединится, он много работал над монстрами, наверняка кое-что знает.
Цитата:
Ku2zoff писал: ЕМНИП, то в халфе как раз сервер тчинкает 10 раз в секунду, отсюда 10 серверных фпс.
в халфе клиент-сервер тикают одинаково.
Цитата:
Ku2zoff писал: насколько вважно, чтобы герцовка монитора (клиентский фпс) была кратной серверному фпс?
меньше ошибок накапливаться будет в дробной части. Хуже всего периодическая дробь.
Цитата:
Ku2zoff писал: Из-за умножения на gpGlobals->frametime.
Ну вот был бы там чисто серверный фреймтайм, так и не было бы проблемы.
Добавлено 29-03-2021 в 18:58:
Цитата:
Aynekko писал: я там двигаю один спрайт с помощью y +=1, поэтому обратил внимание
Дядя Миша писал: Ну вот был бы там чисто серверный фреймтайм, так и не было бы проблемы.
Сейчас залез в код камеры и заменил ->frametime на 0.01
C++ Source Code:
vecAvel.x = dx * SnapSpeed * 0.01;
vecAvel.y = dy * SnapSpeed * 0.01;
vecAvel.z = 0;
Скорость камеры стала одинаковой (кажись) на всех фпс (сверял 60 и 240). Надо было раньше так сделать.
До этого еще смотрел, чему равен этот самый frametime. На 60 фпс он 0.0167, на 240 кажется 0.0045. Отсюда все эти разности в поведении…
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 герц, но тут надо смотреть на тип матрицы. Цем лучше цветопередача - тем выше время отклика пикселя.
Ku2zoff писал: Тогда при разных фпс спрайт будет проходить одинаковое расстояние за одинаковое время.
Ага, спасибо, сейчас помимо этого еще пофиксил плавный зум арбалета у себя. Несмотря на то, что у меня стоял nexthink = gpGlobals->time + 0.01, зум все равно был быстрее на больших фпс. Задал временную переменную, а think поставил просто каждый кадр и все пришло в норму.
Цитата:
Ku2zoff писал: Где-то на гитхабе был фикс avelocity для камеры, погугли.
Ku2zoff писал: На 240 фпс матриц нет в природе. Они выдают 120-144, значения выше - фикция
Это хорошая новость, ящитаю. А я задал этот порог на случай, если у кого-то будет такой моник. У меня так-то 75 Гц, но все равно тестирую очень высокий фпс на предмет всяких косяков.
Aynekko писал: помимо этого еще пофиксил плавный зум арбалета у себя
Плавный зум - устаревшая тема. Это было в Инвазионе, в XDM и ещё в нескольких модах. Намного интереснее комбинация ступенчатый зум (как в кс) с плавным изменением FOV. Типа как в первой Паранойе, но не на одно значение и ещё с возможностью приближать и отдалять колесом мыши.
Странно, что никто этого ещё не сделал. Если интересует, напишу тутор.
Ku2zoff писал: Это типичная ошибка - что-то анимировать, считать или перемещать, используя фиксированные значения. Умножение на фреймтайм компенсирует погрешность при разной частоте кадров.
Не надо умножать на фреймтайм, это же будет переменный шаг интегрирования. Лучше считать с постоянным шагом, а промежуточные значения интерполировать. Кажется, мы это уже обсуждали.
ncuxonaT писал: Не надо умножать на фреймтайм, это же будет переменный шаг интегрирования.
Как интегрирование связано с физикой-движением? Этому где-то учат? У меня после института осталось впечатление что интегрирование-дифференцирование суть математический фокус поприколу.