This was due to the internal counter in the object being just 2 bytes,
which was made in order to optimize the Object class size. In practice
however, not counting the vtables, the class has SEVEN pointers and then
a transformation part that's in most cases multiple of 8. Which means
that on 64 bit platforms there was always 5 bytes of padding next to
this 2-byte counter and 1-byte flags, thus no reason to have it 2-byte
anyway.
On 32-bit platforms this *might* cause the Object to get bigger, yes,
but as it's heap-allocated it's more likely that it's put on a
16-byte-aligned address and thus occupying a multiple of 16 bytes
anyway. In any case, this won't really hurt, because the SceneGraph
situation is bad enough already due to all the pointer chasings and
overhead from loose allocations.
It now delegates to Assimp for ASCII files, along with StlImporter that
does the same but was already marked as having minor caveats. Better
than nothing, and it's not my problem that Assimp leaks and crashes like
mad on broken files.
Took me quite a while to realize what was going on, but in retrospect
it's obvious -- the rasterizer just *rounds* the sub-pixel-positioned
glyph quads to nearest pixels. Which then can cause the neighboring
glyph data to leak to it (because the texture is then sampled not
directly on the edge pixel, but slightly outside of it), or it can also
cut away the edge, when it gets rounded in the other direction.
This was a problem with the original -- laughably inefficient -- atlas
packer as well, but because that packer had excessive padding around
everything, only the second edge-cutting artifact manifested, and that
one is rather subtle unless you know what to look for.
This means the packing is now slightly worse than before and sizes that
previously worked may no longer fit anymore. But since the new atlas
packer is relatively new (well, from September, time sure flies
different here), and the improvement compared to the original packer is
still quite massive, I don't think this is a problem.
And for Sdl2Application print both the keycode and keysym, as the
current way with a keycode seems different from what both GLFW and HTML5
does. But the SDL2 scancode also doesn't feel right because compared to
GLFW and HTML5 it swaps Y and Z on my keyboard. SIGH.
This all looked obviously correct so I never questioned it, but the spec
itself has the order mixed up for an unexplainable reason so it doesn't
match between MouseEvent and MouseMoveEvent.
In the Emscripten build, accepting events in EmscriptenApplication
prevents them from propagating further to the page, such as F1 that
would open a browser help page. That's not the case with SDL as SDL has
no concept of "accepting an event", so just document that in the test
code.
This is what both SDL and GLFW do, so it makes sense to be consistent.
Without it it's also impossible to handle keyboard shortcuts such as
Ctrl-C when editing text, which is rather silly.
Insufficient testing, sorry. This got broken after MAGNUM_TARGET_GLES3
deprecation in 87c7eea1e2, but the stupid
variable name was there before already, and it just worked for some
reason, but when the condition got flipped, setting *minor* version to 2
didn't do the right thing anymore. And of course, typical Emscripten,
it didn't complain at all in either case.
Took me an embarrassingly long time to spot what was wrong.
Vertex buffer offsets are like this already (and I already had a use
case with a mesh of size larger than 4 GB), with index buffers so far I
thought it's not needed, but it makes sense to do that as well -- there
can be a giant index buffer for many meshes and even though the total
drawn element count won't reach 1 billion (or 1 million, even), it can
still go over. Since it was internally already stored as a pointer-sized
value and some (but not all) code was treating it as pointer-sized, this
change just makes sense.
This also fixes "warning C4244: 'return': conversion from 'const
GLintptr' to 'Magnum::Int', possible loss of data" on MSVC, although in
a very different way.
Such as being able to print the contents as hexadecimal. Doing this just
for Vector and not any other math types, as those are all floating point
where it doesn't make sense. And for Nanoseconds, which are integers,
hexadecimal printing makes no sense either.
Got a suggestion that lerp() could be optimized to be one arithmetic
operation less. While valid in certain cases, it would break in case the
endpoints have wildly different magnitudes. Unfortunately that was only
my personal knowledge, not backed by regression tests. Now it is.
The change in 87c7eea1e2 caused a breakage
with old FindMagnum modules, which use if(MAGNUM_TARGET_GLES3) to decide
if they should link to libGLES.
This is now still only defined for deprecated builds, so non-deprecated
builds with old FindMagnum will fail.
Originally (2012? 2013?) I expected that there would eventually be
OpenGL ES 4.0, thus it made sense to differentiate between ES2, ES3 and
something else ES yet unknown. But as ES4 was increasingly unlikely to
happen, the internal code treated MAGNUM_TARGET_GLES3 as a simple
inverse of MAGNUM_TARGET_GLES2, and only in a very few places,
only adding confusion.
Thus it's now deprecated and defined as a simple inverse of
MAGNUM_TARGET_GLES2 on MAGNUM_TARGET_GLES builds, and none of the
internal code uses it anymore.
Vladimír Vondruš