Ninja, спасибо! Значит нужно заняться переводом из ds_map в ds_list

Только в словарях поиск, потому что там ключ может быть любым числом и строкой (зато удобно хранить, к примеру, <ник>--<пароль>); в списках по индексу не совсем поиск, по сути простой перебор до n-го элемента (указатели же); в массиве вообще нету поиска, прямиком обращается к памяти!..
В общем, употребление того или иного представления данных зависит от ситуации!
Делайте выводы. xD

NewStrannik, интересно, почему поиск в ds_map такой медленный, почти в 2 раза медленней списков, из-за чего ds_map так тормозно работает?

Я провёл тесты и у меня это получилось:
ds_map_find_value(a, val) -- ~770
ds_list_find_index(a, val) -- ~925
При чём я не проверял типа такого: ds_list_find_value(a, ds_list_find_index(a, val)+1)...
Снова повторюсь: всё зависит от ситуации.

так а всетаки почему медленнее работает? поиск в списке должен намного больше времени занимать, чем в картах

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

Ninja, поиск там осуществляется по текстовой строке(сравнение), а в списке переход по указателю на определенную позицию. В случае мапа - перебор + сравнение строк, а в случае списка просто перебор, и может быть, сравнение чисел.

Всем привет!
Углубляясь в изучения ГМЛ, назрел такой вот вопрос оптимизации.
Скорость комнаты 300

Задача: Поиск ближайшего объекта, отвечающего нужным параметрам (столкновение с блоком) т.е. существуют одинаковые объекты, среди которых необходимо найти ближайший, сталкивающийся с блоком.

У меня есть 2 варианта:
Первый - при столкновении объекта с блоком менять одну переменную, потом в объекте, которых их ищет писать код наподобие:
(Этот вариант нашел на форуме, предложенный Maverick)

Либо при столкновении объекта с блоком создавать пустой объект, который будет двигаться вместе с создавшим объектом, и искать уже эти пустые объекты:
(мой вариант)

Надеюсь, объяснил понятно. Вопрос в том, какой вариант производительнее. При скорости комнаты в 300 и учитывая, что искать нужные объекты будет тоже не 1 объект, а многие. ТО есть что тот что тот вариант будет обрабатываться много раз.
Обьа способа рабочие, нужно лишь найти менее ресурсоемкий
Заранее спасибо!

Думаю первый вариант будет работать быстрее т.к. в нем не создаются новые объекты и меньше проверок if

Я тоже так думаю, но!
Если такую проверку необходимо проводить в нескольких объектах, и если условие выполняется хотя-бы у одного проверяемого объекта, то все нормально. Но если объектов, отвечающих параметру "if ins.blablabla... //проверка параметров" в данный момент нет (ни один не соприкасается с блоком), то начинаются ужасные тормоза.(ФПС на скорости комнаты 300 приближается к 100, иногда меньше)

Может какой-нибудь пример, где скорость комнаты так падает, покажешь, а?)

SpectruM, при такой скорости глупо проверять это каждый степ, как минимум каждые 10 степов - и тормозов не будет

Скоро закончу проект, тогда покажу (исходник выложу)
Хотя, если получится
то и не увидите.

Добавлено (19.02.2010, 11:47)
---------------------------------------------
Попробовал - реально помогло! Спасибо за подсказку, как-то не пришло в голову!
В любом случае сам по себе вопрос, думаю, был решен еще раньше - первый способ оптимальнее. Намного более удобно читаем (и применяем), не создается лишних объектов, его легче править. Работает быстрее. Большое спасибо!

Все не прочел. Возможно уже было. Сделать ограничитель некоторых объектов. Типо ограничение гильз или крови. ставишь ограничитель 100 и если на мапе, например крови, >100 то удаляем самую первую. Надеюсь понятно.

Чего лучше не делать в событии рисования?

Bercut, всячески не стоит загромждать и рисование и степ постоянными сложными вычислениями. Если все-таки надо - то между рисованием и степом вычисления лучше выносить в степ. В событии рисования нельзя рисовать на сурфейсах, хотя об этом в принципе напрямую написано в справке. Постарайся избавить рисования от частого пересчета коэффициентов и координат, которые обновляются не каждый шаг, их можно пересчитывать в том событии, в котором они обновляются. В любом случае надо быть аккуратным с рисованием длинных всяких примитивов циклами.
И еще совет - если тебе необходимо регулярно обновлять например ИИ, а это обычно кушает много ресурсов, то сделай обновление периодическим, например через алярм зацикленный через каждые 5 шагов. Причем если у тебя много ботов, то в создании каждому лучше выставлять алярм не на 5, а на random(5), тогда обновления ботов будут происходить несинхронно, в разные шаги, соответственно пиковая нагрузка на вычисления будет в каждый момент меньше.

Лучше использовать choose( 2, 3, 4, 5, 6); Ибо рандом, вроде, выдает ноль и дробные числа.

SRes, ну поскольку алярм - это встроенная переменная, то гм сам ее округляет как ему надо. И в итоге все рвно проверки получаются равномерно распределенными по времени.

Ты не учел то, что результат может быть 0.

Ты не учел, что алярм, когда выключен равен -1.
А вообще, пойду ка я проверю, сработает ли алярм при нуле?

Добавлено (15.07.2010, 16:25)
---------------------------------------------
repeat(1000000) if random(10)=0 show_message('****!'); не выдал ниодного сообщения.
И да, неким опытным путем, я выяснил, что алярму нужно значение равное или большее чем 0.5