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.
Advantages:
* The enums were large (600-800 lines) and they polluted the header,
now they are in separate files (except for BufferTexture, which has
the enum small enough to be left in the same file).
* Image classes now don't need to include OpenGL headers, as they were
needed only for the enum values. With advantage of C++11's forward
enum declarations there is no need to include the enum headers
anywhere in implementation, only when particular values are needed.
* The values are now less verbose:
AbstractTexture::InternalFormat::RGB8 // before
TextureFormat::RGB8 // now
* Resolved another "trivial choice" problem (thanks @JanDupal for
introducing this term to me): how to specify the format if there are
ten ways to do it (some being massively confusing):
Image2D::Format f = AbstractImage::Format::RGB; // too long...
Image2D::Format f = Image3D::Format::RGBA; // why 3D? this works?
Image2D::Format f = BufferImage1D::Format::RGBA; // wat?
It is even worse (and more verbose) with textures:
Texture2D::InternalFormat f =
CubeMapTextureArray::InternalFormat::RGB8; // this is allowed?
To have consistent naming this change was done also with
BufferTexture::InternalFormat (now BufferTextureFormat), although there
were no trivial choice issues and the enum isn't too large. But at least
it is now less typing.
OpenGL includes are ~35k lines together and it is a waste of
compilation time to include them even if they are not needed at all
(e.g. whole SceneGraph and Physics libraries). Saves ~10s of compilation
time (6:46 before, now 6:35).
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).
It prevents unwanted implicit conversions from e.g. nullptr to Camera,
Vector2 to Physics::Point etc. By making all the constructors explicit
it is easier to routinely add the keyword to all new classes instead of
thinking about cases when to add and when not to.
Default framebuffer is now accessible throught defaultFramebuffer global
variable, named framebuffers are handled the same way as before. All
operations (clear, setViewport, blit, read) now are member functions
so they cannot be mistakenly used when unwanted framebuffer is bound.
Further rework (DSA, state tracking...) is on the way.
Got rid of InternalFormat class, now it is all in one big enum, as each
version (desktop, ES2, ES3) has different requirements and it can't be
done that way anymore (moreover that was terribly ugly solution).
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.
GLEW defines some extensions on its own and is making mistakes, which
aren't later resolved by including the official header, because the
extension is already defined in glew.h.
Hopefully these are the first and last errors found.
Magnum.h now doesn't include anything except OpenGL headers, thus
changes in Math library don't trigger recompilation of everything, but
only of things really depending on it.
Math constants moved to separate file for similar reasons, de-inlined
some functions to remove the need for some #includes.
It only caused another maintenance burden and was confusing to users.
Now when scene graph is in SceneGraph namespace there is no need for
another grouping. Namespaces are (and should be) sufficient.
This reverts commit 79945ab6fc.
Conflicts:
src/BufferedImage.h
src/BufferedTexture.h
src/Framebuffer.h
src/Query.h
src/SceneGraph/Scene.h
Desktop OpenGL and OpenGL ES 2 support can be switched using CMake
TARGET_GLES option. All functionality not supported in ES is marked in
documentation.
If targetting OpenGL ES, GLES2/gl2.h is included instead of GLEW.
Mesh class now uses VAOs only in desktop OpenGL, in ES the buffers are
bound on each draw call.
While namespaces act for hierarchy, modules are something like "tags" -
usable when you want to check related classes of e.g. CubeMapTexture.
Not sure how to name module for Math and Physics namespaces and
Contexts/Trade, though.
Fixed a few typos in extension names, fixed BPTC texture compression
typos. Removed redundant EXT_framebuffer_object from functions as the
Framebuffer class itself has it.
The requirements are cross-referenced to dedicated page, similarly to
TODO and bug lists.
Also updated / improved documentation for some texture / image formats.
Vladimír Vondruš