Do I have to repeat it? Oh and also it produces warnings ONLY if given
function is used, so I guess the user code has *a lot* more warnings of
this kind.
Similarly to what's now done with NoInit tags for Containers::Array and
all math types such as Vector, there's now NoCreate tag for creating
wrappers without actually creating the underlying OpenGL object. The
instance is then equivalent to moved-from state. Useful to avoid
needless creation/deletion of OpenGL object in case you would overwrite
the instance later anyway:
Mesh mesh{NoCreate};
std::unique_ptr<Buffer> indices, vertices;
std::tie(mesh, indices, vertices) = MeshTools:compile(...);
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.
In the future, when I get to implement proper DSA clearing, this won't
change currently bound framebuffer and thus it might be useful to be
able to call bind() right after, e.g.:
framebuffer.clear(FramebufferClear::Color)
.bind(FramebufferTarget::ReadDraw);
I think it's better to leave the choice on the user -- whether to do
nothing (which might be slower), invalidate whole framebuffer (which
might lose data) or do scissor + clear and thus emulate the
sub-framebuffer invalidation somehow.
Also, for some weird reason I made off-by-one error in
eb32fb1c40, so the documentation for
Framebuffer::invalidate() appeared in documentation block for
Framebuffer::attachRenderbuffer(). Should be fixed now.
The documentation of ARB_invalidate_subdata mentions that all the
functions are really just a hint for the implementation to make some
performance optimizations and they are not affecting behavior at all. So
it's perfectly fine to do nothing if the extension is not supported.
I didn't do this originally as I mistakenly thought that invalidating
depth buffer would somehow behave the same as clearing it, but that's
not the case.
In most cases the label is set directly from code, e.g.:
texture.setLabel("diffuse-duck");
Avoiding conversion to std::string and passing char(&)[size] directly
will avoid one allocation and deallocation. Better solution would be to
use std::string_view everywhere, but we're not in C++17 yet.
The previous way was half-working at best, as it handled array textures
improperly. Now there is overload for each texture type. The old way
with attachTexture*D() is marked as deprecated and will be removed in
future release.
The only places where they aren't absolute are:
- when header is included from corresponding source file
- when including headers which are not part of final installation (e.g.
test-specific configuration, headers from Implementation/)
Everything what was in src/ is now in src/Corrade, everything from
src/Plugins is now in src/MagnumPlugins, everything from external/ is in
src/MagnumExternal. Added new CMakeLists.txt file and updated the other
ones for the moves, no other change was made. If MAGNUM_BUILD_DEPRECATED
is set, everything compiles and installs like previously except for the
plugins, which are now in MagnumPlugins and not in Magnum/Plugins.
Vladimír Vondruš