Существует метод JobHandle.ScheduleBatchedJobs. Он позволяет "отправить" новую джобу на обработку. Если его не вызвать - джоба будет отправлена "когда-нибудь позже". Но не стоит его писать после шедулинга каждой джобы, т.к. это по сути форсированная отправка из локальной очереди в поток, а это занимает время.
Записывайте большие числа читаемо.
const long SOME_CONST = 1000000000L; // пример плохой записи const long SOME_CONST = 1_000_000_000L; // пример хорошей записи
Все знают, что есть IJobParallelFor, мы туда передаем 2 параметра - количество элементов и сколько элементов будет попадать в одну итерацию.
Но давайте представим ситуацию, что мы не знаем сколько элементов у нас будет (например, если у нас предыдущая джоба заполняет коллекцию). Таким образом мы не можем создать джобу.
На самом деле для такого кейса существуют "отложенные джобы" ScheduleParallelForDeferArraySize. Чтобы завести такую джобу нужно передать указатель на Sequential-структуру, в которой первые 2 поля будут такие:
T* list; int count;
Т.е. указатель на массив элементов и количество этих самых элементов. Прочитаны эти данные будут только после того как все зависимости джобы будут завершены.
Используйте блоки кода вида
{
// block 1
}
{
// block 2
} для того, чтобы избежать конфликтов локальных переменных и перестать выдумывать нечитаемые названия типа i, k, j, z etc 🙂
Вы, наверное, слышали про IJobParallelForTransform.
Это такая джоба, которая с удовольствием даст доступ к массиву трасформов ваших GameObject.
Но существует несколько интересных моментов, которые повлияют на производительность:
1. Если вы читаете трасформы и не меняете их - помечайте их как ReadOnly (Запускайте джобу через ScheduleReadOnly), это повлияет на выполнение джобы.
2. Раскидайте элементы по нескольким рутам иерархии, группировав их по 64/128/256 штук.
То есть если у вас на сцене в руте 10к GameObject и вы хотите их подвигать, то создайте N пустых GameObject и вложите в них по 64/128/256 ваших объектов.
Если этого не сделать, то ваша джоба будет всегда ожидаться главным потоком независимо от отсутствия Complete.
Дефайны можно объявлять не только в ProjectSettings, но и в файлах csc.rsp. При этом эти файлы могут располагаться как в корне (В папке Assets), так и у каждой ассембли отдельно. Внутри можно делать ссылки на другие csc.rsp, подробнее можно почитать тут:
https://docs.unity3d.com/530/Documentation/Manual/PlatformDependentCompilation.html.
Многие встречали и даже использовали memcpy. В юнити это UnsafeUtility.MemCpy. Но там есть еще UnsafeUtility.MemMove. Главное отличие в том, что memcpy работает быстрее, т.к. не делает дополнительных проверок на общую область памяти, а вот memmove делает. Проще говоря, не используйте memcpy, если два блока пересекаются, т.к. это приведет к неопределенному результату. Т.е. когда вы копируете данные из одного массива в другой - память никак не пересекается и можно использовать memcpy. Но если же вы хотите "подвинуть" данные в одном массиве, то используйте memmove.
Существует такой аттрибут Conditional, который дает возможность отключать/включать куски кода по дефайну.
[Conditional("DEBUG")]
void Method() {...}Метод будет компилироваться только если существует дефайн DEBUG. Метод должен быть void.
Можно определить отсутствие кода в методе, используя вызов
methodInfo.GetMethodBody().GetILAsByteArray()?.Length >= 2
т.к. по сути там может быть 2 инструкции. Я использую этот метод только в редакторе, т.к. результат работы метода в билде будет зависеть от сборки.
public static void Lock(ref int lockIndex) {
for (;;) {
if (System.Threading.Interlocked.Exchange(ref lockIndex, 1) == 0) {
break;
}
}
}
public static void Unlock(ref int lockIndex) {
System.Threading.Interlocked.Exchange(ref lockIndex, 0);
}Мы заводим int поле и используем его в качестве идентификатора для операции блокирования. Другими словами, пока не будет вызван Unlock, второй поток не пройдет через Lock.
Из минусов такого подхода - если ваш код между этими вызовами упадет по исключению, то все ожидающие потоки повиснут. Для этого я написал дополнение, которое выходит из цикла с ошибкой, если мы ждем слишком долго.
Как я писал выше в одном из постов, лучше вообще избегать блокировки и Interlocked, но в редких случаях без них не обойтись.
int i = 123; // всегда атомарно long j = 234L; // атомарно на x64, но кому сейчас надо x32? i++; // никогда не атомарно, т.к. мы читаем данные, увеличиваем, а потом записываем
Как устроен GOAP (или Goal-Oriented Action Planning)?
Все мы знаем деревья поведений или FSM. FSM дает возможность приходить к конкретной цели, основываясь на параметрах, приобретенных при выполнении конкретных состояний, но при этом вы можете находиться в конкретном одном состоянии в определенный момент времени.
В деревьях поведений же мы не ограничены одним состоянием в определенный момент, но сейчас не о них. Есть еще Utility based AI, но о нем нужно рассказывать отдельно.
GOAP не имеет связей. Это важно. Совсем. Простыми словами GOAP представляет собой массив простых событий, которые выполняются, если обеспечены их входные параметры, а на выходе дают необходимые эффекты.
А имея такие вводные, можно без труда построить граф для достижения необходимого действия. Как видно из названия, Goal-Oriented или ориентрир - это цель, мы ориентируемся на достижения цели. То есть мы говорим персонажу "будь сыт", а он сам добудет еду и поест. Ну или "построй дом", а он сам добудет необходимые материалы и построит дом. Пожалуй, на этом примере можно и остановиться.
Допустим, у вас есть 3 простых действия:
1. Собирать камень
2. Рубить дерево
3. Строить дом
Строить дом - это действие, которое как результат выдает "дом построен", но на вход ему необходимо 2 камня и 4 дерева. Для того чтобы добыть 2 камня нужно иметь кирку, а чтобы добыть 4 дерева - нужен топор. Допустим, что топор и кирка у нас уже есть. Мы идем рубить дерево и добывать камень. И повторяем эти действия столько раз, пока не наберется необходимое количество.
Таким образом GOAP - это граф, который строится динамически, когда мы просим дать нам какой-то результат. Он всегда строится исходя из кратчайшего пути, т.е. если 4 дерева будет лежать на складе, то персонаж пойдет именно туда, т.к. рубить ничего не нужно.