I expect the drivers to return size of *one* face when I'm querying that
particular face using the pre-DSA or EXT_DSA API and size of *all* six
faces when I'm querying whole texture using DSA API.
One can dream, eh?
It appears that, at least on my NVidia, the returned value does not
depend on whether I'm querying all faces or a single one, but RATHER
is based on whether the texture is immutable or not. How's that
predictable at all?! Workaround in the next commit.
Pre-DSA code paths need to specify for which face we are querying the
level parameters, which meant that all other calls had to specify the
(implicit) target too. I'm also preparing to put a cubemap-specific
workaround in the level parameter query and that really shouldn't be
present in the generic implementation for all texture types.
The other place where a specific target is needed is in setImage()
implementations, but these are rather big chunks of code and I don't
feel like copying these verbatim to cubemap implementation just to
isolate the workaround in one place.
The DSA function does not accept any texture target parameter so the
cube map texture was bound as a whole (and thus behaving as a layered
attachment) instead of just a single face. Thanks to @chpatrick for the
report.
The engine can now list all driver workarounds that were used during the
initialization. Any listed workaround can then be disabled from the
command-line using `--magnum-disable-workarounds` command-line
parameter. The disabling and querying API is private and undocumented,
because the driver workarounds should be disabled only by end-users and
not application developers. The workaround list is now empty, but will
be filled up in the following commits and the workarounds will be
probably documented only privately in Implementation/driverSpecific.hpp,
as it is really something that should be used only to debug driver
problems.
Pre-DSA code path needs to pass specific slice of a cube map to all
getters instead of just GL_TEXTURE_CUBE_MAP. I did that properly for
image size query, which weirdly enough, had its own implementation, but
forgot to do that in compressed image getters and, because I have DSA
drivers, never tested that on pre-DSA contexts.
Using single implementation of image size with explicit target
parameter now.
I can't believe that you can just forget to include some file and it
will SILENTLY PASS and then crashes horribly at runtime because each
translation unit thought that given member function pointer had
completely different size. THIS IS NOT ACCEPTABLE.
Pain and misery. Majority of functionality for 3D compressed images now
suddenly fails the test -- this is either very vaguely specified or I am
very bad at understanding things or there are bugs in my NVidia drivers.
This was awful feature. Kill me now.
Yeah, sorry, I know, the enums are renamed for second or third time in a
row, first they were Image::Format, then ImageFormat, then ColorFormat
and now PixelFormat. But this time it's final and last time they are
renamed and now everything is finally consistent:
* ColorFormat::DepthComponent -- depth is not a color, thus
PixelFormat::DepthComponent makes a lot more sense.
* There will be PixelStorage classes, which will be stored in images
alonside PixelFormat/PixelType enums, making everything nicely
aligned.
* The GL documentation about glTexImage2D() etc. denotes the <format>
and <type> parameters as format and type of *pixel* data, so now we
are _finally_ consistent with the official naming.
I wonder why did I not choose PixelFormat originally. Anyway, the old
<Magnum/ColorFormat.h> header, ColorFormat, ColorType and
CompressedColorFormat types are now aliases to the new ones, are marked
as deprecated and will be removed in some future release (as always, I'm
waiting at least six months before removing the deprecated
functionality).
Currently the user had to ensure that buffers added to mesh were not
moved at all, which was very annoying, basically each one of them had to
be allocated on heap. Now the Mesh stores a weak copy (yes, really) using
Buffer::wrap() with no deletion on destruction, so the original instance
can be freely moved around without any fear of crash.
Thanks to @Squareys for the original idea/request about wrap() functions,
really useful part of the API.
Intel drivers on Windows print out "No errors." when the shader is
compiled/linked successfully. I consider that as unnecessary spam and
filter it out.
The original goal was to avoid branches when binding the vertex
attributes for drawing, so I stored float, integral and double
attributes in separate std::vector instances and then was going through
each one of them in separate loop. In retrospect that was _not_ a good
idea, because it results in larger Mesh class, two more allocations
resulting in far more pointer chasing and more complicated
constructor/destructor.
Now everything is stored in a single vector. I may optimize it further
by not calling the constructor/destructor on it when VAOs are used.
This was the actual problem. Most of ES extensions are not available in
WebGL, thus the GL headers and the code was far more bloated than it
needed to be. The GL header is now reduced and the previous 13 commits
were disabling features that aren't actually available in WebGL.
The final executable size is reduced by ~50 kB, which actually isn't
much, but still something.
Some ES extensions (ANGLE_depth_texture and ANGLE_instanced_arrays) have
now WEBGL_* prefix. I'm still using the original prefix in the
implementation because there are headers for these, but in public docs
and elsewhere they are exposed with WEBGL_*.
Actually properly supporting ANGLE_instanced_arrays. Emscripten
currently has the functions without the ANGLE suffix. Only causes linker
warnings when not used, need to fill a bugreport and fix properly.
Vladimír Vondruš