First, do a ray intersection test with the bounding-sphere for all
entities on the map and then check the more detailed selection shape for
the remaining candidates. Do checks that require component lookups after
the ray intersection tests because these are relatively expensive.
The old method for figuring out which entities are below the mouse
cursor was incorrect because it does a 2D check to filter out the first
candidates which can lead to incorrect results with lower camera angles
and high buildings or buildings with a large footprint. Such problems
were avoided with quite a large radius for this 2D test and resulted in
a large number of candiate entities after this first test (200-500).
Also rename PickEntitiesAtPoint to PickEntityAtPoint and make it return
only one (the closest) match.
I've tested performance with the tracelogger by starting a map and then
moving the mouse in circles for one minute. The results were relatively
stable. I've compared the total time percentage of input.js:836, which
spends nearly all of the time in PickEntityAtPoint.
Ardennes Forest - Normal size: Original: 41.46% Patched: 31.6%
Ardennes Forest - Giant size: Original: 40.59% Patched: 51.55%
As we see, it's faster on normal map sizes but slower on giant maps with
a lot of entities.
This approach can be further improved with some kind of spatial
subdivision for the culling (like an octree), which would help the unit
renderer too. This way it should be possible to make it faster (and
still correct) on all map sizes and with a large total numbers of
entities.
This was SVN commit r16098.
Previously we removed all players and created them anew. This caused
issues in Atlas,
as some components were recreated, but did not get informed about
already existing
entities (eg cmpTechnologyManager). By only creating/deleting players
until we obtain
the new number of players we do not have this issue.
This was SVN commit r16080.
Tested in combat demo huge where nearly 50% of the replay time is spent
looking for new targets, and GetPreference is called a lot as used to
sort possible targets.
Caching the preferred classes before the second loop, the replay time of
combat demo huge is reduced by about 15%. Replacing the "for each" loops
by "for of" loops gains an additionnal 7%.
This was SVN commit r16057.
The tracelogger has shown one of the functions as 4.9% and one as 2.2%
before the patch. After the patch, both functions were below 0.5%. 100%
is the time for all JS code being executed during a non-visual replay,
including GC, overhead for the tracelogger and JIT code compiling.
This was SVN commit r16036.
