Resolves https://gitlab.com/OpenMW/openmw/-/issues/7891
I think this is better than just adding 8192 as an allowed option as the vast majority of GPUs would be too slow given what we know about the cost if that setting (maybe that'll change if we get rid of the unconditional conditional discard I suspect is the cause of the slowness that's there for no good reason since the shadowsbin already moves most drawables to a known alpha-free stateset).
To produce the same stats for single and multiple sources.
If there are multiple sources with different number of frames, leave the number
of values per each metric as is. For example:
source 1: [1, None, 2]
source 2: [3, None, 4, 5]
before this change becomes:
source 1: [1, 1, 2, 2]
source 2: [3, 3, 4, 5]
and after this change:
source 1: [1, 1, 2]
source 2: [3, 3, 4, 5]
In file included from apps/opencs/model/world/pathgrid.hpp:7,
from apps/opencs/model/world/idcollection.hpp:15,
from apps/opencs/model/world/idcollection.cpp:1:
In constructor ‘constexpr ESM::Pathgrid::Pathgrid(ESM::Pathgrid&&)’,
inlined from ‘constexpr CSMWorld::Pathgrid::Pathgrid(CSMWorld::Pathgrid&&)’ at apps/opencs/model/world/pathgrid.hpp:24:12,
inlined from ‘constexpr CSMWorld::Record<CSMWorld::Pathgrid>::Record(CSMWorld::Record<CSMWorld::Pathgrid>&&)’ at apps/opencs/model/world/record.hpp:39:12,
inlined from ‘std::__detail::__unique_ptr_t<_Tp> std::make_unique(_Args&& ...) [with _Tp = CSMWorld::Record<CSMWorld::Pathgrid>; _Args = {CSMWorld::Record<CSMWorld::Pathgrid>}]’ at /usr/include/c++/13.2.1/bits/unique_ptr.h:1070:30,
inlined from ‘std::unique_ptr<CSMWorld::RecordBase> CSMWorld::Record<ESXRecordT>::modifiedCopy() const [with ESXRecordT = CSMWorld::Pathgrid]’ at apps/opencs/model/world/record.hpp:92:116:
components/esm3/loadpgrd.hpp:19:12: warning: ‘<unnamed>.CSMWorld::Record<CSMWorld::Pathgrid>::mBase.CSMWorld::Pathgrid::<unnamed>.ESM::Pathgrid::mData’ may be used uninitialized [-Wmaybe-uninitialized]
19 | struct Pathgrid
| ^~~~~~~~
In file included from apps/opencs/model/world/idcollection.hpp:8:
apps/opencs/model/world/record.hpp: In member function ‘std::unique_ptr<CSMWorld::RecordBase> CSMWorld::Record<ESXRecordT>::modifiedCopy() const [with ESXRecordT = CSMWorld::Pathgrid]’:
apps/opencs/model/world/record.hpp:92:53: note: ‘<anonymous>’ declared here
92 | return std::make_unique<Record<ESXRecordT>>(Record<ESXRecordT>(State_ModifiedOnly, nullptr, &(this->get())));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Otherwise terrain textures cache has zero hits because it stores not normalized
paths. Due to implicit conversion it's possible to add entry with
addEntryToObjectCache passing a string that is converted into normalized path.
But then getRefFromObjectCache called with original value does not find this
entry because it's not converted and overloaded operators are used instead.
These warnings were always enabled, but we didn't see them due to https://gitlab.com/OpenMW/openmw/-/issues/7882.
I do not fully understand the cause of 7822 as I can't repro it in a minimal CMake project.
Some of these fixes are thought through.
Some are sensible best guesses.
Some are kind of a stab in the dark as I don't know whether there was a
possible bug the warning was telling me about that I've done nothing to
help by introducing a static_cast.
Nearly all of these warnings were about some kind of narrowing
conversion, so I'm not sure why they weren't firing with GCC and Clang,
which have -Wall -Wextra -pedantic set, which should imply -Wnarrowing,
and they can't have been affected by 7882.
There were also some warnings being triggered from Boost code.
The vast majority of library headers that do questionable things weren't
firing warnings off, but for some reason, /external:I wasn't putting
these Boost headers into external mode.
We need these warnings dealt with one way or another so we can switch
the default Windows CI from MSBuild (which doesn't do ccache) to Ninja
(which does).
I have the necessary magic for that on a branch, but the branch won't
build because of these warnings.
It turns out that it's possible for OSG plugins to be spread across multiple directories, and OSG doesn't account for this in osgDB::listAllAvailablePlugins(), even though it works when actually loading the plugin.
Instead, use code that's much more similar to how OSG actually loads plugin, and therefore less likely to miss anything.
Incidentally make things much simpler as we don't need awkwardness from working around osgDB::listAllAvailablePlugins()'s limitations.
AnyOldName3
elsid
Alexei Kotov
psi29a
jvoisin
Dave Corley
Andrei Kortunov
Sam Hellawell
uramer
Evil Eye