Попробуйте уменьшить fps, что бы добиться оптимального баланса между задержкой между кадрами и плавностью движения. Ведь чем меньше fps, тем быстрее работает ваша игра))
Типа Опа, умные учатся на чужих вопросах, глупые - на своих.
А мой ответ - это прямая отсылка к множеству других. Но для того, что бы это понять, надо научиться копировать текст, вставлять текст и даже, вы не поверите, нажимать на кнопки.
Андрей R, Есть такая идея: будем заполнять по k картинок размера a на a вдоль меньшей стороны. Тогда можно утверждать, что мы сможем заполнить k*a вдоль большей стороны. Далее представляем оставшийся прямоугольник как новую исходную задачу, и рекурсивно решаем её. И так влоть до минимального размера стороны квадратного изображения - a[min].
Тогда вся задача сводится к оптимизации двух функций:
N = dN + Summ [i=1..j] (k[i])^2
S = 600*400 - Summ [i=1..j] (a[i]*k[i])^2
a[j] >= a[min]
dN <= 0,
где S - неиспользуемая площадь, N - количество картинок, dN - оставшиеся слоты под картинки, a[i] - сторона квадратной картинки на iом вызове рекурсивной функции, k - количество картинок вдоль меньшей стороны прямоугольника.
Бла-бла-бла, получаем dN -> 0 (а может и нет?) и S -> 0. Как это сделать, мне в голову не пришло.
Например, если у нас 10 картинок, то мы можем разбить их на две итерации: k[1]=3, k[2]=1. Тогда a[1]=133, a[2]=200. Получается квадрат 3*3 изображений 133*133,а оставшаяся полоска заполняется одним изображением 200*200. Получаем dN=0, S=40 000.
Алексей, чисто теоретически тоже возможно. Нужно каким-то образом отредактировать таблицу маршрутизации. А вот как её найти - это большая загадка для меня. В любом случае, здесь надо копать в сторону маршрутизации.
DuckMcQuack, слушайте, вот вы меня просто заставили открыть юнити и проверить это код. Всё прекрасно работает, и документация, как это ни странно, не врёт!
Значит это либо вы криво пишите, либо у вас есть другие скрипты, которые мешают вам.
Например, если у создаваемого объекта навешено rigidbody, то он не будет двигаться вместе с PrefabsParent.
