Войти
ПроектыФорумОцените

[Iron meat - теперь демо в Steam] Платформер в стиле "Contra" - Обновление 22.07.2020 (48 стр)

Страницы: 145 46 47 48 49 50 Следующая »
#705
19:45, 24 июня 2020

Rikk
Мне непонятно, зачем вы лезете в дебри вплоть до ассемблера.
Я говорю о том, как работает игровой движок. Unity. У него есть событие «onUpdate» или как-то так.
Так вот этот обработчик с точки зрения игры - один кадр. Если код в обработчике этого события выполняется 60 раз в секунду - это и есть 60 FPS. Все. Процессор за это время успевает миллионы операций выполнить. По расчету как игровых переменных, так и всей остальной запущенной ОС.


#706
19:59, 24 июня 2020

Лекс Ливень
> Мне непонятно, зачем вы лезете в дебри вплоть до ассемблера.
....
Лекс Ливень
> Если код в обработчике этого события выполняется 60 раз в секунду - это и есть
> 60 FPS. Все. Процессор за это время успевает миллионы операций выполнить. По
> расчету как игровых переменных,
всё-таки, сколько операций выполняется или 60 в секунду или миллионы за это время?
скажем ситуация с финансами типа один шаг это один доллар. будет или 60 долларов всекунду или миллионы долларов за это время=вы ведь согласный что это большая разница.

#707
20:03, 24 июня 2020

Rikk
> всё-таки, сколько операций выполняется или 60 в секунду или миллионы за это
> время?
Да когда я говорил про 60 операций-то?
Я с самого начала говорил про КАДРЫ. Чтобы просчитать каждый кадр - нужны миллионы процессорных операций! Сначала посчитать, потом отрисовать в памяти, послать видеокарте, обработать там, отправить на вывод в монитор.

#708
20:08, 24 июня 2020

Лекс Ливень
> У него есть событие «onUpdate» или как-то так.
> Так вот этот обработчик с точки зрения игры - один кадр. Если код в обработчике
> этого события выполняется 60 раз в секунду - это и есть 60 FPS.
Лекс Ливень
> Да когда я говорил про 60 операций-то?

#709
20:12, 24 июня 2020

Rikk
И? Где здесь указание, что каждый кадр - это одна процессорная операция?

#710
20:28, 24 июня 2020

Лекс Ливень
> И? Где здесь указание, что каждый кадр - это одна процессорная операция?
это очевидно понятно из контекста. просто теперь вы ищете левые отмазки в оправдании.

#711
20:32, 24 июня 2020

Rikk
> это очевидно понятно из контекста. просто теперь вы ищете левые отмазки в
> оправдании.
Нет, блин! Это нифига не очевидно из контекста, раз. Я уже трижды повторил, что это не так, два. И я не ищу отмазок, я пытаюсь донести свою мысль, три.
Вижу, что это бесполезно. Более диалог поддерживать не намерен.

#712
21:07, 24 июня 2020

Лекс Ливень
> Unity. У него есть событие «onUpdate» или как-то так.
> Так вот этот обработчик с точки зрения игры - один кадр. Если код в обработчике
> этого события выполняется 60 раз в секунду - это и есть 60 FPS
потому что и это неверно.
Дела происходят прям наоборот.
код внутри Update { code } на юнити =это такая программа которая обязана выполняться в каждом кадре.
если система делает 30 кадров в секунду=этот код будет 30 раз в секунду
если система делает 60 кадров в секунду=этот код будет 60 раз в секунду
потому на юнити предписывают проводить умножение *time.DeltaTime чтоб на разных системах всё происходило одинаково.чтобы на системе суперММО на юнити клиент1 30кадров в сек а клиент2 60кадров в сек ситуация была бы одна и та же самая, а не то один имел бы явное преимущество перед другим.

#713
21:17, 24 июня 2020

Rikk
Ну неужели мы пришли к одному уровню, не залезая в частоты прогрессивной развертки и ассемблер.

Да, если игра идет в 30 FPS, то код будет выполняться 30 раз в секунду.
Да, если коду приходится выполняться 60 раз в секунду - это значит, что система выдает 60 FPS.

Да, именно это и рекомендуют умножать на deltaTime, но не для того, чтобы у кого-то было из игроков преимущество, а просто для того, чтобы скорость игры оставалась постоянной при любом FPS. Все-таки  вдвое ускоренный платформер станет тупо неуправляемым.

Я не пытался вывести 100% точное объяснение, как зависит расчет от FPS, или FPS от расчета. Я просто привел в пример 60 кадров в секунду для того, чтобы посчитать урон и показать, как он будет меняться в зависимости от способа расчета именно урона, нанесенного в один кадр.

Бл.. я опять в полемику вступаю. Все. Замолчал.

#714
(Правка: 21:40) 21:39, 24 июня 2020

Лекс Ливень
> и ассемблер.
это не ассемблер
это электросеть, частота сети, телевизионная система, системы изображений экран,монитор=к ассемблеру и компьютеру и тем более к геймам это отношений не имеет тк это появилось задолго до компьютеров. это наоборот компьютерную систему подгоняют под эти стандарты типа пишут на с++ которое гавно "драйвер монитора Х для операционной системы У".

#715
23:48, 24 июня 2020

Вау, отличная игра)

#716
23:52, 24 июня 2020

Лекс Ливень
> Да, именно это и рекомендуют умножать на deltaTime
это где такое рекомендуют?

#717
23:56, 24 июня 2020

forwhile
> это где такое рекомендуют?
это в принципе "правило хорошего тона" все что в игре зависит от времени (перемещение, скорострельность) привязывать к дельте, чтоб отвязать скорость происходящего от фпс

#718
(Правка: 0:23) 0:22, 25 июня 2020

Я бы не рекомендовал обновлять логику игры в Update.
Лучше в Update только проверять ввод игрока, а всю логику вынести в FixedUpdate и умножать на Time.fixedDeltaTime, чтобы при не весть откуда взявшихся лагах у игрока игра с ума не сошла, и чтобы геймплей на любых компах шел с одинаковой скоростью вне зависимости от частоты экрана.

И саму Time.fixedDeltaTime куда-нибудь сохранить, чтобы не вызывать ее напрямую - иначе будет обращение к недрам движка из C# к С++ и обратно.

#719
(Правка: 0:50) 0:48, 25 июня 2020

Mindfog games
фиксированный фпс, это правильно хорошего тона, ни где дельту не используют, кроме техно демок и криворуких инди разрабов.

Страницы: 145 46 47 48 49 50 Следующая »
ПроектыФорумОцените