Например, чтобы сдвинуть объект, который находится в x=10, на 100 юнитов вправо, нужно написать 10+100 и нажать enter.
Еще можно использовать функции L(x, y) и R(x, y), которые выставят выделенные объекты по Lerp и Random соотвественно.
Есть такой мемчик, где люди делятся на 2 типа и вот это все. Ну там где у человека выключено отображение ворнингов и там где включено.
Я отношусь к тем, у кого они включены и вообще не люблю когда в логах мусор.
Так вот, в шарпе есть такая штука:
#pragma warning disable #pragma warning restore
Она позволяет включать и выключать либо все ворнинги, либо конкретные, если указано какие конкретно нужно отключить.
Вообще я предпочитаю исправлять предупреждения, а не использовать эти директивы, но тем не менее иногда без этого никуда.
Поддерживайте ваш код в чистоте и без лишних логов и предупреждений.
Я уже писал про PackTextures, но эта штука ломается, если невозможно запаковать текстуры, т.к. их размер превышает максимальный размер атласа. Для этого можно использовать GenerateAtlas, т.к. этот метод ничего не делает с текстурами, а только работает с ректами и возвращает true, если все объекты поместятся в атлас. То есть можно сначала вызвать его, а потом использовать PackTextures, либо запаковать самостоятельно, используя SetPixels.
Как-то не особо заметно прошло появление этого класса в юнити, но появился он аж в 2019.2.
Это такая удобная штука, которая позволяет получать уже нужные типы без необходимости искать их во всех ассембли.
Нам часто нужно из точек сделать меш, чтобы потом отрисовать его.
Для этой цели нужно использовать алгоритм триангуляции (например, вот этот). Вообще реализаций полно, так что не думаю что с этим будут проблемы.
Суть сводится к тому, чтобы на выходе получить треугольники (как следует из названия) из точек. А для создания мешки нам нужны вертексы (те самые точки) и индексы (как именно эти точки образуют треугольники).
Мы знаем, что производительность - это метрика, которую можно оценить по fps или frames per second, т.е. сколько раз мы можем за секунду выполнить всю логику в кадре и отрисовать все, что мы посчитали.
Логика - это все то, что мы пишем в наших методах Update, которые являются частью основного цикла кадра и это обрабатывается на cpu, а вот рендер - это то, что обрабатывает видяха.
В целом эти два процесса никак не связаны, то есть в какой-то момент времени cpu посчитал что-то и готов передать на gpu некие данные, которые будут обрабатываться уже там и как результат - будет картинка. Существуют еще compute shaders, которые по сути используют проц на видяхе, чтобы посчитать результат.
И вот тут нам нужно синхронизировать данные. То есть при использовании синхронизации нам нужно задать фиксированное количество времени, которое мы готовы потратить на кадр, например, 30 кадров в секунду или 33мс на кадр. И при синхронизации существует время ожидания, когда cpu ждет gpu или наоборот. В профайлере такие ожидания обозначаются как WaitForPresentOnGfxThread. А вот WaitForTargetFps - это время, которое нужно, чтобы поддержать заданный frame rate.
В юнити есть замечательная штука, которой мало кто пользуется. На самом деле дает возможность считать отсечение примитивами. На практике я такое часто использую для того, чтобы знать какие объекты нужно просчитывать, а какие - нет. Наверное, это апи можно считать уже устаревшим, т.к. приходят всякие brg, которые умеют в culling, плюс это апи не умеет в burst. Но на самом деле я все равно его использую, т.к. даже на уровне представления оно дает заметный прирост, если самому отключать аниматоры/рендеры и прочие штуки.
Когда-то давно мы делали 3D игру (да, такое тоже было, сейчас от нее остались старые исходники и пара видосов на ютубе).
Тогда в ходу были всякие тулзы вроде T4M. Но все подобные штуки работают по принципу раскраски или смешивания. Т.е. есть 4 канала маски, а есть 4 текстуры, там где красный - там тайлится первая текстура, где зеленый - вторая и т.д.
Но существует проблема тайлинга текстур, т.е. когда мы можем отдалить камеру таким образом, чтобы тайлинг стал заметен. Так вот чтобы этот эффект был менее заметен, мы не тайлили первую текстуру в террейне, т.е. она была растянута на всю площадь и обычно это была текстура "миникарты". Таким образом мы получали раскрашенный террейн по всей площади текстурой плохого качества.
После этого мы брали уже другие текстуры и тайлили их поверх той самой текстуры плохого качества, но с прозрачностью процентов 20-40. Таким образом тайлинг был практически незаметен, т.е. каждый тайл блендился со своим практически уникальным кусочком миникарты.
Сегодня используются различные техники при работе с поверхностями начиная от моей любимой «забьем болт» и заканчивая извращениями с шейдерами и дистанцией, но мне все еще нравится способ использовать текстуру плохого качества ;)
Мы храним SystemInfo.deviceUniqueIdentifier, который вовсе не device id, а advertisement id, т.е. раньше он был айдишником девайса, но потом от их использования отказались в пользу различных авторизаций.
Но мы хотим, чтобы юзер мог играть без авторизации, т.е. юзер должен передать некую уникальную строку.
Когда я разбирал исходники ios, я находил там несколько вариантов этой строки, там был и айди девайса, и мак адрес и всякие другие попытки получить уникальный айди (всего было штук 5, если мне не изменяет память).
Раньше этот айдишник был вполне стабилен, т.к. являлся заводским уникальным айдишником. Сейчас нам дают рекламный айди, который может измениться в любой момент. Самый простой способ - сохранить его в PlayerPrefs, чтобы даже при его изменении со стороны ОС - ничего не менялось для игрока. Естественно, мы предупреждаем, что лучше бы подключить какую-нибудь сеть типа фейсбука, чтобы не потерять прогресс, но это как прочитать readme.
Но люди продолжали жаловаться, что аккаунты теряются, в основном на ios, т.к. именно там рекламные айдишники меняются и меняются часто. Т.е. люди просто удаляли игру и ставили ее заново, прогресс естественно терялся. Чтобы решить эту проблему, мы начали сохранять ключ в Keychain и проблема ушла.
Для того, чтобы в инспекторе при отрисовке массива отображались нормальные названия элементов, а не Element 0, Element 1, Element N, можно использовать строку первым полем:
struct Item {
public string key;
...
} Тогда введенные данные в этот ключ будут отображаться вместо стандартного Element X, что повысит читаемость и поиск, и вам не придется писать дополнительных редакторов для элементов.
Это приведение к единичному размеру, при этом направление сохраняется. Обычно мы используем для этого v.normalized или v.Normalize(). Второй вариант будет немного быстрее первого, т.к. мы не создаем копию вектора, а изменяем существующий.
Но как оно работает внутри? Как нетрудно догадаться из определения нормализации, чтобы привести вектор к единичному - нам нужна его длина, а длина вектора - это корень по теореме Пифагора. Поэтому если вы по какой-то причине уже получили длину вектора, то просто поделите (ну поделите, ага https://t.me/unsafecsharp/150):
var inv_length = 1f / length; v.x *= inv_length; v.y *= inv_length;
И получите нормализованный вектор.
А то я часто встречаю примерно такой код в хот частях:
var length = v.magnitude; var n = v.normalized;
Хотя на деле проще было бы просто получить длину один раз и использовать ее дважды (ну или сделать свой метод для этого).
Я уже делал пост про FixedUpdate (https://t.me/unsafecsharp/103), но не писал про разницу между fixedDeltaTime и deltaTime.
В методе Update deltaTime будет равен времени, которое прошло с прошлого кадра, при этом fixedDeltaTime будет равен фиксированной величине.
А вот в FixedUpdate fixedDeltaTime останется, а вот deltaTime будет равен fixedDeltaTime. Другими словами, можно использовать deltaTime внутри FixedUpdate.