потомму что на 3000 вар повеситьса чисто из за присуцтвия стольких юнитов =) 1000 тоже многовато в процесе заполнения карты могут быть сильные лаги... но если грамотно заполнить можно да и 1К...


я сделал просто буль который проверяетьса. т.е. типо да но с таким же успехом можно исключать из цыкла обработки ВООБЩЕ т.е. на факте это не играет роли не считая того что я буду избегать лупа вида

loop
///
if x.active then // т.е. такая проверка стоит
///
endloop

т.е. если я буду даже убирать то производительность это не поднимит ну ок при большом кол юнитов на 1-5 ФПС МАКС. т.е. двумя словоми not essential.

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

Jon, стена там, давай ты сделай хотябы физику 20 кубиков я погляжу как ты буш жмякать ресет

ScorpioT1000 добавил:

дыг это оно и есть тока апгрейженое)
и я это зоюзаю в кампе(в основном это мне надо для тру эффектов взрыва, а также некоторых головоломок)

ScorpioT1000 добавил:
Toadcop, я вот думаю, а не тормозят-ли проверки все это, т.е. мб их можно оптимизить/увеличить период?

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

а я про вар и что? на остальном есть хавок и геймдев(на выбор=)), алгоритм ясный, просто стоит почитать физику за 9 класс(динамику)

ScorpioT1000 добавил:

дыг открой и посмотри, ты только разводишь ненужный флуд

ScorpioT1000 добавил:
т.е. если тут радиусы, то на кубиках будут несколько точек, которые из-за большого кол-ва операций будут приводить к неоправданным лагам

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

ну да, конешн... ну зделай рас это так легко

ну я предпочел заюзать готовое, точней сначало хотел продж.креатор, но вот Tc посоветовал StoneCrusher)

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

да жон прав их дб 666 чВ



ну я понял, потом вникну как будет настроение как ты определяшь "активность", впринципе идея тру)

(я так понял ты это где то в ТсХ заюзаешь? для тех же бочек/пассив обьектов) - если так то можно на карте будет кучу "мусора" "активного" раскидать...

ADOLF добавил:


кстате каждый луп тоже время) ну хотя и не такое большое...

хз, можно еще как нить попробовать оптимизить, но опять же смысла в этом мало чВ

ADOLF, там все просто, цикл такого вида:

Как вариант, можно сделать два массива - активные снаряды, для которых и делается луп с действиями, и неактивные, с которыми ничего не делается ^_^ Тогда не потребуется проверять флаг активности.
ADOLF, ага, верно, нет предела † задротизации † ...

ShadoW DaemoN, так а смысл? просто заносить все активные в один массив, и переносить удаленные и уменьшеть счетчик МаксОбжект. ну опять же надо смотреть насколько часто они удаляются)



предел ограничен недостежимым идеалом

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

// ты за меня не беспокойся, я разобрался, а ты не в тему сказанул. Я свой вариант предложил. © swdn

//swdn, там все это есть, там даже больше чем ты сейчас говоришь, тоесть это какраз бессмысленный флуд (цэ)Sc

не факт то что написал ShadoW DaemoN и есть что там проверяетьса =)

Toadcop ну активность/неактивность это помойму очевидная вещь и фигня недостойная обсуждения)
по поводу сопособа хранения активных/неактивных сфер адольф предложил более мение вменяемое решение...
таккже я обсалютно неуверен, но можно попробывать активные сферы в группые? и проходится по всем через ForGroup, это избавет от лишней мороки с сортировкой, незнпаю как повлияет на производительность, мб стоит попробывать...
далее...

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

функции медленнее массивов и циклов)

помните мою задачу про движение снарядов? у меня была извращенная идея типа



и в Мове уже через Юнит2Интерег(ГетПикедЮнит()) получать прожектилину и мувать ее, но я отказался) (ибо влом было тестить возможные косяки)

но на факте функция - это как минимум пуш в стек адреса возврата (во я умных слов нахватался^^) и аргументов (я вообще пришел к выводу что инлайн наше все, особенно в узких местах), так вот, о чем это я)

короче если делать это группами вы теряете много времени именно на самом "вызове"

хм, я кстате уверен что больше 50% тормознутости кеша в том, что я писал (ну т.е. то что он - функция) (когда то я проверю это стопВачем)



я когда то пробывал без "разбивки", ну там были немного другие условия, вобщем луп себя не оправдал, хотя хз, я неуверен что делал это 100% оптимально.

хм...?

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

ADOLF добавил:


если так то стоит пробывать наоборот писать свой алгоритм этого) имхо)

Jon ты не в теме. иди на ГеймДев форумы и пииш подобный шлак =)
весь ключевой момент в том что это вар =) а не какай та С++ (или что либо) прога =)

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


чё то неочём не люблю когда отходят от дела =))) (я про посты)
есть 2 вещи

1) реально применимые вещи в варе
2) реально не применимые вещи в варе но с которыми интеерсно играть и возможно вы их рименити когданить еще в другом месте.

ну ты сейчас здесь обсуждаетьса 1. ибо второе на факте куда проще и более обсосано. это делаетьса в каждой 1ой игре или что то наподобие =)

факты:
любой альтернативный выбор юнитов в радиусе написаный в джасс как минемум будет в 5 раз медленей. сам алгоритм выбора (нативный) быстрый медленая часть это вызов каллбек функции. он равен TriggerEvaluate()

с неактивными юнитами можно просто удалить и добавлять в стек объектов что делаетьса в полне просто и без проблем. ключевой момент заключаетьса в том что это даст смысл ТОКА при количестве объектов выше ~300 до этого это будет вообще не заметно а иногда даже глючней если будут происходить частые включения отключения объектов.

вы просто незнаете всех аспектов которые здесь присуцтвуют надо расматрить не тока одну проблема а последствия которые от ниё могут происходить...

Toadcop я уже год как нерасматриваю вар как место для серьезного кодинга, потому мне больше по фкусу вещь №2)

дык не сри своими мыслями тогда тут в ВАР3 разделе =)
+ фишка в том что я это тоже обдумывал... "альтернативные свои алгоритмы" но на факте джасс медленый тем самым 75% обрубаетьса =) особено то что касаетьса игровой механики.
+ ятоже интересуеюсь как всё работает на тюею реализуетьса имея примитивные средства =)
просто еще раз повторю это вар3 раздел джасса здесь стоит постиь практические вещи =) вот и всё.
а занимаюсь я варо м лиш из за того что у меня ТсХ если бы его небыло я уже наверно почти бы и н делал ничего.

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

ну да ладно это тож оффтоп =). а так всё очень просто
"я первый сделал отрубание ненужных динамических объектов в варе" кстати я этоже делал ЕЩЕ раньше в ТРС когда я делал (не публик) демо бочек которые стояли одна на однои и их можно было сталкивать друг сдруга и они типо двигались это впринцыпе даже в ТРС карте еще и есть надо нажать Еск там падает бочка. и я помню что когда бочка стоит одна... то она отрубываетьса ну там это хуже реализовано. ну короче ладна...

ну я писал... что самое медленое это выбор юнитов вокруг. а лежишие объекты один на другом это почти ексклюзивность для вара =)

ну очевидно что это так кажетса =) т.е. там есть что то что не покоитса.

кстати демка достаточно суровая... если поставить в ниё "конкурентов" то они сразу бледно выгледят. хотя там есть свои ньюансы. ну напр многие просто не могут нормально поодерживать стояние одного на другом объекте там они проникают внутрь. у меня нет тока при больших скоростях и подобных факторах... просто что бы сделать подобные вещи чёткими надо и более сложные вычисления делать что в варе нельзя себе разрешить.