Good thing I checked this -- based on WebGL I was under assumption that
all GPUs have it just 256, but that was really just WebGL limitation.
Also ugh why this query wasn't there since the 90's?
What's left is *a lot* of places taking monstrous
std::vector<std::reference_wrapper> and that can't be changed to
std::vector<Containers::Reference> in a source-compatible way. Even that
would be only a temporary change, since the goal is to fully avoid
dependency on STL in those cases.
The final version of these APIs should take
Containers::ArrayView<Containers::Reference> and be implicitly
convertible froom e.g. std::vector<Containers::Reference>. That's
definitely possible, but not in time for 2019.01, so instead of forcing
users to temporary pass a `{vec.begin(), vec.size()}` everywhere instead
of just `vec`, I'm rather keeping these APIs intact.
The change done in 680144f1c5 was not
properly handling these cases:
* Mesh(NoCreateT) and wrap() were not constructing the internal vector,
which blew up when move-assigning another instance.
* ~Mesh() was not destructing the internal vector if the VAO ID was
zero or non-owning wrap() was used.
Strangely enough none of these were causing *any* problems for me on
Linux (even ASan was totally quiet and due to the unfortunate
combination of bugs even when I assigned totally random data to the
storage vector). This however blew up on MSVC, assuming there the
implementation is more checked.
Because it's possible to construct Mesh with no GL context available,
the move construction and destruction needs to avoid accessing Context
unless really necessary (it would be also unclear which type of vector
should be constructed if we have no context).
Extended the tests to handle hopefully all the cases.
This is actually a preparation to make buffer-owning meshes a
possibility (where I would need an union of vectors otherwise),
nevertheless it removes the dependency on a vector.
At the moment just the GL library itself w/o the tests, and without
backwards compatibility aliases. The following types were left in the
root namespace, despite being in the GL/ directory, as they will get
moved back soon:
* Image, CompressedImage and their dimensional typedefs
* ImageView, CompressedImageView and their dimensional typedefs
* PixelStorage
Not PixelFormat etc., that one will stay in the GL namespace and a
completely new PixelFormat enum will be provided in the root namespace.
Minimal updates (just the include guards) so Git is hopefully able to
detect the rename and track the history properly.
Everything except Magnum::GL doesn't compile now.
Currently the user had to ensure that buffers added to mesh were not
moved at all, which was very annoying, basically each one of them had to
be allocated on heap. Now the Mesh stores a weak copy (yes, really) using
Buffer::wrap() with no deletion on destruction, so the original instance
can be freely moved around without any fear of crash.
Thanks to @Squareys for the original idea/request about wrap() functions,
really useful part of the API.
The original goal was to avoid branches when binding the vertex
attributes for drawing, so I stored float, integral and double
attributes in separate std::vector instances and then was going through
each one of them in separate loop. In retrospect that was _not_ a good
idea, because it results in larger Mesh class, two more allocations
resulting in far more pointer chasing and more complicated
constructor/destructor.
Now everything is stored in a single vector. I may optimize it further
by not calling the constructor/destructor on it when VAOs are used.
Actually properly supporting ANGLE_instanced_arrays. Emscripten
currently has the functions without the ANGLE suffix. Only causes linker
warnings when not used, need to fill a bugreport and fix properly.
This function was added to ARB_instanced_arrays spec very late and thus
some implementations don't provide it (one case being AMD drivers on
Linux). If that function is not available, the non-DSA VAO specification
is used instead.
No backward compatibility issues should exist, as the class is in most
(if not all) cases used with unscoped name:
class MyShader: public AbstractShaderProgram {
public:
typedef Attribute<0, Vector3> Position;
// ...
};
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.
* The light didn't catch camera transformation changes, so it was
returning wrong position for most of the time.
* The multiplication was in wrong order, it should be multiplied with
camera matrix from the left.
I need to find an solution for this, because now it is one redundant
matrix*vector multiplication per object per frame again.
This reverts commit 0443bbe286.
Conflicts:
src/Light.cpp
src/Test/LightTest.cpp
Object::setClean() now computes absolute transformation while traversing
through object parents and passes it as parameter to clean(), which is
now virtual a meant to be reimplemented instead of setClean().
Updated and greatly improved unit test.
Saves one matrix*vector multiplication per object per frame. The
position can be now Vector3 like before, because it won't be multiplied
with anything on draw call. Added unit test.
Removed functions at(), set() and add(), everything (and more) can be
now done using operator[]. Accessing matrix elements is now done through
column vectors, e.g.:
Matrix4 a;
a.at(row, col); // before
a[col][row]; // now
Note that because operator[] on Matrix returns column vector (there is
nothing like row vector), the parameter "order" is now swapped.
It was overengineered and unnecessarily complicated. Now the camera is
specified only in Scene::draw(), which eliminates all the needs for
recalculating absolute object transformations on each camera
transformation change. Absolute object transformation is now computed
relative to root object or relative to camera object passed as
parameter. Because of that it is now also possible to draw the scene
using multiple cameras at once.
Vladimír Vondruš