Caused linker problems mainly on Windows, where every symbol would need
to be exported manually, on Linux this was done implicitly (or with
`-fvisibility=default`). I now maintain glLoadGen fork at
https://github.com/mosra/glloadgen.git containing changes needed for
Magnum.
The `ogl_*()` functions are used only internally, various global
variables for extension queries are not used at all and thus they don't
need to be exported. I thus enabled `-fvisibility=hidden`.
Fixes#16.
Resolves some linker errors in Windows, removes code bloat from Platform
namespace (previously it was copied in _every_ *Application).
Originally this was in Platform namespace because I thought that it
would be possible to have one version of Magnum library for both desktop
and ES and the actual Application would determine which GL edition will
be used. Fun idea, but it would remove the static checks (e.g.
accidentaly using geometry shaders on ES), which isn't worth it.
It's counterintuitive when you have to enable `WITH_GL_TESTS` just to
install the header, moreover the dependent projects have no easy way to
detect the header presence, so they just fail on preprocessor error.
Removed all known GLEW workarounds, added one small workaround for
missing ARB_texture_compression_bptc. I didn't want to patch glLoadGen
for just four enum values, this way it's possible to use stock one
without any patching (except for missing OpenGL 2.1 support, as stated
in external/OpenGL/GL/README.md).
As one file now replaces both `glew.h` and `glcorearb.h` and it has the
same size as `glcorearb.h` alone , it saves approximately 18k LOC,
resulting in 15 second shorter compilation time (5:03 before, 4:48 now).
Not bad.
It contains a few (un)packing functions present in ARB_gpu_shader5, but
isn't mentioned anywhere except GLSL 4.20 changelog (and there it has
its old name, ARB_shading_language_pack2f). It might be supported on
machines where ARB_gpu_shader5 can't be supported (GL3 HW).
Now named MaterialType. It's easier to type this:
auto t = Trade::MaterialType::Phong;
Than this overlong name, which is moreover ambiguous due to subclassing:
auto t = Trade::AbstractMaterialData::Type::Phong;
// or should I use rather Trade::PhongMaterialData::Type::Phong?
This requires inclusion of heavyweight <memory> header (~25k LOC), but
data import isn't something the user would want to do in every file, so
it hopefully won't hurt compilation times too much.
Saves unnecessary heap allocation and saves user from the burden of
explicit deletion, otherwise the usage is the same. Polymorphic types
can't be done using `std::optional`, will fix that later.