Задачи, которые требуют манипуляции с векторами (перемещение, вращение и тд) лучше вешать на ивент тик и дельта тайм. Еще потому, что если их повесить на таймер, могут быть графические глюки, такие как мерцание. На высоком фпс не заметно, но если снизить скорость (через dilation), будет. Все потому, что объект не прорисовывается каждый кадр, а меняет свое положение в пространстве и отрисовывается заново.
На самом деле всё ещё хуже и разница в производительности между запуском в редакторе и скомпилированной версией может быть 10ти кратной и даже больше, но это касается именно логики, если слабым местом будет графика то такой разницы не увидите.
Интересно было бы посмотреть сравнение не на такой тяжелой операции, как кручение объектов, т.к. 99% производительности уходит именно на это, и весь выигрыш эвент тика лишь в том, что он по факту тикает реже, чем таймер
В этом вся соль, поскольку логика к ним прикрученная как правило намного более ресурсозатратна чем стоимость самого тика или таймера. Информация же которую в начале озвучил как раз и получена в Shipping билде при 60 тысячах таймеров с максимально простой логикой т.к. целью было как раз сравнить базовую производительность тика и таймера.
Аж страшно становится, когда ты что то делал но одном, а потом тебе говорят что это снижает производительность и ты понимаешь что все надо переделывать и менять. Все говорят надо сначала сделать игру потом ее оптимизировать, но я если нахожу баг или просадку ФПС сразу ищу причину, иначе потом среди тысячи причин сложно будет что то найти.
Есть обратный пример, когда мы преждевременной оптимизацией занимаемся. И сидим делаем то, что вообще не надо делать или усложняем себе процесс до уровня, что никто уже вообще не понимает как это работает. Есть две фразы: "Тестируйте рано, тестируйте чаще" и "все проблемы от преждевременной оптимизации" которые надо учитывать. Помимо оптимизации производительности есть ещё оптимизация бюджетов, например, о которой часто люди страдающие перфекционизмом забывают. Особенно если эти люди принимают решения. И потом оказывается что огромную часть времени потратили на какую-то малозначительную ерунду и теперь абы как надо всё остальное сделать.
![[🔴LIVE] งานประกาศรางวัล MAYA TV AWARDS 2024 : มายามหาชน](http://i.ytimg.com/vi/nwmWYXXVwBY/mqdefault.jpg)
Первое видео th-cam.com/video/diz6gjV8GbY/w-d-xo.html
Поддержать можно тут boosty.to/valkyrie
С вопросами сюда discord.gg/7swknc5yxa
Блен не хватает только вывода в конце по всем примерам. Чтобы можно было просто перемотать и послушать вывод, для тех кому не так важно обоснование.
ЛАЙКИЩЕ ТЕБЕ!
Задачи, которые требуют манипуляции с векторами (перемещение, вращение и тд) лучше вешать на ивент тик и дельта тайм. Еще потому, что если их повесить на таймер, могут быть графические глюки, такие как мерцание. На высоком фпс не заметно, но если снизить скорость (через dilation), будет.
Все потому, что объект не прорисовывается каждый кадр, а меняет свое положение в пространстве и отрисовывается заново.
Тесты производительности нужно делать в билде. При тестировании в редакторе ко времени отрисовки кадра игровым потоком добавляются фоновые 7-8 мс.
На самом деле всё ещё хуже и разница в производительности между запуском в редакторе и скомпилированной версией может быть 10ти кратной и даже больше, но это касается именно логики, если слабым местом будет графика то такой разницы не увидите.
Но что тяжелее в редакторе, практически всегда тяжелее в билде :)
@@ivan-_-8577 важно то, насколько тяжелее. То, что в редакторе тяжелее на 20%, может быть тяжелее на 100% в билде.
Интересно было бы посмотреть сравнение не на такой тяжелой операции, как кручение объектов, т.к. 99% производительности уходит именно на это, и весь выигрыш эвент тика лишь в том, что он по факту тикает реже, чем таймер
В этом вся соль, поскольку логика к ним прикрученная как правило намного более ресурсозатратна чем стоимость самого тика или таймера. Информация же которую в начале озвучил как раз и получена в Shipping билде при 60 тысячах таймеров с максимально простой логикой т.к. целью было как раз сравнить базовую производительность тика и таймера.
Аж страшно становится, когда ты что то делал но одном, а потом тебе говорят что это снижает производительность и ты понимаешь что все надо переделывать и менять. Все говорят надо сначала сделать игру потом ее оптимизировать, но я если нахожу баг или просадку ФПС сразу ищу причину, иначе потом среди тысячи причин сложно будет что то найти.
Тоже не раз подобное слышал, что сначала делаем потом оптимизируем, к чему это приводит несложно судить по современным играм.
Так говорит в основном менеджмент.
А причин на самом деле 3: таймер, ивент тик и циклы. Например, такие методы как get all actors of class
@@Poloskun4ik Ахахахахпхпхп. Если серьезно то все эти байки от блоггеров, которые ведут уроки по блупринтам изрядно приелись.
Есть обратный пример, когда мы преждевременной оптимизацией занимаемся. И сидим делаем то, что вообще не надо делать или усложняем себе процесс до уровня, что никто уже вообще не понимает как это работает.
Есть две фразы:
"Тестируйте рано, тестируйте чаще" и "все проблемы от преждевременной оптимизации" которые надо учитывать.
Помимо оптимизации производительности есть ещё оптимизация бюджетов, например, о которой часто люди страдающие перфекционизмом забывают. Особенно если эти люди принимают решения. И потом оказывается что огромную часть времени потратили на какую-то малозначительную ерунду и теперь абы как надо всё остальное сделать.