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.
Buffered* hinted that it has something to do with caching, streaming or
whatever. "Buffer texture" is now also consistent with naming in
specification.
On OpenGL 3.3 context it was checking for support of all 3.0, 3.1 and
3.2 extensions even if isExtensionSupported() didn't use that
information at all.
Some target platforms supply their own OpenGL headers, thus we cannot
use our own from ES 3.0 and compilation fails.
On the other hand, this will be better for users as usage of unsupported
features will be catched right during compilation and not at runtime.