адекватный опрос объектов
 

здравствуйте! пишу игрушку-стрелялку с видом сверху. очень интересует ваш опыт.

при инициализации "раунда" в классе Game (создается новый экземпляр при каждом новом раунде) заполняется массив obj со ссылками на собственно человечков, снаряды и т.д. то есть перед началом раунда имеется массив:

также есть вспомогательный массив free_obj, который хранит в себе булевы значения true/false, длина такая же, как и у obj. если free_obj[ n ] == false, этот объект опрашивается. если true, объекта как бы уже нет (погиб например), и опрос не производится.

функция ongoing класса Game вызывается через ENTER_FRAME 36 раз в секунду и вызывает соответствующую функцию main каждого человечка/снаряда, которой передаются нажатия клавиш (если человечек - главный герой, то есть управляемый игроком).

в ней изменяются координаты соответственно модели поведения и производится расчет пересечений/столкновений с другими объектами. то есть если у нас 10 объектов, опрос будет выглядеть так: 1 объект опрашивает 2,3,4...10й, потом второй объект опросит 1,3,4...10й и так далее.

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

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

производительность этого движка меня как-то не устраивает.

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

не трать зря время, используй box2d

ну, это не по-джедайски

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

ну или хотя бы покопайтесь в его исходниках.

Так а что именно тормозит?
Навскидку - нет широкой фазы. Это правда может ускорить. Возможно, поможет замена массива на список и/или не использовать вообще удаление из массива через slice (только помечать).

как вариант, пороюсь.

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

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

Вопрос "что тормозит" был к тому, что собсно править надо именно то, что тормозит. Если вся игра, то всю игру)
Надо определить, что же конкретнее начинает жрать много. Ну в общем на геймдеве там в терминах в разделе физика даны основные понятия о том, как физ. двиги работают, читайте)
Возможно даже тяжелой артиллерии не надо, только завести собсно AABB и проверку по ним и если было просчитано взамиодействие 1 с 2, то не проверять, как у вас делается, взаимодействие 2 с 1.

да если бы ты использовал box2d, то мог бы протестить без графики на отладочной отрисовке, а так даже не знаю что тебе посоветовать =)

а я так и тестирую. графики пока тупо нет :)