Merging two sorted sequences is is something I always struggle with to
write from scratch. Fortunately here I could just reuse what got done for
DebugTools::CompareMaterial already, haha.
Such an unnecessary footgun -- I was already checking the other case,
having attribute data too short, but this I thought is fine because it's
not leading to any crash. Well it's leading to needless pain and
suffering, that's what it is doing!
And of course already found FIVE such bugs in just Magnum tests alone.
Okay, GCC 12, this warning about an uninitialized member was actually
helpful, thank you. Too bad I didn't see it in all the useless
warning noise that you also produce.
Having code snippets in docs compiled and checked for syntax and
outdated API errors is great. In theory. In practice the people reading
docs have NO IDEA how much needless suffering goes into making the
compiler collaborate with me on such a seemingly simple task. UGH.
Say how many devices there were in total, so it's possible to
distinguish the case of trying to find a CUDA device on a machine with
no NVidia GPU (where it says it found some other EGL devices) and the
case of drivers being completely broken for some reason (where it says
it didn't find any device at all).
Uses StridedBitArrayView underneath. Waited for this container to exist,
because implementing this using bools and wasting 8x more memory wasn't
a good option. Plus, being able to address single bits opens a
possibility to describe individual bits in enum flags, whereas the only
other option would be to take the whole flag as an opaque type
containing "some bit values".
Apparently I forgot to actually test these -- in order to fit the string
data pointer without making SceneFieldData too large, it'đ stored as an
offset from fieldData. And that's something not expressible in a
constexpr context. Thus the only way to create a constexpr string field
is by using the offset-only constructor (which is now appropriately
tested).
This change at least allowed me to move the constructor to the cpp file,
saving on header size and using more lightweight assertions.
Counterparts to the sRGB-converting APIs, for when one doesn't want to
perform sRGB conversion. Or for "wrong sRGB" workflows. Named like this
and not just `fromRgbInt()` to make the calls at least a bit suspicious.
I should probably go over all Math tests and include Magnum.h there. No
idea why did I do it like this back in 2010, maybe to have the Math
library "independent" from the rest of Magnum? That can be done even
without having to suffer like this...
The glTF importer plugin contains functionality that's present only in
deprecated builds (backwards compatibility for skinning mesh
attributes), which isn't causing any API signature difference but rather
a difference in behavior. So expand the docs to say it's not limited to
just APIs but features in general.
Somehow I forgot to cross-reference the SceneFieldData constructor and
mention which are usable for strings and which not, and that no builtin
fields are strings.
This got probably implemented long before the change in
c74b4c6b90. Or actually maybe not at all.
In any case, it'd cause an ambiguity with the 2D char view constructor
when the "updimensioning" StridedArrayView constructor gets introduced.
I did that just to be sure that 3c8fd70c12
didn't break anything, but to my surprise arrived at a difference
somewhere completely different.
The problem is that the SVGs were generated before Math::pack() was
fixed in e62ce4faa6 (Feb 2019) to perform
correct rounding, and so most color values were off by one. Heh.
Vladimír Vondruš