Jump to content

less precise sorting in range manager


Recommended Posts

2 hours ago, real_tabasco_sauce said:

Well, it is hard to say on performance: On one replay, I got a pretty sizeable improvement, but on a few others, it's been basically the same. @phosit had a significant detriment to performance on one replay. There are probably a few things that can still be done to optimize it.

Still sounds like little downside. Benefits just might be narrow. 

Link to comment
Share on other sites

It could also be a compiler difference @phosit is using GCC while @real_tabasco_sauce is using MSVC. Maybe gcc has a harder time optimizing that specific code (would be a first, since it's usually the converse but who knows)

The more logical explanation is the cause of the slowdown is not correctly identified, could be the sorting, could be the computation or something else.

  • Like 1
Link to comment
Share on other sites

The current version works like this, where near by units are evaluated with precision, and P controls how fast the margin grows with respect to distance:

image.thumb.png.0a789c56ff896831a6e9bbf532867641.png

The values above are arbitrary, just to illustrate. For a value to be sorted over another, it must surpass the other length^2 on the red line, and for a value to be considered lesser, it must be less than the other length^2 on the blue line.

So this means the effect is more noticeable at larger ranges where a single unit is more likely to be considered the closest by many ranged units (or melee units).

  • Thanks 1
Link to comment
Share on other sites

  • 3 weeks later...
  • 2 weeks later...
4 minutes ago, real_tabasco_sauce said:

If another volunteer or two could profile this patch, I'd be super grateful!

Hey, I haven't looked in details but if the goal is to improve performance this looks like a bad target to me. You've invested a lot of energy in this which is nice, but maybe you should shelve it for some time ? Given the current activity I do not want you to burn all your energy on this while you've been doing great for the rest.

If this is a major gameplay improvement that's another matter but maybe integrating some of autociv units and building hotkeys could be worthwile too

Anyway just a heads up ;)

  • Like 1
Link to comment
Share on other sites

6 minutes ago, Stan` said:

Hey, I haven't looked in details but if the goal is to improve performance this looks like a bad target to me. You've invested a lot of energy in this which is nice, but maybe you should shelve it for some time ? Given the current activity I do not want you to burn all your energy on this while you've been doing great for the rest.

If this is a major gameplay improvement that's another matter but maybe integrating some of autociv units and building hotkeys could be worthwile too

Anyway just a heads up ;)

The target isn't performance, I just want to avoid making it worse. I think its a significant gameplay improvement, as it really helps with melee units not all pathing to try and hit the first unit when there are other targets nearby (see the video I posted on page 2). Also, it helps for ranged units to not all shoot the closest unit when there are others really close behind. So for ranged units, it elegantly avoids overkill.

I suppose it also looks more cool/realistic as @wowgetoffyourcellphone pointed out earlier.

The improvement will be the best for han crossbows which experience overkill when more than 3 xbows hit an enemy ranged unit, or more than 6 xbows hit an enemy melee unit.

That being said, its not a huge departure from the way fighting works, and it may not be noticeable to the casual player. There are also possible gameplay downsides to choosing too large a P for a unit, like spreading damage too much over units. However, if one unit should be targeted, the typical player will specifically attack that unit anyway. And, with the P values being determined in the templates, any undesirable behavior can be adjusted or removed on a per-unit basis.

  • Like 1
Link to comment
Share on other sites

25 minutes ago, real_tabasco_sauce said:

Hmm, well the rough sort is a new function. If no P value is used in the template, then the regular full-precision sorting is used.

Yeah my point was calling that new function directly from js to remove the if test.

Link to comment
Share on other sites

17 minutes ago, Stan` said:

Yeah my point was calling that new function directly from js to remove the if test.

So you mean when a P exists, unitAI.js should call a separate query setup/activation function(s) in Rangemanager and use a separate EntityDistanceOrdering?

Or do you mean using the function to re-sort an existing set of targets within UnitAI.js?

Link to comment
Share on other sites

Quote

So you mean when a P exists, unitAI.js should call a separate query setup/activation function(s) in Rangemanager and use a separate EntityDistanceOrdering?

Dunno about should but might be worth checking :)

 

  • Like 1
Link to comment
Share on other sites

  • 2 weeks later...
  • 2 weeks later...
On 14/08/2024 at 12:35 PM, Stan` said:

Yeah my point was calling that new function directly from js to remove the if test.

Do you think the 'if' in EntityDistanceOrdering is wasteful (since it is done for each unit and each target)?

I could move it out to where the stable_sort()'s are called and make an EntityDistanceOrderingRough, but this would be a little bit redundant code wise.

Link to comment
Share on other sites

Maybe. But in these cases it's always better to know and test than to think. For instance my intuition would be that we should reuse all the queries results that happen on the same turn at almost the same location. Compute them once instead of 400 times and return slightly less accurate data. But it might be that this simplification could cost more than doing it 400 times.

  • Like 1
Link to comment
Share on other sites

3 hours ago, Stan` said:

Maybe. But in these cases it's always better to know and test than to think.

Ok, I'll go ahead and try it. As long as some semi-redundant code is ok.

3 hours ago, Stan` said:

For instance my intuition would be that we should reuse all the queries results that happen on the same turn at almost the same location. Compute them once instead of 400 times and return slightly less accurate data. But it might be that this simplification could cost more than doing it 400 times.

But if a unit got another unit's target data, they would choose the same target no? I suppose its trading the task of finding nearby enemies for finding nearby units, but maybe it could be a future improvement.

Link to comment
Share on other sites

 This is with a higher P value (P = 5, so +/-25% error) for demonstration purposes. To be honest I think its pretty close to ideal for xbows. I went with P = 4 in the PR: https://gitea.wildfiregames.com/0ad/0ad/pulls/6960 Edited by real_tabasco_sauce
  • Like 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...