Because the uncolored overly verbose output was ridicilously ugly and
hard to navigate for larger scenes. Like with TestSuite executables,
there's a --color option that defaults to automatic coloring based on
whether printing to a TTY and can be both explicitly enabled and
disabled.
Again not publicly documented because I don't like the naming and I
don't have the full behavior and interactions figured out yet -- i.e.,
an array of VertexFormats would be printed with Debug::packed as a long
string of characters without any whitespace. Not good, thus this
feature probably needs to be split in two, with this being named
"compact" or something else.
It limits the support for CMake 3.12+, but it's much less verbose and I
don't expect people to use ancient CMake versions with IDEs like Xcode
or VS anyway, so this should be fine.
Except for file callbacks, for these I have another change planned for
zero-copy import and it would be unwise to break stuff twice, providing
two sets of backwards compatibility wrappers. The image / scene
converter plugins went through a similar change earlier already and the
shader converters were made sane since the very beginning. OTOH audio
importers and text stuff are scheduled for merging with Trade or a
larger rework anyway, so I didn't see any point in updating those.
It's mostly a trivial change, except that returned String instances are
now also checked for non-default deleters same as Arrays because yes,
wow such flexibility compared to STL strings. Same was done for
ShaderTools::AbstractConverter already anyway, so nothing unheard-of
either.
The importer plugin interface version is bumped as this likely breaks
ABI in a nasty way that would lead to crashes.
I wanted to avoid including extra stuff with the Manager.hpp split, but
this would make it even worse than having Array and String included
unconditionally. Fortunately it's enough to simply not even have the
declaration.
This would fail to build when Corrade is built w/o deprecated APIs but
Magnum is with. Rare case, but I just hit it while testing, so I guess
it's valid.
For file opening there's no longer an unatomic pair of exists() +
read(), but since Path::read() now returns an Optional, it means we can
reliably distinguish between empty files and failures.
While at it, also added TODOs for removal of the StringStl.h header
that's needed in various places for compatibility with APIs still using
STL strings.
It's dangerous, as in case of failure it will attempt to print them as
strings. Plus now with latest de-std-string-ification of TestSuite it
causes the compilation to fail due to an ambigupus overload.
This should eventually be catched and disallowed directly by the Tester
class.
With really huge materials it's kinda useless to not know which layer
the error happened in -- and usually it's exactly because the layer
indices were specified wrong.
It was a clever harmless trick. Well, it was way more harmless than it
was clever, but even then it caused UBSan to complain. And that's Not A
Good Thing for various reasons, so let's just comply.
The main bad effect of this change is a *slightly* larger list of
exported symbols but until we actually get rid of the major bloats like
<iostream>, <string> and the like, this is not going to have any
measurable impact.
Like, I can't even, why does it warn for function *definitions* for a
deprecated class which don't even use the deprecated class name anywhere
except the fully qualified name? Why does it warn here but not for, say,
ObjectData2D?
Warning that a *deprecated class* copy/move constructor/assignment is
deprecated is useless. Good thing the newer versions fixed that,
nevertheless it's still beyond annoying to see in the CI output.
The previous commits changed *nothing* related to this code, yet somehow
a Release build started warning about this variable maybe being used
uninitialized in the attribute checking loop even though it's *clearly*
not the case.
Tools are getting less useful and more annoying DAY BY DAY.
This mirrors what's done already for implementation-specific vertex
formats, thus:
* Ability to construct the classes without tripping up when trying to
check for type size in various asserts
* Providing a zero-size type-erased access in indices() and
mutableIndices()
* Disallowing typed and convenience access
The type is now extended to 32 bits. In the GL and Vk libraries it means
one can now do things like
MeshIndexType type = meshIndexTypeWrap(GL_UNSIGNED_BYTE);
and passing that to GL::Mesh or Vk::Mesh will cause it to use the value
directly, instead of doing a mapping from a generic type. The *real* use
case for this is however to allow custom index buffer representations in
Trade::MeshData. Support for that will be hooked up in the following
commit.
Also not something the classic GPU vertex pipeline can handle, but
useful for other scenarios. Subsequently a support for array indices
will be added, allowing to directly represent for example OBJ files,
where each attribute has its own index buffer.
This is not something the classic GPU vertex pipeline can handle
(except maybe Vulkan, which can handle zero strides for instanced
attributes?), but useful for other scenarios. This means existing code
needs to be aware of and handle the new corner case.
This took me quite a while to realize -- not always it's desirable to
have the original layout unconditionally preserved, especially if for
example filtering a MeshData to just a subset of attributes.
No functional change, just splitting them to two separate headers and
two separate tests. These will eventually become public SceneTools
APIs... once I figure out better naming.
Probably a leftover from when these dependencies were handled in a
much shittier way? For as long as I remember, enabling WITH_GL_INFO
always enabled WITH_GL and WITH_WINDOWLESSWHATEVERAPPLICATION
implicitly.
Vladimír Vondruš