есть одна 2D карта (по зеленой кнопке)
но код для просчёта коллизий может обработать только 11 юнитов
(если играть всемером - то получится, что можно добавить только 4 доп.юнита на карту)
если сделать 12 или 50 юнитов - то варик просто захлёбывается
(в карте есть счетчик обработки коллизий - максимально 80000 операций в секунду)
есть желающие поковыряться в коде и улучшить его, чтобы он смог обрабатывать 50 юнитов?
коллизии - это столкновение. по X это толкание соседних юнитов вправо влево, по Y это носить на голове или стоять сверху на юните
(если играть всемером - то получится, что можно добавить только 4 доп.юнита на карту)
если сделать 12 или 50 юнитов - то варик просто захлёбывается
(в карте есть счетчик обработки коллизий - максимально 80000 операций в секунду)
есть желающие поковыряться в коде и улучшить его, чтобы он смог обрабатывать 50 юнитов?
коллизии - это столкновение. по X это толкание соседних юнитов вправо влево, по Y это носить на голове или стоять сверху на юните
цепочка функций по просчёту коллизий:
main - начало карты
Frame__init - инициализация кадра
Frame__Main - просчет одного кадра (частота 0.02)
Frame__PlayersGroup - просчет группы юнитов
Frame__SquaresMoving - движение юнитов
Frame__MovingY [b==false] - движение по Y
if MushroomMoving_RectCondition "UpWidthOM" + "DownWidthOM" - сравнение ректов
MushroomMoving_CollisionCheck - проверка на коллизии
set otherx=GetUnitX(OrangeMushroom[j]) + set othery=GetUnitY(OrangeMushroom[j]) - считывание координат
графики:
скриншот карты:
`
ОЖИДАНИЕ РЕКЛАМЫ...
Чтобы оставить комментарий, пожалуйста, войдите на сайт.
host_pi:
host_pi:
Отредактирован host_pi
по общему впечатлению карта с глобалками на промежутке 40~50 фпс работает на пару фпс ниже-выше (прыжками туда сюда), сложно отловить, но тренд небольшой есть на обоих проверках
в целом - отличий на высоких фпс практически нет, зато как только фпс начинают падать - так сразу появляется небольшой выйгрыш на 5-10 фпс перед предсмертной агонией, т.е. небольшой выйгрыш таки есть, цена этому - сотня замен по всему коду и при выходе новых версий временнозатратно будет их патчить
итоговые результаты поразительны - количество коллизий уменьшилось в 3 раза, а максимальное количество коробок стало в 2 раза выше
и если в оригинальном виде - было под 80000 просчётов коллизий и максимум 8 объектов (не путать с 1ым графиком, там чуть щадящая система оценки была и можно сдвинуть на 1 влево)
то в enum128 варианте - происходит только 35000 просчетов коллизий, и макс 15 объектов, что уже ощутимо вырывается по отличиям
мало того, эта система еще и гибкая - т.е. в реальных игровых условиях результаты будут еще чуть лучше, потому что многие объекты стоят отдельно на уровне а не в единой цепочке с остальными
1 - оптимизировать MushroomMoving_RectCondition, там по 3 раза вызывается MushroomMoving_CollisionCheck на каждый чих а не по 1 и есть шанс еще в 3 раза повысить производительность без потери текущей физики
2 - как предложил Daro делать на триггерах вхождения юнитом в регион (на карте подобная система уже присутствует при нырянии в воду)
возможно есть и другие методы, а также те люди, кто в будущем захочет этим заняться и довести максимальное количество объектов до 50, как и задумано в карте с лабораторией - заспавнить 50 коробок
тем более что картоделы тоже страдают от этого лимита коробок, поэтому на карте больше 7+6=13 объектов обычно не появляется
вот код с глобалками + енум - xgm.guru/files/100/315886/comments/520383/BoxLab_1.1_EN_global_e...
вот чистый енум:
Отредактирован host_pi
макс количество коробок в -box3 режиме выросло на 10%
Отредактирован Jack-of-shadow
Отредактирован host_pi
но есть счетчик по вызову GetUnitX() GetUnitY() - это цикл внутри MushroomMoving_CollisionCheck
на графиках это CPS
средние цифры - десятки тысяч раз в 1 сек
а проблема во вложенных циклах с лупом
Отредактирован Jack-of-shadow
Соответственно все вычисления происходят в одном тике.
Более того в теории если в карте несколько тяжелых периодиков, то лучше инициализировать их так, что бы они не совпадали по моменту выполнения.
В итоге момент их выполнения совпадает.
Что бы этого избежать лучше инициализировать их не одноверменно, а со сдвигом в сотую.
Я могу быть не прав, тк не проверял тестами. Но по логике получается именно так.
Отредактирован Vlod
Смекаешь