Because Debug outputs chars as numbers, it displayed the following:
compilation of fragment shader321 succeeded ...
compilation of vertex shader322 succeeded ...
instead of
compilation of fragment shader 1 succeeded ...
compilation of vertex shader 2 succeeded ...
Now I will forever know that ASCII code of space is 32.
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 :)
I didn't yet have time to add more complete support for ES 3.1, but the
engine should at least work on it. If the driver reports ES 3.0 or 3.1
it is taken as valid value in both ES2 and ES3 builds (i.e. the engine
can work in ES2 mode also on ES3 driver).
The point of this change is to allow greater flexibility and reduce
confusion.
When instanced meshes are implemented, MeshTools::interleave() can be
used for creating interleaved buffers with per-instance data and then
the call to Mesh::setCount() will be harmful and/or confusing, becuase
the user would in fact want to call Mesh::setInstanceCount() instead.
Similarly, MeshTools::compressIndices() can be used to create index
buffer for more than one mesh.
GL 4.4 has ARB_buffer_storage, which (in relatively distant future) will
mean that the current way of Buffer::setData() will be deprecated in
favor of Buffer::setStorage(), similarly as Texture::setStorage()
replaced Texture::setImage(). Thus any function which calls
Buffer::setData() internally is not future-proof.
The old MeshTools::compressIndices() and MeshTools::interleave()
overloads are marked as deprecated and will be removed in future
release.