region vs area lag question

[von_Oberstain]

hi!

i'm working on a map which has lots of triggers, custom units, spells etc. naturally, lags can be significant

now the question is:
trigger uses, for example: group = units within 1000 of point matching...

resulting in group made of units in CIRCLE around point (and doing lots of calculations in process)

i assume something like:

center rect on position... / group = units withing region matching...

would be, like, infinitely faster (having just to compare coordinates), back-draws being only missing circle shaped selection (which don't care about)?

can someone pls confirm me if using region is faster than using area function?

(there is quite a lot area-based lines, i would preffer to more certain of whether this logic is true, before i change them all)

thanks in advance!

 

[kleinerhauck]

Both should take about the same time...
As long as you remove leaks both shouldn't cause lags unless used in a 0.01 timed trigger or something..

 

[Spartipilo]

Region implicates the creation and handling of the rect and the region behind it. Circular area, or Units in Range, doesn't.

 

[von_Oberstain]

ok, i don't mean to contradict you (after all, it was the question), but does your answers come from experience or is theory-crafting?

cause for determining whether unit are in circle, all points along the border must be calculated and each unit position compared to border values.

ok, not ALL border points, but game has to have at least crude approximation of circular shape, and crudest there is consists of 3 rectangular shapes per corner (implicates 3 more rect checks for other corners)

theoretically, crudest approximation of circle is still like 10 times slower than any rect operation, since it includes a number of rect operation, compared to one in case of rectangular shape

i meant to have regions of different sizes pre-created, and move rect to unit position, instead using area function

my question is, since i have ALOT of area-checks (no small triggers intervals, lags hopefully removed):
- has someone definite knowledge of this?

based on theory, rects are always faster, but processes handling regions in worldedit may not be, etc

thanks in advance!

 

[kleinerhauck]

cause for determining whether unit are in circle, all points along the border must be calculated and each unit position compared to border values.

Not really.
The game probably just checks the unit's distance to the centre of the area you are picking units from. (d = sqrt(dx^2+dy^2))

If you want to know which is faster just run a test map in windowed mode and watch ur task manager at the same time.

 

[Spartipilo]

I Know for sure that Wc3 doesn't handle circles as lots of small rects.

Warcraft 3 handles Regions and Rects as differents stuff. You can create Rects, and every Rect implies a Region behind it. There's no way to access the region.

//This is "Pick every unit in region centered at point.
call ForGroupBJ( GetUnitsInRectAll(RectFromCenterSizeBJ(GetUnitLoc(GetTriggerUnit()), 500.00, 500.00))

//GetUnitsInRectAll
function GetUnitsInRectAll takes rect r returns group
    return GetUnitsInRectMatching(r, null)
endfunction

//GetUnitsInRectMatching
function GetUnitsInRectMatching takes rect r, boolexpr filter returns group
    local group g = CreateGroup()
    call GroupEnumUnitsInRect(g, r, filter)
    call DestroyBoolExpr(filter)
    return g
endfunction

//RectFromCenterSizeBJ
function RectFromCenterSizeBJ takes location center, real width, real height returns rect
    local real x = GetLocationX( center )
    local real y = GetLocationY( center )
    return Rect( x - width*0.5, y - height*0.5, x + width*0.5, y + height*0.5 )
endfunction

It can be improved, but these are the functions in GUI.

This is the "Pick in Range"

all ForGroupBJ( GetUnitsInRangeOfLocAll(512, GetUnitLoc(GetTriggerUnit()))

//GetUnitsInRangeOfLocAll
function GetUnitsInRangeOfLocAll takes real radius, location whichLocation returns group
    return GetUnitsInRangeOfLocMatching(radius, whichLocation, null)
endfunction

//GetUnitsInRangeOfLocMatching
function GetUnitsInRangeOfLocMatching takes real radius, location whichLocation, boolexpr filter returns group
    local group g = CreateGroup()
    call GroupEnumUnitsInRangeOfLoc(g, whichLocation, radius, filter)
    call DestroyBoolExpr(filter)
    return g
endfunction

The main difference, as I said, is that the region implies the creation of the rect, the region and the group. Units in range doesn't (As long as you don't pick every unit in renga from the center of a region centered at a point...)

Less functions (calls) means less system job, which could be interpreted as less lag in some cases. How Wc3 handles the radius, I don't know, maybe it's as kleinerhauck said. I guess it's as "fast" as you can cast an ability with a circular AoE.

 

[von_Oberstain]

ok, thanks, all is clear now (+rep for both)

[edit]

additional value for me is lesson to look-up GUI in jass-form before posting, which will teach me not to just "assume" things are handled in some manner (like radius thing, which was shamefully stupid of me )

i would still like to test out the whole thing, but i doubt i'll have enough time in near future. if i do, i'll post the results, but potential gain seems much less now than i thought previously (if indeed there is any)

 

[Spartipilo]

Mmm... Regions created that way will remain there... stacking up and requiring more memory to... be there. You would need to remove the region somehow later... and that would involve at least adding the region to a variable, and then destroying the region (2 more actions, + 1 variable to store it)

 

[von_Oberstain]

can't i pre-create region and just move rect when trigger activates, instead of creating new region? i expect i need only few of them, like 300, 600 and 1000 squares.

this time i WOULD check in worldedit first, but now i'm nowhere near it

 

[Spartipilo]

Nah.. If you say exactly what you need we may be able to help you finding the best way to do it

 

[Dr Super Good]

If anything Nestharus has been saying is right, then there exist special data structures to handle efficient positional enumeration. If WC3 uses these structures (which it should seeing how often positional enumeration is used) then both methods will be likly as fast. In any case the difference between the group fillers is so small that there will be no noticable difference.

On the other hand, you having to call another function to move a rect will make it slower than enumerating units in a circle of a point definatly.

 

[von_Oberstain]

If anything Nestharus has been saying is right, then there exist special data structures to handle efficient positional enumeration. If WC3 uses these structures (which it should seeing how often positional enumeration is used) then both methods will be likly as fast. In any case the difference between the group fillers is so small that there will be no noticable difference.

On the other hand, you having to call another function to move a rect will make it slower than enumerating units in a circle of a point definatly.

interesting! did he make a use out of it? i searched his posts, but there are many...

i also *believe* wc3 engine often uses mechanics unavailable in editor - for a various reasons... let's just mention game age, and computing/graphical power available at that time - and how often speed issues still appear...

Nah.. If you say exactly what you need we may be able to help you finding the best way to do it

sure, only reason i skipped this is that i thought question is general enough and wanted to skip long text. but, ok, here it is - i'll try to be concise

1. map is TD type, more precisely two out of three unofficial LegionTD offsprings (UE and X3)
2. i'm neither original author, rather second-in-line of successors - explaining my noobness in WE (while i do have some programming background)
3. at one time, it was REALLY popular map, was hosted constantly - furthermore, lags were so low that people with bad connection (0.25mbit upload, for example) could host 4v4 easily on bnet

4. ok, intro over - at one PRECISE point in development, map became SO laggy that even hostbots couldn't handle it. fixes were applied, but game remained in host-bot power only
5. original author left project at this time (unrelated to lag issues), but left open-code version for eventual successors - concludes 'legitimacy part' ORIGINAL author = LISK, MODDER of open version = EGZE, me = merely maintainer the egze's map, which i have written permission to do

here's open map source:
http://www.legiontd.com/file/Legion150c - Editor's Version.w3x

under ABILITIES (folder) in TRIGGERs, pls look for "Autocast Mindwarp" and "Autocast Seduce smart"

i strongly believe things like that are causing lags - they give some AI to previously random triggers (as i suppose, no open code available), at heavy price - they are both needed and slowing game down

(oh, btw, leaks are fixed and number of other lags are reduced, by several people - and i thought giving you link to open map might be better - if someone far more competent than me looks at it, even for a glance) he might notice more lag culprits)

what i'm working on is FINISHED project (just to mention it's not work-in-progress or some 85% complete map) - of course, it continues to evolve and new content is being added, not helping map speeding-up

this is kinda sad, since map is now, after more than a year of working, richer, better balanced and more fun to play

what i EXACTLY want is to reduce lags to bearable point - and thought, possibly wrongly, that constant area checks and group forming are bottle-neck, or at least good part of problem

if you can help with, say, one of triggers i mentioned, i would be most grateful

if you can pin-point of some other stuff causing lags (EXCEPT leaks which are dealt with), i would be even more grateful and grant you a castle once when i achieve world-domination

thanks in advance!