It compiles on GLES2 as well, but there it hits the massive PITA of
being unable to render to LUMINANXCE formats and GL_RED formats not
really being available everywhere.
I don't have the patience to fix that, and almost nobody needs to use
ES2 platforms nowadays, so this isn't really a priority.
So one can directly read it back on GLES without having to wrap the
texture in a framebuffer again.
This change also puts the framebuffer completeness check *before* the
clear() and bind() which makes it no longer emit a GL error. The error
is still silent though, which isn't nice. Gotta fix that eventually as
well.
Mainly important for Shader::addSource() to prevent it from creating a
needless copy, but doesn't hurt to do the same also for
uniformLocation(), bindAttributeLocation() etc. -- it'll avoid a runtime
strlen() in that case at least.
Same as in the previous commit, most cases are inputs so a StringStl.h
compatibility include will do, the only breaking change is
GL::Shader::sources() which now returns a StringIterable instead of a
std::vector<std::string> (ew).
Awesome about this whole thing is that The Shader API now allows
creating a shader from sources coming either from string view literals
or Utility::Resource completely without having to allocate any strings
internally, because all those can be just non-owning references wrapped
with String::nullTerminatedGlobalView(). The only parts which aren't
references are the #line markers, but (especially on 64bit) those can
easily fit into the 22-byte (or 10-byte on 32bit) SSO storage.
Also, various Shader constructors and assignment operators had to be
deinlined in order to avoid having to include the String header, which
would be needed for Array destruction during a move.
Co-authored-by: Hugo Amiard <hugo.amiard@wonderlandengine.com>
Funny/sad that this possibility took me so long to realize. Until now it
was "you can have command-line utilities or static plugins but never
both", and only with CMake 3.13+ it was possible to link static plugins
to these executables from outside. Now it's a builtin and supported
option.
For some reason, it was adding also the magnum / magnum-d directory,
which isn't really useful, especially in cases where the directory is
not at all or it's desired to pick a debug plugin from a release
executable and vice versa.
Also the distancefieldconverter was still attempting to join with an
absolute path -- somehow 7fb63a9434 missed
this one.
I really need to write regression tests for all this, sigh.
These two options were mutually exclusive, and both were doing the same
thing -- switching to EGL on desktop GL, or switching away from EGL on
GLES. That made all logic vastly more complicated than it should be, and
unfortunately it took me half a decade to realize that. The new logic is
significantly simpler everywhere.
As usual, the old options are still recognized by CMake on a deprecated
build (with a warning), and are still exposed both as CMake variables
and a preprocessor define. But the logic for them was quite complicated,
so I don't guarantee all cases are covered.
I also tried to clean up the dependent CMake options to allow building
GLX and WGL apps on GLES independently of whether EGL is used, but it's
quite a mess due to the limitations of CMake < 3.22. Build directories
that have the options switched randomly over a long time might start
misbehaving, but the initial build should work well.
The whole class was a bad idea, why create something that's 99% similar
to another application and has just one platform-specific workaround? Of
course it resulted in this code being completely untested and not even
built anywhere, because it served a tiny insignificant use case.
To avoid losing all the code, I did my best in attempting to merge this
into the WindowlessEglApplication. But since, again, EGL isn't
really used on any Windows platform, I can't even say it builds
properly. Maybe not even the original code built.
Consistently with checkLink(), this avoids having to explicitly include
both Iterable and Reference in shader code. Alsod allowing people to
have direct arrays of shaders, runtime-sized lists of shaders etc.
A compat include is provided on a deprecated build to avoid breaking
existing code.
There's no reason for those to exist anymore -- origiinally they were
added in a hopeful attempt to make use of parallel shader compilation,
but in practice that meant compiling at most two or three shaders at
once and still stalling until that was done, so not that great at all.
The new APIs provide much better opportunities for parallelism.
Fun fact:
CORRADE_INTERNAL_ASSERT_OUTPUT(vert.compile() && frag.compile());
is actually one character shorter than
CORRADE_INTERNAL_ASSERT_OUTPUT(GL::Shader::compile({vert, frag}));
so not even typing convenience would be a reason to keep these.
Together with the parent commit, it's now possible to do THE
UNTHINKABLE:
Containers::Array<Trade::ImageData2D> inputImages = ...;
auto out = TextureTools::atlasArrayPowerOfTwo({2048, 2048},
stridedArrayView(inputImages).slice(&Trade::ImageData2D::size));
An actual use case, in fact. Because why not.
Similar to the change done in Corrade, see the commit for details:
878624ac36
Wow, this is probably the most backwards-compatibility code I've ever
written. Can't wait until I can drop all that.
The boring dry usage info grew significantly, and listing it as the
first thing on the page would scare people off. Put the examples first
instead, and for the imageconverter and sceneconverter add --info
listing examples, as that's what is eye-catchy.
It limits the support for CMake 3.12+, but it's much less verbose and I
don't expect people to use ancient CMake versions with IDEs like Xcode
or VS anyway, so this should be fine.
Probably a leftover from when these dependencies were handled in a
much shittier way? For as long as I remember, enabling WITH_GL_INFO
always enabled WITH_GL and WITH_WINDOWLESSWHATEVERAPPLICATION
implicitly.
I went through renaming this on many places quite some time ago, but
this one slipped through. Now that UBOs will be a thing, rename to
EXPLICIT_BINDING instead of EXPLICIT_UNIFORM_BINDING.
First and foremost I need to expand the interface to support 3D
image conversion. But the interface was not great to begin with, so this
takes the opportunity of an API break and does several things:
* The `export*()` names were rather strange and I don't even remember
why I chose that name (maybe because at first I wanted to have an
"exporter" API as a counterpart to importers?)
* In addition, there was no way to convert a compressed image to a
compressed image (or to an uncompressed image) and adding the two
missing variants would be a lot of combinations. So instead the new
convert() returns an ImageData, which can be both, and thus also
allows the converters to produce compressed or uncompressed output
based on some runtime setting, without having to implement two
(four?) separate functions for that and requiring users to know
beforehand what type of an image will be created.
* The ImageConverterFeature enum was named in a really strange way as
well, with ConvertCompressedImage meaning "convert to a compressed
image" while "ConvertCompressedData" instead meant "convert a
compressed image to a data". Utter chaos. It also all implied 2D and
on the other hand had a redundant `Image` in the name, so I went and
remade the whole thing. As mentioned above, two of the enums now mean
the same thing, and are both replaced with Convert2D.
* Finally, similarly as changes elsewhere, I took this opportunity to
get rid of std::string in the convertToFile() APIs.
Disabling engine startup log or modifying enabled extensions /
workarounds from the application side was one of the common pain
points and this should *finally* solve the problem. This Configuration
is now inherited by the usual Platform::*Application::GLConfiguration /
Platform::Windowless*Application::Configuration classes people are used
to, so for the end user it's just as if these classes got a bunch new
options.
Having this, I also extended the ContextGLTest to verify that the
Configuration and command-line options do what's expected because that
hadn't automated tests until now. The test is mostly a copy of what I
did for Vulkan already, nothing special. Additionally all
Platform*ApplicationTest executables gained a new --quiet option to
verify that the GL::Context::Configuration subset gets correctly passed
from the Application code, because that's something we can't really
verify in an automated way.
Should make new things more discoverable, avoid confusion when a
documented API isn't there and reduce the need for maintaining multiple
separate versions of the docs.
Vladimír Vondruš