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.
They provide the same or slightly different functionality as is present
in ES3 itself, causing confusion. Fortunately this change required only
one modification in Context test and nowhere else.
There will be many places (e.g. all
Platform::*Application::Configuration classes) where Version will be
used without Context (and all GL stuff brought with it).
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
Previously this was done in DebugMarker only via GREMEDY_string_marker
on desktop and EXT_debug_marker on ES, now supporting both three on
desktop and KHR/EXT version on ES. The old DebugMarker is now only a
thin wrapper around DebugMessage, is marked as deprecated and will be
removed in future release.
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.
Resolves some linker errors in Windows, removes code bloat from Platform
namespace (previously it was copied in _every_ *Application).
Originally this was in Platform namespace because I thought that it
would be possible to have one version of Magnum library for both desktop
and ES and the actual Application would determine which GL edition will
be used. Fun idea, but it would remove the static checks (e.g.
accidentaly using geometry shaders on ES), which isn't worth it.
It contains a few (un)packing functions present in ARB_gpu_shader5, but
isn't mentioned anywhere except GLSL 4.20 changelog (and there it has
its old name, ARB_shading_language_pack2f). It might be supported on
machines where ARB_gpu_shader5 can't be supported (GL3 HW).
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.
Separated EXT_framebuffer_object, EXT_framebuffer_blit,
EXT_framebuffer_multisample and EXT_packed_depth_stencil don't have the
same functionality as ARB_framebuffer_object (e.g. missing
GL_FRAMEBUFFER_UNDEFINED in glCheckFramebufferStatus()) and separated
read/draw binding is only in EXT_framebuffer_blit, which complicates the
internals.
Checked with Mesa 8/9 and OpenGL 2.1, current one has
ARB_framebuffer_object and also all these four, Mesa 7.7 didn't have
EXT_framebuffer_multisample, but that's a long time ago, so not
supporting these separate extensions shouldn't be an issue.
The problem with unavailable separate binding points remains on OpenGL
ES 2.0, there are three different extensions bringing that
functionality, thus the code managing the available binding points
remains there.
Not relying on GL version when asking for extensions, i.e. Mesa might
know glGetStringi() even if it reports OpenGL 2.1 only. Similarly in
shadingLanguageVersionStrings(), not all HW is capable of 4.3, but
GL_NUM_SHADING_LANGUAGE_VERSIONS might be supported on GL3 HW too (not
my case, though).
Robust *Framebuffer::read() access, ability to query robust buffer
access behavior in Context::flags(), ability to check graphics reset
status and reset notification policy in Renderer.
OpenGL 3.0 specification is awesomely confused with extensions. The ones
listed in specs don't have the complete functionality and references
to related ARB extensions are nowhere to be found.
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.
Vladimír Vondruš