According to reports on delphigl.de this extension is far more supported
in comparison to the NV version (and also there's much less FF cruft in
the specification).
In OpenGL ES this is implemented in EXT_multi_draw_arrays extension, if
it is not available, the functionality is emulated using sequence of
normal draw() calls.
Functionality provided by GL 3.3 and ARB_instanced_arrays, on ES2 this
is again implemented in three different extensions --
{ANGLE,EXT,NV}_instanced_arrays. They are disabled until Magnum has
proper extension loading on ES.
On desktop GL this is provided by ARB_draw_instanced (GL 3.1). Base
instance is available only on desktop GL (4.2, ARB_base_instance). In
ES2 the instanced functionality is provided by three (!) different
extensions (ANGLE_instanced_arrays, EXT_draw_instanced,
NV_draw_instanced), the proper implementation is chosen on context
creation based on what extension is available. Though we don't have
extension loader for ES yet, thus all these extensions are disabled and
the implementation has assertion in it.
Added blind test which tests only that something has been drawn and no
errors were emitted, but not whether the right command is used. I'll
probably need to check this later, because the Mesh::draw() behemoth is
going slightly out of hand :)
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.
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).
Related to issue #27 -- layout() qualifier causes compiler errors on
GLSL 1.40 (GL 3.1) on Mac OS X even that the extensions are marked as
supported. Bumping the minimal required version disables the extensions
on this versions, which should avoid the issue.
It is not proper fix at all, but most of the GL3 implementations are
now at least GL 3.2, so it shouldn't be too much of an issue. The only
exception is Mesa (GL 2.1/3.1 on most of the machines), but we need
to maintain GL 2.1 compatibility for it anyway.
Even if the extension specification describes the minimum required
version as GL 2.1 (or doesn't mention it at all), most compilers can't
handle `layout(...)` before input/output declaration. These drivers mark
the extensions as supported on GL < 3.1, but then can't handle them at
all: Mesa fails to compile it with GLSL 1.20, NVidia fails with GLSL
1.30.
Also updated `EXPLICIT_*` defines in Shaders/compatibility.glsl to
reflect this change.
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).
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.
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.