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.
In OpenGL ES 2.0 there is EXT_draw_buffers, which I overlooked somehow,
so I added it to extension list and included in the implementation. It
combines NV_draw_buffers and NV_fbo_color_attachments, so the
implementation now selects one of the two based on which extension is
supported, preferring the EXT one. Updated the documentation to be
less confusing, fixed extension links. Also the single-output
mapForDraw() is not handled separately on ES anymore and just calls
DrawBuffers implementation with single parameter, resulting in less
generated code.
EXT_draw_buffers can also be called on default framebuffer and
apparently in ES there is no way to map front framebuffer for drawing,
so I removed it from the DefaultFramebuffer::DrawAttachment enum.
This was a leftover from some not-well-thought-out design decision. The
function is now used exclusively for binding for draw, as all
framebuffer reading functions (blit(), read()) are doing the read
binding internally. Moreover it required the user to be extra careful on
ES2, because in many cases there are no separate binding points for
reading and drawing.
The function is now parameter-less and always bind the framebuffer for
drawing. The logic for internal binding was also simplified and on ES2
there are separate implementations for single/separate binding points.
For *Framebuffer::checkStatus() the documentation was updated to explain
the meaning of the parameter on ES2 implementation. Also removed the
need for FramebufferTarget::ReadDraw binding, as it was rather
confusing.
Old *Framebuffer::bind(FramebufferTarget) is now just an alias to the
parameter-less function, ignoring the parameter. Along with
FramebufferTarget::ReadDraw it is marked as deprecated and will be
removed in some future release.
Because ARB_DSA doesn't have any way to extract image of single cube map
coordinate, we have to use ARB_get_texture_sub_image instead, thus for
cube maps the whole thing is different. That was implemented, but wasn't
mentioned in the docs and wasn't properly accounted for in
implementation switcher (I was under assumption that ARB_DSA is
equivalent to ARB_get_texture_sub_image, which is not).
Had to rework the API a bit, the original one (everything through
DebugMessage) should be still available, but marked as deprecated (and
will be removed in some future release).
The whole cycle of reading up on a feature, understanding the feature,
understanding the bigger concept under the feature and then having
understood everything so thoroughly so I can document the functionality
is time consuming.
Not sure why I chose to have offset and size in these two function, but
that's probably because I never used them in real code. The original
overloads taking pair of Vector2i are now marked as deprecated and will
be removed in future release.
This function was added to ARB_instanced_arrays spec very late and thus
some implementations don't provide it (one case being AMD drivers on
Linux). If that function is not available, the non-DSA VAO specification
is used instead.
Vladimír Vondruš