User Details
- User Since
- Mar 10 2022, 2:20 AM (124 w, 1 d)
Yesterday
@phosit this diff has all the P values removed so that the only change is the roughSort function. It is basically the same for me compared to the patch as written and vanilla. If it is a lot better for you maybe we have a lead.
Alternatively, you could also just revert the line that calls compareLengthRough() (L272 in CCmpRangeManager.cpp) and see if performance is still bad.
Ok, I profiled with AI (just my opponent was AI) and the improvement was less substantial (about 1/3 the improvement for me at least)
I think the comparison is somehow wrong now: The AI always attacks units at the "North"
The second is with the patch. It's indeed better.
You can't use the same replay to compare it. It's incompatible, since unit's behave differently.
Wed, Jul 24
use getPlayerIDs where sortAllPlayers() is used to get an array of IDs.
ok the accuracy part definitely works in a26 vanilla XD.
Tue, Jul 23
good catch. I didn't test it but it looks correct.
use 24 for finding margin for performance.
ok, so in following the above, I set out to find the best margin size for performance in combat demo huge.
0- vanilla
1- roughsort as written (.../30).
2->increasing margin size starting with (.../26)
so according to the above, margin = ((d2+od2)/24) * P is the fastest.
On their own, they look like this:
0-vanilla
1-roughsort as written
2-margin divided by 24^
now this may change when using units with a lower P value like skirmishers, but it won't get so bad as the really large margin plots I showed before, since margins get smaller with larger P.
Ok this is really interesting:
If I make the margin much larger (ie margin = (d2 +od2)/5 *P, the performance gets much worse, and it is only partially rescued by removing the tiebreak. Removing the tiebreak on the regular roughSort has almost no effect, maybe because it results in fewer ties that the stable_sort doesn't have to swap.
I am not sure why changing the margin has this great an effect on performance, as it is the same amount of math, just different values.
throw an error when > 2 teams, include a warning in map description.
add small metal mines, more fish, make coastline more straight to optimize space.
Add support for river placement
improve spacing with circle placement
improve spacing with stronghold placement
var -> let, const where possible
remove dock auto placement, let place and time for dock placement be decided by the player.
Mon, Jul 22
@phosit could you profile that replay I shared above? This will tell us if the difference between your profile and mine is due to replay differences or computer differences. Maybe other differences? like petra? in my replay, I just attack moved groups of 200 units.
Tue, Jul 9
well I think it could be nice if performance was at least roughly equal to the current. @phosit are you sure that profile was from the more recent patch (the one that doesn't use isqrt)
fix playerAngle for dock placement, add stronghold and river team placements, which do not support docks (yet)
Mon, Jul 8
https://wildfiregames.com/forum/topic/118677-less-precise-sorting-in-range-manager/page/2/#comment-578105
seems like there are nice effects on melee combat due to the LOS queries.
where do I find this?
Ok and I did a version comparing tie break vs no tie breaker:
Replay 1 tie break vs vanilla:
Replay 1 no tie break vs vanilla:
Replay 2 tie break vs vanilla:
Replay 2 tno tie break vs vanilla:
RoughSortEverything (replay2):
RoughSort (replay 2):
RoughSort (replay 1, control re-measured, roughSort version from before):
Ok, so I profiled a version where I use CompareLengthRough with a fixed value of P = 3, and then used CompareLengthRough for every call to EntityDistanceOrdering. Interestingly, the performance was worse, so I think the targeted approach in the patch currently is better.
Ok, so on second thought, there is not really a need to include P in the templates. So, it could be done to just pass a bool to determine exact vs rough sorting, and then eliminate P from the function calls to compareLengthRough(). Would that be even faster?
Sat, Jul 6
ok whoever wrote that instruction set did a very good job. Now, I don't know which is which here. I uploaded the jsonp without the roughSort first, and then the jsonp with the roughSort. Is the reference always the first file uploaded?
use a curve fit to fix even player placement with respect to startAngle.
update with generator approach, something wrong with playerAngle
groupedlines -> groupedLines
When placing teams in a circle with varying team sizes, I the line between the teams shifts. Its really noticeable between teams of 1 and teams of 2. teams of 3 (third pic) is perfectly even and teams of 4 is slightly off center.
Fri, Jul 5
update to use generator, something wrong.
update to account for generator!
.
ok whoever wrote that instruction set did a very good job. Now, I don't know which is which here. I uploaded the jsonp without the roughSort first, and then the jsonp with the roughSort. Is the reference always the first file uploaded?
well I can't get the profilier to do anything on windows. Any ideas why extract.pl is giving no output in neither the json file nor the plots?
increase rounds to 20
Thu, Jul 4
implement firing in bursts.
Wed, Jul 3
@Stan @phosit thoughts on this approach? I'd expect the performance to be pretty much the same for this one, since its just adding a margin for each comparison. Ive checked things out in gameplay tests and it seems to work well. My only concern would be consistency across unit types and avoiding unintended behavior.
Tue, Jul 2
remove isqrt64 dependence
int CompareLengthRough(const CFixedVector2D& other, u8 P) const
{
u64 d2 = (SQUARE_U64_FIXED(X) + SQUARE_U64_FIXED(Y))/100000000000;
u64 od2 = (SQUARE_U64_FIXED(other.X) + SQUARE_U64_FIXED(other.Y))/100000000000;
u64 margin = ((d2 + od2) / 100) * P;
//LOGWARNING("margin %i", margin);
//LOGWARNING("compare %i, %i", d2, od2 + margin);
//LOGWARNING("compare %i, %i", d2, od2 - margin);
if (d2 < od2-margin)
return -1;.
0 is without a patch
1 is cheapsqrt3_noRough.diff
2 is cheapsqrt3_keepoldSqrt.diff
3 is cheapsqrt3.diffone can see the median get's increasingly slower.
with 2 and 3 there is more variance.
droping from 20.78 ms to 23.05 ms per simulation frame.
measured on no-visual combat demo huge.As it doesn't improve performance. What's the goal of this diff?
Given the estimated time share this function has and an increase of some 15% total execution time we are probably looking at an algorithm some 2 orders of magnitude worse than the original.
Mon, Jul 1
fix tiebreaker, use ternary expression.
Sun, Jun 30
Aren't archers at large distances already less percise?
To behave more natural? IRL not all units would should at the same target.
To be more effective?
Both?Maybe there are other solutions:
Properly sorting then getting one of the nearest N entities.
First rounding then sorting.
...
add vs2017 intrinsic
droping from 20.78 ms to 23.05 ms per simulation frame.
measured on no-visual combat demo huge.As it doesn't improve performance. What's the goal of this diff?
Fri, Jun 28
fix curly braces
replace the old sqrt(), add a working 64 bit log2.
Thu, Jun 27
remove isqrtEst64 call from debugging.
fix EntityDistanceOrdering
define default parameters in the declaration not definition.
read from templates.
Jun 25 2024
do integer division before finding square root to make things easier for sqrt algorithm (probably needs fewer iterations of the while loop).
Jun 23 2024
use sdl handling of intrinsics for log2
Jun 9 2024
Jun 8 2024
whats a good way to report the values involved so I know the math is working out as expected?
@phosit any ideas why this isn't affecting anything? if my function was actually called with p=100, it would cancel any sorting.
How do I go about using the different versions of count leading zeroes from GCC and VS2017?
do I need some #ifndef,#define,#endif?
Jun 5 2024
May 31 2024
May 9 2024
May 7 2024
May 5 2024
Well my reasoning is listed in the patch summary, so no need to revisit my points. Its just a complaint I heard from 3 different iber players so I thought I would make a quick patch.
In a27 the romans will get a pretty significant economy advantage and I think they should have a bit of vulnerability.
At the same time tho, increased wall garrison space will make walls more useful for defense, so maybe its best left as is.
fix missing files
May 1 2024
I tried enabling the options for mainland, and it didn't work even though the other patches are already committed. What is the update needed for these to work? it isn't clear when looking at the later updates to D4948
If I can figure out how to get them working on a couple maps, I could update these maps and my own two random maps.
This is the error log. I just used the lines from mainland.js and .json. What i did here is opened single player gamesetup, selected mainland, selected line, started a game. When I tried to start a new game, the errors made the placement option selection unavailable and clicking start game errored out too.
Apr 30 2024
Apr 29 2024
translation of "Load Game" doesn't work. It remained in english for me.