Initially I thought there was no reason for this to fail, but then
realized AnySceneConverter would need it. And also any other plugin
relying on something external that might fail during initialization --
there's no other moment after plugin instantiation where it could
signalize a failure, and deferring that to the first add() call,
whichever would it be, is really not a sane idea.
Wasn't really possible to split this into multiple commits, so here's
the whole thing including delegation from and to the single-mesh APIs.
What's not done here and postponed for later is:
- an ability to feed the whole importer to it, filtering away data that
aren't supported by the converter
- corresponding changes in AbstractImageConverter, where it would now
primarily accept ImageData to future-proof for arbitrary extra
key/value data
These headers are included quite often and because
<Corrade/Utility/StlForwardString.h> expands to the whole <string>, it
has quite a significant impact.
Other cases like Math/ConfigurationValue.h are not changed at the
moment, as that header is only included together with Utility::Arguments
or Utility::Configuration -- and these classes are still STL-heavy, so
avoiding std::string usage in just the ConfigurationValue
specializations doesn't help anything at the moment.
Same as the previous commit in MeshTools -- allows to pass a
Containers::Array<DescriptorSetLayoutBinding> to it without having to
form a list of references first.
This allows people to directly pass Containers::Array<Trade::MeshData>
there, without having to put them to an annoying temporary
Containers::Array<Containers::Reference<const Trade::MeshData>.
The Iterable header is included for backwards compatibility, apart from
that there should be no breaking change.
Apart from returning const T instead of T it kinda worked, but in case
of floating-point vectors it tried to operate with
`std::pair<std::size_t, const T>` internally and failed miserably.
I wondered if I should put them into the GL/VK startup log, but
while definitely useful, they don't really have any relation to GPU
drivers. So it's just here for now.
Funnily enough, this broke building of anything depending on the Audio
library with OpenAL Soft 1.22.2.
It now sets the OPENAL_INCLUDE_DIR variable for backwards compatibility
purposes, but in 1.21.1 and before such variable was not set in
OpenALConfig.cmake at all, thus this expression did nothing. But now
using this variable by accident led to
CMake Error at src/MagnumPlugins/AnyAudioImporter/CMakeLists.txt:46 (target_link_libraries):
Error evaluating generator expression:
$<TARGET_PROPERTY:OpenAL::OpenAL,INTERFACE_INCLUDE_DIRECTORIES>
Target "OpenAL::OpenAL" not found.
which is rather strange -- the OpenAL::OpenAL target (which is a local
alias scoped only to the Magnum/Audio directory from where
find_package(OpenAL) was called) *is* propagated correctly from the
target_link_libraries() call, but at the same time it's not propagated
if it's passed via target_include_directories(). I don't know why (and
probably don't want to know), in any case the expression is not needed
and removing it altogether fixes everything.
This might eventually be a supported case (an object referencing three
meshes with different primitives), but let's just cover the existing
code for now.
Basically just making use of all APIs that got invented over the last 10
years, such as using instanced test cases instead of repeatedly having
the same test code with just different strings or accessing meshes
directly by name instead of meshForName().
Additionally the test files were renamed to better group them visually,
with invalid cases being separated from valid cases so it's possible to
have instanced tests for those.
Because it somewhat confusingly may have implied that it's really
composed of 8-bit bools, and not bits. The same reasoning was used to
pick the name for Corrade's Containers::BitArray.
Backwards compatibility aliases are in place as usual, however the
internal BoolVectorConverter is now BitVectorConverter and there
unfortunately cannot be any backwards compatibility. This breaks only
GLM and Eigen integration in the magnum-integration repo, which I'm
fixing immediately. I don't expect any user code to use this internal
helper. For regular vectors maybe, for this one definitely not.
For quite a while, setSwapInterval() was reporting that "swap interval
was ignored by the driver". Since I used to have that behavior ages ago
on a NVidia Optimus machine (where it was just *impossible* to have
VSync, imagine that!!), I assumed it was a similar wart in Mesa and
didn't bother looking into it.
It turns out, however, that calling setSwapInterval(1) may result in
SDL_GL_GetSwapInterval() returning -1 instead of 1, thus helpfully
enabling late-swap behavior for me. Since -1 != -1, the code treated
that the same as if SDL_GL_GetSwapInterval() returned 0 (which was the
case with NV Optimus having broken VSync), but it's not an error in
fact.
They are required to have the same format already, so flags make sense
as well -- what's the point of saving a multi-level cube map with one of
the levels being just a 2D array, anyway?
Array texture and cubemap (array) subimage queries get
ImageFlag*D::Array, cubemap whole image ImageFlag3D::CubeMap, cubemap
array whole image get ImageFlag3D::CubeMap and ImageFlag3D::Array. No
flags are checked when uploading images or when downloading images to
views -- using an array texture as a cube map and vice versa is a valid
case, and others are probably also, so there's no point.
The flag restrictions will come into place when ImageFlag*D::YUp / YDown
etc. are a thing.
With the intention that those will eventually contain also things like
YUp / YDown, PremultipliedAlpha and such.
This commit is mostly just busywork, wiring this into [Compressed]Image,
[Compressed]ImageView and Trade::ImageData and ensuring the flags get
correctly propagated during moves and conversions. Unfortunately in case
of Trade::ImageData it meant deprecating the current set of constructor
in order to insert an ImageFlags parameter before the importer state
pointer.
The only non-trivial piece of logic is when a 2D
[Compressed]ImageView gets converted to a 3D one, then the Array bit is
implicitly dropped, as 2D arrays of 1D images are not really a thing.
Instead, it's now possible to add new flags when doing the conversion --
for example to turn a 2D image to a (single-layer) 2D array image.
Vladimír Vondruš