Even though KtxImporter / KtxImageConverter doesn't support these (and
probably never will), the rationale here is to provide a somewhat better
message than "unable to detect file format" when trying to open a *.ktx
file, or when trying to save to a *.ktx by accident, instead of *.ktx2
(I do that quite often). The concrete plugins are able to provide a much
better error message about version 1 not supported.
Hey, do you also remember the times where people were excited to upgrade
from Clang 3.6 to 3.7, GCC 4.7 to 4.8 or Firefox 1.1 to Firefox 1.5? Not
Clang 12 to 14, GCC 10 to 13 or Chrome 102 to 126.
Eheh. But given that nobody complained for so long, it means nobody uses
those ancient versions anymore. Or nobody uses DebugTools, that's more
like it.
Counterpart to d07b6a2bb4, which did this
for sceneconverter (I should really do changes in both at the same
time). Additionally, it's not saying "uncompressed" for images anymore,
since it's more confusing than just saying nothing, especially when
block-compressed formats are involved.
Which allows to get rid of a now-unneeded ArrayView include in the
header. Also, now that we're returning a StringView, it's useful to
have the view always null-terminated. In SDL2 and Emscripten it was
already like that, GLFW needed a minor change.
Required for Buffer::data()/subData() used by GLES3 tests. Otherwise
all the tests would have to check the Emscripten version and skip if
it's too old.
Since glGetBufferSubData() is only exposed on Emscripten 2.0.17 and up,
both functions are not available on older versions. This is to avoid any
accidental foot guns since it explodes at compile time. The webgl2 CI
will be upgraded to 2.0.17 in a later commit.
As was done with GL::Buffer::data() back in 2017 -- the size parameter
is way too error prone this way (is it bytes? or multiples of
sizeof(T)?), plus arrayCast() contains a few extra checks that would
have to be replicated here to have the same level of robustness, etc.,
etc.
For animations, scenes, meshes and images, where the memory impact is
measurable. For others such as materials or cameras the memory impact is
either unclear (depending on the final representation) or so small it's
not important.
Because yes of course dealing with a JSON just isn't possible
without having to make decisions between insufficiently imprecise
integers and unnecessarly overprecise doubles.