`ciCompareLen(a, b, b.size()) == 0` expression is an equivalent of checking for
equality of `a` prefix with size `b.size()` with `b`.
`ciCompareLen(a, b, a.size()) == 0` is also the same thing but `a` is a prefix
`b` should start with.
Engine controls lifetime of managers therefore it should own them. Environment
is only access provider.
This allows to avoid redundant virtual calls and also some functions from
managers base classes can be removed if they are used only by Engine.
../../components/misc/color.cpp: In static member function 'static Misc::Color Misc::Color::fromHex(std::string_view)':
../../components/misc/color.cpp:36:24: error: 'v' may be used uninitialized in this function [-Werror=maybe-uninitialized]
36 | rgb[i] = v / 255.0f;
| ~~^~~~~~~~
This prevents actors going back when a new shortest path includes a point
behind them where they were right before. Such situation can happen when path
includes off mesh connection. Resulting cost of such path can be lower than
the real one because off mesh connections are straight lines and walking
surface usually is not a plane but a surface.
Skip to path point where distance from current position to the line between
previous and this point is less than point tolerance. Which means actor is
standing very close to the edge between those points. Additionally check by
navmesh raycasting to make sure there is actually a valid path.
With this PR we refactor `StringUtils::replaceAll` to accept `string_view` as suggested in a code comment. In addition, while we are touching this rebuild happy file, we slim it down a bit by moving a few sparingly used functions elsewhere.
This PR removes unneeded `lowerCaseInPlace` calls in in a hot path of `objectpaging.cpp` that are no longer necessary after PR #3197. In addition, I have been informed that these changes should by coincidence address a compiler specific compilation error we currently experience.
This PR aims to spark the retirement of a questionable pattern I have found all over our code base. I will illustrate how this pattern encourages code duplication, lacks type safety, requires documentation and can be prone to bugs.
```
std::map<std::string, Object> mMap; // Stored in all lowercase for a case-insensitive lookup
std::string lowerKey = Misc::StringUtils::lowerCase(key);
mMap.emplace(lowerKey, object);
std::string lowerKey = Misc::StringUtils::lowerCase(key);
mMap.find(lowerKey);
mMap.find(key); // Not found. Oops!
```
An alternative approach produces no such issues.
```
std::unordered_map<std::string, Object, Misc::StringUtils::CiHash, Misc::StringUtils::CiEqual> mMap;
mMap.emplace(key, object);
mMap.find(key);
```
Of course, such an alternative will work for a `map` as well, but an `unordered_map` is generally preferable over a `map` with these changes because we have moved `lowerCase` into the comparison operator.
In this PR I have refactored `Animation::mNodeMap` accordingly. I have reviewed and adapted all direct and indirect usage of `Animation::mNodeMap` to ensure we do not change behaviour with this PR.
The idea is to avoid std::map lookup for each CellRef. Instead generate a
sequence of added and removed RefNums into a vector then order them by RefNum
using a stable sort that preserves relative order of elements with the same
RefNum. RefIDs are stored in a different vector to avoid std::string move ctor
calls when swapping elements while sorting. Reversed iteration over added and
removed RefNums for each unique RefNum is an equivalent to what map-based
algorithm produces. The main benefit from sorting a vector is a data locality
that means less cache misses for each access. Reduces ESMStore::countRecords
perf cycles by 25%.
Add special loading progress bar.
It should be fast enough to not keep loading screen for noticably long but
will provide better pathfinding for actors inside interior cells.
rtprio is both a struct and a function, so we need to be explicit.
../../../components/misc/thread.cpp:53:9: error: must use 'struct' tag
to refer to type 'rtprio' in this scope
rtprio prio;
^
struct
/usr/include/sys/rtprio.h:91:5: note: struct 'rtprio' is hidden by a
non-type declaration of 'rtprio' here
int rtprio(int, pid_t, struct rtprio *);
^
1 error generated.