On Emscripten this was equal to ";somebogusprefix" (as per the
toolchain), which got expanded into just somebogusprefix, losing the
empty string. Saving it back to CMAKE_FIND_LIBRARY_PREFIXES would cause
all subsequent find_library() calls to fail, because no library is named
somebogusprefixMagnum*.bc.
Thinking about this, the "somebogusprefix" was probably added "back
then" as a workaround to CMake complaining that I'm messing up in the
Find module. So I guess I can remove that as well.
Size of all executables got inflated by *half a megabyte* because of
this. I'm not sure if the change is worth it, so reverting for now.
This reverts commits
c01961ba6b5fb3f435ddfada6fba05
Since 98a676ef65, on ES2 and WebGL1 the
Texture::setStorage() emulation passes the pixel format to both <format>
and <internalFormat> of glTexImage() APIs. On desktop the go-to way to
create a sRGB texture is by passing GL_SRGB to <internalFormat> and
GL_RGB to <format>, but here GL_RGB was passed to both and thus the
information about sRGB was lost.
With the new PixelFormat::SRGB and PixelFormat::SRGBAlpha enums that
are present only on ES2/WebGL1 this case is fixed -- sRGB texture format
will get translated to sRGB pixel format and that used for both
<format> and <internalFormat>.
Another case is when EXT_texture_storage is available -- passing unsized
GL_SRGB_EXT or GL_SRGB_ALPHA_EXT to glTexStorageEXT() is an error and
there's apparently no mention of this in any extension, making it
impossible to create sRGB textures using EXT_texture_storage. I bit the
bullet and tried passing the (numerical value of) GL_SRGB8 and
GL_SRGB8_ALPHA8 to it. At least on my NV it worked, so I enabled these
two in TextureFormat for ES2. No EXT_texture_storage is on WebGL1, so
they are only on ES2.
These two sized TextureFormat::SRGB8 and TextureFormat::SRGB8Alpha8
formats are translated to GL_SRGB and GL_SRGB_ALPHA and so using them
unconditionally for all platforms (except WebGL1) "just works".
Used `#pragma warning(suppress: 4996)` before which was apparently doing
completely nothing. Switched to `#pragma warning(disable: 4996)` now.
Started to become problematic on latest MSVC 2017 update (19.11) -- the
UWP builds are failing because of implicit warning-as-error.
There's a new DynamicAttribute class that is very similar to Attribute,
but it has the location and base type as runtime properties instead of
them being a part of template. This allows for more flexibility, but
OTOH also more typing and more responsibility on the user. See
MeshGLTest for details and usage comparison to the Attribute API.