Or would this also create one thread per unit... I think if you can do this for a unit group of whatever is selected that would work?
Also for attack move units, couldn't you just queue it the move order so that after the unit is done auto-attacking the trigger will resume checking the original move pathing? Your need to save the orders as points. Or I guess you will also have to check the individual unit's pathing first..
heres the algorithim
it wont work if you just run it. it needs an efficient method to grab units and run the algorithim.
im hoping someone has a good idea on this.
identified alot of problems with above trigger
reworked alot of it (my detection of adjacent nodes didn't work properly)
basically still trying to get the performance of it down still and i've run out of ideas
it seems the main loop is whats taking all the time
creating nodes takes less than 0.1ms, sorting binary heap takes about 0.01ms, finding adjacent nodes takes about 0.3-1ms
but the main loop, even for a path 4-5 nodes long, takes about 3ms
it easily hits about 50-100ms with a 100 node path and generally hits the limit with anything larger
so, just asking if theres anything that stands out here as a glaring performance issue http://pastebin.com/BfHxRh75
might be too daunting, will just list the loops that are used.
while loop
Bubble Down(Binary Heap Sort - while loop){
}
Pick each integer from 1 to 8{
}
Find Adjacent Nodes (while loop){
}
while loop{
(main bulk of the trigger)
Bubble Up(Binary Heap Sort - while loop){
}
}
}
Reconstruct Paths(while loop){
}
ResetVars(while loop){
}
also wondering if it would be feasible to perhaps instead of calculating the entire path just calculate 20 or so nodes and wait until unit has made it to the 19th node and calculate the next 20?
Would this work?
Or would this also create one thread per unit... I think if you can do this for a unit group of whatever is selected that would work?
Also for attack move units, couldn't you just queue it the move order so that after the unit is done auto-attacking the trigger will resume checking the original move pathing? Your need to save the orders as points. Or I guess you will also have to check the individual unit's pathing first..
heres the algorithim
it wont work if you just run it. it needs an efficient method to grab units and run the algorithim.
im hoping someone has a good idea on this.
identified alot of problems with above trigger
reworked alot of it (my detection of adjacent nodes didn't work properly)
basically still trying to get the performance of it down still and i've run out of ideas
it seems the main loop is whats taking all the time
creating nodes takes less than 0.1ms, sorting binary heap takes about 0.01ms, finding adjacent nodes takes about 0.3-1ms
but the main loop, even for a path 4-5 nodes long, takes about 3ms
it easily hits about 50-100ms with a 100 node path and generally hits the limit with anything larger
so, just asking if theres anything that stands out here as a glaring performance issue
http://pastebin.com/BfHxRh75
@maverck:
might be too daunting, will just list the loops that are used.
while loop
Bubble Down(Binary Heap Sort - while loop){
}
Pick each integer from 1 to 8{
}
Find Adjacent Nodes (while loop){
}
while loop{
(main bulk of the trigger)
Bubble Up(Binary Heap Sort - while loop){
}
}
}
Reconstruct Paths(while loop){
}
ResetVars(while loop){
}
also wondering if it would be feasible to perhaps instead of calculating the entire path just calculate 20 or so nodes and wait until unit has made it to the 19th node and calculate the next 20?