Added base vertex specification, not differentiating between vertex and
index count. The old setVertexRange(), setIndexRange(4) and
setIndexRange(2) are now aliases to new setCount(), setBaseVertex(),
setIndexRange(3) and setIndexRangge(1) functions, are marked as
deprecated and will be removed in future release.
The well-known issue is that gl*DrawElements*BaseVertex() is not
supported in OpenGL ES. It is possible to work around it by
reconfiguring whole VAO, but that seems to be a bit overkill. Currently
the draw() function just asserts that base vertex is not specified for
indexed meshes.
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.
They need to be installed into possibly system-wide location on Windows
and thus we need to avoid name clashes (or at least explicitly show that
e.g. TgaImporterTestLib.dll belongs to Magnum and is not any OMG virus).
Makes it possible to have both debug and release libraries installed. If
both libraries are present when finding the package, proper version is
used based on what configuration is used in depending project.
Until we have proper extension loader implemented (caused
FramebufferGLTest to assert).
On a related note, NVidia drivers 334.21 support *a lot* of ES2
extensions. Wow.
With ARB_multi_bind it is needed to associate the texture with some
target before calling glBindTextures(), otherwise the texture is
treated as invalid.
Would cause random weird issues with texture configuration/upload if
ARB_multi_bind is available and EXT_direct_state_access is not. Probably
not an issue, since EXT_direct_state_access is probably available on all
drivers which support also ARB_multi_bind.