Собственно, зачем тратить громадные ресурсы на pick every unit в системе движения, если можно создать для каждого снаряда отдельный триггер, который регистрирует вхождение юнита?
private void Do(){ int i = 0 int j = 0 while(i<=maxArray){ if(uLaser[i]!=null){ SetUnitX(uLaser[i],GetUnitX(uLaser[i])+Cos(bj_DEGTORAD*GetUnitFacing(uLaser[i]))Anton Bugaev) SetUnitY(uLaser[i],GetUnitY(uLaser[i])+Sin(bj_DEGTORAD*GetUnitFacing(uLaser[i]))Anton Bugaev) uPath[i]+=1 j++ if (uPath[i]>maxPath){ uPath[i]=0 RemoveUnit(uLaser[i]) uLaser[i]=null uCaster[i]=null DisableTrigger(tr[i]) TriggerRemoveAction(tr[i],tra[i]) DestroyTrigger(tr[i]) tr[i]=null tra[i]=null } } i++ } if (j==0){ DestroyTimer(t) t=null }
}
private void Collision(){ int i = 0 while (tr[i]!=GetTriggeringTrigger()){ i++ } if(GetEnteringUnit()!=uCaster[i])and(GetUnitTypeId(GetEnteringUnit()) != ID){ RemoveUnit(uLaser[i]) uLaser[i]=null uCaster[i]=null DisableTrigger(tr[i]) TriggerRemoveAction(tr[i],tra[i]) DestroyTrigger(tr[i]) tr[i]=null tra[i]=null } } void SystemMoveRun(unit u){ int i = 0 while(uLaser[i]!=null){ //Находим индекс пустой ячейки для массива i++ } uCaster[i]=u float a = GetUnitFacing(u) float x=GetUnitX(u)+(RangeOfCreation*Cos(a*bj_DEGTORAD)) float y=GetUnitY(u)+(RangeOfCreation*Sin(a*bj_DEGTORAD)) uLaser[i]=CreateUnit(Player(bj_PLAYER_NEUTRAL_EXTRA),ID,x,y,a) UnitAddAbility( uLaser[i],'Amrf') SetUnitFlyHeight( uLaser[i], GetUnitFlyHeight(u), 0.00 ) // tr[i]=CreateTrigger() // TriggerRegisterUnitInRange(tr[i],uLaser[i],RangeOfCollision,null) // tra [i]= TriggerAddAction(tr[i], function Collision)
PauseUnit(uLaser[i],true) if (t==null){ t=CreateTimer() TimerStart(t,TimerPeriod,true,function Do) } if (i>maxArray){ maxArray=i }
i=0 if (maxArraySearch==true){ int j = 0 while(i<8191){ if(uLaser[i]!=null)and(j<i){ //Находим максимальный индекс непустого элемента j=i } i++ } maxArray=j //Найдя максимальный индекс непустого элемента, мы будем использовать его } //для нахождения максимального номера массива, который мы будем обрабатывать u=null }
}
Но создавать триггеры каждый раз... утечно? Да, если их не очищать. При правильном удалении триггера(условия, действия, обнуление), память не засоряется, ну или засоряется незначительно даже при низких периодах . Простейшая наработка делает следующее:
Получает юнита-кастера Ищет пустое место в стеке Создаёт юнит снаряд Попарно заполняет ячейки массивов в стеке Создаёт триггер для снаряда, регистрирующий вхождение юнита Запускает таймер(если он не запущен) для обработки стека Таймер двигает все снаряды в стеке(массив не прогоняется полностью, если включён модуль поиска макс. не пустого индекса массива)
Само движение лишь набросок(здесь даже не учтены перепады высот, склоны и остальные хитрости) Да и на быдлокод не обращайте внимания, я не мастер оптимизации :)(p.s. хэш не перевариваю, вместо него юзаю стек и парные массивы) Фишка в том, что использование динамических триггеров, позволяет избежать поиска юнита вокруг каждый период таймера. Поиск производится лишь при регистрации вхождения триггером. То бишь по идее это должно быть быстрее обычной системы движения. К слову, при периоде в 0.02 одновременно без лагов я тестировал 1000 снарядов сразу, на 1500 уже начинает подлагивать(карта и без того далеко не пустая, чего только стоит PDL система физики). Что вы думаете насчёт этого?
Мир, как зеркало, отражает ваше отношение к нему. Когда боретесь с миром, он борется с вами. Когда прекращаете свою битву, мир идет навстречу.(В.Зеланд) vk.com/zonnery
Сообщение отредактировал Zonnery - Понедельник, 11 Марта 2013, 13:37:07
Делал купол войда с пикевриюнит. Мой слон нахер вис с событием 0.5 сек. Любой другой вариант уже лучше. на джассе тем более, как ты уже заметил - триггер дестроить и всё...
Но создавать триггеры каждый раз... утечно? Да, если их не очищать. При правильном удалении триггера(условия, действия, обнуление), память не засоряется, ну или засоряется незначительно даже при низких периодах
динамические триггеры засирают память намного сильнее, чем грамотный пик юнитов, даже если эти триггеры правильно очищать
Добавлено (11 Марта 2013, 17:13:27) --------------------------------------------- Да, кстати, мне одному кажется, что заставлять варик при инициализации забивать 8191 значение нуллов - это бред?
Да, кстати, мне одному кажется, что заставлять варик при инициализации забивать 8191 значение нуллов - это бред?
Все массивы (и локальные, и глобальные) при создании инициализируются значениями по умолчанию. Я, видимо, невнимательно смотрел код, но где там забивание 8191 значения?
Он ставит массивам размерность - разве это у нас не генерирует цикл с забиванием?
Нет. Просто если поставить размерность больше 8192, JassHelper создаст несколько массивов и функции доступа типа таких:
Код
function func________get takes integer i returns integer if i < 8192 then return arr_a[i] endif return arr_b[i - 8192] endfunction
function func________set takes integer i, integer value returns nothing if i < 8192 then set arr_a[i] = value else set arr_b[i - 8192] = value endif endfunction
динамические триггеры засирают память намного сильнее, чем грамотный пик юнитов, даже если эти триггеры правильно очищать
Открой любой редактор памяти и посмотри память вара, память используется лишь при первом использовании стека ячейки триггера, далее она всегда очищается до исходного состояния. Если утечки же и есть, то они незначительны(я таковых вообще не увидел в редакторе памяти), и ими можно пожертововать, располагая системой движения до 1000 юнитов одновременно.
Мир, как зеркало, отражает ваше отношение к нему. Когда боретесь с миром, он борется с вами. Когда прекращаете свою битву, мир идет навстречу.(В.Зеланд) vk.com/zonnery
Открой любой редактор памяти и посмотри память вара, память используется лишь при первом использовании стека ячейки триггера, далее она всегда очищается до исходного состояния. Если утечки же и есть, то они незначительны(я таковых вообще не увидел в редакторе памяти), и ими можно пожертововать, располагая системой движения до 1000 юнитов одновременно.
А теперь вопрос на засыпку: на каком патче? Да, на 1.24b и у меня не удалялись, но ведь возможно, что Blizzard'ы это пофиксили? Если человек сразу предлагает воспользоваться редактором памяти, скорее всего, сам он это уже сделал, не так ли?
Цитата (Zonnery)
p.s. хэш не перевариваю, вместо него юзаю стек и парные массивы
Цитата (Ty3uK)
Он ставит массивам размерность - разве это у нас не генерирует цикл с забиванием?
А, понял, где ты ошибся. Когда в GUI массиву ставишь размерность, WE генерирует цикл.
А теперь вопрос на засыпку: на каком патче? Да, на 1.24b и у меня не удалялись, но ведь возможно, что Blizzard'ы это пофиксили? Если человек сразу предлагает воспользоваться редактором памяти, скорее всего, сам он это уже сделал, не так ли?
будь это после 1.24, то думаю близзарды бы вписали это в чейнжлог может он и прав, в своё время на xgm'е проводились тесты на эту тему в идеале бы приаттачить карту с примером для детальных тестов
Ну как бы система сама под спойлером, вставил в любую карту и тестировать можно сколько хочешь)
Мир, как зеркало, отражает ваше отношение к нему. Когда боретесь с миром, он борется с вами. Когда прекращаете свою битву, мир идет навстречу.(В.Зеланд) vk.com/zonnery
Мир, как зеркало, отражает ваше отношение к нему. Когда боретесь с миром, он борется с вами. Когда прекращаете свою битву, мир идет навстречу.(В.Зеланд) vk.com/zonnery
. Простейшая наработка делает следующее: 
