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.
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.
We don't have extension loader for ES yet, thus we need to abort on
these to avoid undefined behavior. The only exception is NaCl, which
provides _some_ extensions without the need for extension loader. These
extensions are implemented in particular:
CHROMIUM_map_sub
EXT_occlusion_query_boolean
Can't test EXT_debug_label, as that is apparently OSX 10.9-only. Added
GL tests for all implemented objects. KHR_debug is selected first, if
that is not available, fall back to EXT_debug_label. If neither is
available, the functions are no-op.
I hope EXT_debug_label gets replaced by KHR_debug later, thus it is now
only "emulated" through KHR_debug enums.
Encourages vectorization and generic usage even more. Some functions
were rewritten to make use of the new features, resulting in shorter and
more readable code. This also fixes the annoying naming collision with
WINAPI Rectangle() function.
The old Rectangle is now subclass of Range2D, is marked as deprecated
and will be removed in future release.
GL_NONE is fortunately zero, so we can skip std::fill_n altogether and
replace it with zero-initialized allocation. Added just-in-case
static_assert to check that.
Makes the lines shorter, the conversions are mainly from strongly-typed
enums to underlying type, so nothing potentially harmful which should be
marked with static_cast.
Passing pointer as function parameter will now mean that it is possible
to pass `nullptr`. Some code examples now look like the parameter is
copied instead of referenced, which is misleading. Updated the
documentation to reflect that more clearly.
Makes some cases less consistent (and some convenience shortcuts
impossible), but goes well with the attitude "don't use pointer when it
can't be null".
Instead of having pair of functions for depth/stencil and color
attachments this is now solved using specialized class. It is now more
descriptive, as specifying color attachment is now done explicitly using
Framebuffer::ColorAttachment(2) instead of just `2`. Specifying "no
attachment" is now also done explicitly using
Framebuffer::DrawAttachment::None instead of `-1`.
Also updated related documentation.
Framebuffer::attach*() doesn't need the target at all (meaning the
attachment will be used for both reading and drawing), another
misunderstanding on my side.
Now the extension is used on all places where it can be used (except for
unimplemented features).
Viewport position and size is managed separately for each framebuffer
and glViewport() is called in bind() (and also from setViewport(), if
the framebuffer is currently bound) if the viewport differs from
current state. If used only one framebuffer size through whole
application lifetime, glViewport() doesn't need to be called at all.