It was rather discouraging to start "Basic usage" with a boring-ass long
snippet. On the other hand showing just compile() first would lead
people to think it's all some opaque magic, so trying to balance that a
bit.
Also why the hell was the compile() snippet showing the horrendous GL
way of specifying attribute formats? This is not great either but at
least not redundant.
There's a lot to change with the current version -- the bloaty tuple,
the useless min/max, and compressing all the way down to 8 bits is not
desirable anymore either. The new function allows to specify a minimal
type to compress to and works also on 8- and 16-byte types, which makes
it possible to also inflate a smaller type into a larger one.
The old function is now deprecated.
103% of use cases use the returned value directly without checking, so
we might as well do the check ourselves. Added new function hasCurrent()
and added deprecated backward-compatibility conversion and -> operators.
Wow, that creeped to a lot of places.
Last dinosaur from the pointer age.
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;
// ...
};
Only one value from these two was used in the end, wasting precious
bytes. Also these two values were used to differentiate between indexed
and non-indexed mesh (instead of relying on actual index buffer being
bound), which was very confusing. This approach looks more clean. The
MeshView class is not yet updated, as the change would expose some
features that aren't possible in current implementation (base vertex
specification).
Merged Mesh::setVertexCount() and Mesh::setIndexCount() into one
Mesh::setCount(), the two original functions are now guarded aliases to
the new one, are marked as deprecated and will be removed in future
release, similarly for the getters.
In particular, if the mesh is indexed, setVertexCount() does nothing and
vertexCount() returns 0. The setIndexCount() and indexCount() do and
return the same regardless of whether the mesh is indexed or not.
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.
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).
Because we can't forward-declare class members we would need to include
whole Mesh (along with all OpenGL headers and other stuff) just to use
Primitive enum. The old Mesh::Primitive is now alias to new one, is
marked as deprecated and will be removed in future release.
Buffer usage is used as parameter in many functions, e.g. in
*Framebuffer::read() and *Texture::image(), but they are rather seldom
used and including whole Buffer.h file just for one enum is just
overkill. The old Buffer::Usage is now alias to BufferUsage, it is
marked as deprecated and will be removed in future release.
It is possible to do everything with Mesh::addInterleavedVertexBuffer().
Moreover Mesh::addVertexBuffer() was dependent on vertex count, which
was counterintuitive and not always what the user wants. Also in many
times I mistakenly used Mesh::addVertexBuffer() instead of
Mesh::addInterleavedVertexBuffer() and then spent endless hours trying
to figure out what is wrong. This is now over. Thanks, brain!
On systems without VAOs and without gl_VertexID the buffer needs to be
bound before every draw call. This way the buffer reference would become
dangling one, because the buffer is moved out somewhere else. Now
creating it on heap and returning pointer instead.
This multiple code path implementation is really starting to pay out,
yay!
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.
* 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š