как узнать, когда нужно закончить код в update(),чтобы избеж

[mrcoder]

Добрейшее время суток!
почему то не нашлось ответа на вопрос, хотя думается это должно быть реализовано вероятно какой то стандартной командой....


есть функция update() в которой выполняется объемный код. сейчас этот код "на глазок" разбивается на периодические выполнения через небольшой самописный менеджер задач(tasks), работающий все в том же update().
как узнать время когда нужно прервать выполнение этого кода, что бы продолжить его при следующем update(), так что бы это не сказалось на фпс(что бы из за update() Не начинал падать фпс)?
то есть, иными словами, использовать всё(или почти всё) доступное свободное время процессора в функции update()?



з.ы. читал про корутины на форуме. но показалось не актуально.

[mrcoder]

Сейчас сделано "на глазок", и так что бы и на слабых процессорах не торомозило абсолютно. То есть контролируется сколько задач(и их сложность) за update() было сделано и если оно больше N, то все остальное остается до следующего update(), причем я понимаю что нпри этом остается еще очень много свободного времени(даже для слабых cpu), которое можно было бы использовать.

[Woolf]

Атомизировать ваш код вручную. Или использовать thread, но тогда появляется куча проблем с синхронизацией. Выбирайте, что больше подходит к вашей задаче.

[mrcoder]

Атомизировать ваш код вручную. Или использовать thread, но тогда появляется куча проблем с синхронизацией. Выбирайте, что больше подходит к вашей задаче.

эммм. постапокалисистически©?

я не верю что юнити настолько не продуман что не дает возможность узнать в Update() сколько времени осталось до того, когда ему будет надо рисовать следующий кадр... . на основе этого можно проверять - если времени много - то запускаем еще одну задачу на выполнение в экзекуторе, если уже в притык - то откладываем на потом. хотя это тоже не очень правильно. так как все равно неизвестная N будет. подобрав ее не правильно можно создать тормоза на тех машинах, которые могли бы тянуть без тормозов вообще... или опят же оставлят слишком много на мощных...
сомнительно что нет вообще функции, однозначно решающей эту задачку.


потоки отпадают однозначно. клиент многопоточный не требуется, достаточно многопоточного сервера, работающего на ура. если в последствии потребуется генерировать что то сверх качественное(меши/освещение). то я скорее это сделаю отдельной небольшой программой на том же с+ а переброску данных в движок можно организовать локально, даже через сеть.

[Woolf]

"атомизировать код" - значит разбить его на дискретные части, которые можно выполнять за раз. К примеру, если вам нужно провести цикл по 20 объектам, то атомизация подразумевает, что за каждый вызов вашей функции будет обрабатываться один (два, три и тд) объекта, без самого цикла.

Что же касается вашей задачи - не могли бы вы озвучить саму задачу? То, что вы хотите сделать - в юнити так не делают. Значит у вас ошибка в построении структуры программы. Возможно, есть более изящные решения вашей задачи.

[mrcoder]

насчет атомов я немного съязвил конечно.
она и атомизирована сейчас, хотя скорее "молекулизирована" . То есть законченные задачи разбиты на более мелкие.

хэх. вроде все написал выше, а вы просите озвучить...

ну ладно - поясню конкретно.
в update() генерируем меши окружающего мира. что бы успевать все сделать и избежать задержек с фпс (тормозов в игре) - разбиваем процесс генерациии меша на задачи(генерируем частями). эти задачи и помещаются в простейший обработчик. меш может быть вообще пустой и его генерация занимает копейки cpu, а может быть и сложный - тогда процесс на порядок дольше, все это учитывается. и если сгенерировали больше N - То обработчик делает return вместо генерации нового куска меша и уже при следующем update продолжает. а это не правильно, так как остается еще огромная куча времени(особенно если проц мощный) за которое можно было нагенерировать еще немало кусков мешей и при этом избежать задержки в игре.

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

[Woolf]

Карутины. После каждого атома кода, yield некоторое время, 0.1сек достаточно, чтобы отдать юне время на свою работу. По крайней мере, так нужно делать. В апдейте и (не дай бог) в фиксетапдейте подобные вещи делать нельзя.

[waruiyume]

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

O,o знает откуда? Следующий кадр не начнётся, пока не выполнен весь пользовательский код.

[artk]

Использовать потоки. Но с ними некоторые трудности будут.
Ну и естественно нужно распределять нагрузку равномерно, это и касается и дизайна карт, чтобы не скакал фпс.

[bomberest]

O,o знает откуда? Следующий кадр не начнётся, пока не выполнен весь пользовательский код.

Была у меня фобия такая в начале изучения: а вдруг не успеет просчитать

[mrcoder]

O,o знает откуда? Следующий кадр не начнётся, пока не выполнен весь пользовательский код.

Была у меня фобия такая в начале изучения: а вдруг не успеет просчитать

если фпс фиксированный, будет пауза в расчетах. даже если он вычисляет несколько итераций наперед - все равно будет знать. разумеется это все для ситуаций когда вычислительные мощности для программы меньше возможностей cpu.

Была у меня фобия такая в начале изучения: а вдруг не успеет просчитать

значит у вас координально другой тип игр. не успеет просчитать. поэтому и пришлось откалибровать производительность на процессоре 6летней давности. если бы он "успевал просчитать" - я бы мог позволить себе очень вкусные вещи.

[mrcoder]

про потоки я уже расписал, почему они мне не нужны в клиенте, а если и будет нужно например второе ядро - я описал как и на чем реализую это.
юнити здорово отстает в плане технологий, в 4ре дружелюбной многоядерности так и нет.

Карутины. После каждого атома кода, yield некоторое время, 0.1сек достаточно, чтобы отдать юне время на свою работу. По крайней мере, так нужно делать. В апдейте и (не дай бог) в фиксетапдейте подобные вещи делать нельзя.

про это я читал, и уже отписал выше, что вариант с карутинами не лучший..

объясню почему для меня проше апдейт, в частном случае.
например игрок изменил состояние мира, нужно пересчитать меш и граничащие с ним меши/освешение и тд. при update() можно гарантировано контролировать кадры и когда это произойдет. ведь просчет нужно сделать мгновенно, то есть в том же кадре что и изменился мир. иначе будут получаться ситуации такие к примеру: игрок удалил под собой на стыке мешей блок(кубик). новые меши не успели просчитатся в этом кадре, в следующем кадре под игроком пусто - игрок проваливается в текстуры.. подобное будет происходить не часто, но будет.
а подумайте какого оно в ондайн режиме... здесь же одновременно могут убрать/поставить блоки 10ки человек. конечно делается через буфер и не для каждого действия меш пересчитывается. так же и сейчас у меня на случай проблем ставится временная невидимая коллизионная плоскость что бы исключить подобные ситуации.

спасибо. не понимаю почему в апдейт нельзя засовывать большой код?(про фиксед понятно).

[mrcoder]

вобщем написал много, и многое не каждый человек поймет - тороплюсь при наборе текста и выражении мыслей. а порой голова кругом... так что уж "извините за мой русский"
вопрос то был краткий простой и с кратким простым ответом ожидаемым.

спасибо за советы. значит пока не будем трогать - пусть будет надежнее, но с менее эффективным использованием процессорного времени и меньшими качественными возможностями.