`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.
This allows to distribute AI reaction calls over time.
Before this change actors appearing at the same frame will react in the same
frame over and over because AI reaction period is constant. It creates a
non-uniform CPU usage over frames. If a single frame has too many AI reactions
it may cause stuttering when there are too many actors on a scene for current
system.
Another concern is a synchronization of actions between creatures and NPC.
They start to go or hit at the same frame that is unnatural.
Measure time at the computation end but before sleep. This allows to adjust
sleep interval for the next frame in case sleep is not precise due to syscall
overhead or too low timer resolution.
Remove old frame limiting mechanism.
Before movement calculation, the main thread prepare a
vector of ActorFrameData, which contains all data necessary to perform
the simulation, and feed it to the solver. At the same time it fetches
the result from the previous background simulation, which in turn is
used by the game mechanics.
Other functions of the physics system (weapon hit for instance)
interrupt the background simulation, with some exceptions described
below.
The number of threads is controlled by the numeric setting
[Physics]
async num threads
In case 'async num threads' > 1 and Bullet doesn't support multiple threads,
1 async thread will be used. 0 means synchronous solver.
Additional settings (will be silently switched off if async num threads = 0)
[Physics]
defer aabb update
Update AABBs of actors and objects in the background thread(s). It is not an especially
costly operation, but it needs exclusive access to the collision world, which blocks
other operations. Since AABB needs to be updated for collision detection, one can queue
them to defer update before start of the movement solver. Extensive tests on as much
as one installation (mine) show no drawback having that switched on.
[Physics]
lineofsight keep inactive cache
Control for how long (how many frames) the line of sight (LOS) request will be kept updated.
When a request for LOS is made for the first time, the background threads are stopped to
service it. From now on, the LOS will be refreshed preemptively as part of the background
routine until it is not required for lineofsight keep inactive cache frames. This mean
that subsequent request will not interrupt the background computation.
Refactoring related to "smooth movement"
See merge request OpenMW/openmw!285
(cherry picked from commit 6eaf0a389d5aed3b74ab1a7cf89574612f964bdf)
e847b4c8 Split getSpeed() to getMaxSpeed() and getCurrentSpeed()
a96c46bc Refactor calculation of movement.mSpeedFactor
03ee9090 Use getMaxSpeed instead of getCurrentSpeed where it makes sense.
a178af5c Create helper functions `normalizeAngle` and `rotateVec2f`
context menu.
The documentation opens in default browser.
There are 3 contexts:
- global: opens the OpenMW CS User Manual main page
- when a record is selected: opens the "Tables" page
- when the filter field is selected: opens the "Record Filters" page
There is also a link to the OpenCS tutorial in the help menu.
