Don't try to look for them if we don't use them. It only makes people
install additional outdated crap on their machines for no reason. The
only case where platform-specific GL headers are needed is in case of
iOS which doesn't provide any means of function pointer loading, but
there the include is passed implicitly from the framework.
Emscripten's MINIMAL_RUNTIME requires -lGL or -lopenal to be specified
(the default does that implicitly). It doesn't hurt to do that every
time and it makes the Find modules slightly simpler.
Instead of them being deleted. This was not possible in the times where
GCC 4.7 compatibility was a thing, but now that's long gone.
And of course I forgot the l/r-value overloads on CompressedImage :/
This one returned a raw pointer, losing all size information, One should
instead use the non-templated data() along with Containers::arrayCast()
for a properly type-checked conversion.
There's *a lot* of tests using the deprecated functionality. I need to
change one more thing before updating those.
If building with deprecated features enabled, the buildsystem checks if
the option is still set and is inconsistent with what Corrade reports
and reports a deprecation warning. For backwards compatibility the
MAGNUM_BUILD_MULTITHREADED CMake variable and preprocessor macro are
still provided as well.
Note -- since there are no visual tests for Phong yet, this is done in
the least intrusive manner to avoid breaking current functionality. It's
likely very underperforming due to the matric calculation per fragment,
it'll get optimized once I have proper tests.
Also move it to a new GenerateNormals.h header so we can easily add
generateSmoothNormals() to it. The old API and header is deprecated and
will be removed in the future. I can't be bothered rewriting the old
code using the new thing, so it's preserved there as a mausoleum until
it gets finally nuked from the orbit.
Provide a version taking StridedArrayView instead, taking an arbitrary
view and also arbitrary index type. Also introduce duplicateInto() which
doesn't even allocate, but rather writes the output to pre-existing
location.
Found while working on the Python bindings --- BoolVector4(0b1010) got
printed as BoolVector(0101), which is totally confusing. Now it prints
it in a way that looks exactly the same as when constructing the vector
with binary literals.