The LDR/HDR detection from 8da46ef9dc
unfortunately made Emscripten apps crash on startup if --closure was
enabled in linker flags, unless the page was run with
?magnum-disable-extensions=GL_WEBGL_compressed_texture_astc
added to the URL. The fix basically forces me to make the code not rely
on undocumented Emscripten internals anymore, which is nice, however I
now have to duplicate it because of compiler silliness and the
comment:code ratio is not getting any better either.
When writing high-level documentation for those I realized that it's
easier to just add the r-value variants than trying to explain why one
has to be careful to not pass r-values there.
Matching what's in MeshTools, because I need them to implement other
algorithms that match what's in MeshTools. In other words no idea why I
didn't make these along with copy() already.
Back in 2020 when I wrote this I didn't really expect the MeshData to be
directly used for much more than putting them on a GPU, mostly because
that used to be the primary use case with the old MeshData2D /
MeshData3D. So the documentation was focusing mainly on populating a GPU
mesh, and any docs for CPU-side access were added rather hastily.
As now the asset processing use case is much larger, the original docs no
longer made sense. Let's hope this is better.
Not too great yet, but at least the most common operations have an
example snippet that shows real use, instead of jumping off a cliff
right into the most detailed description.
New since 7ca7e5a62b, and no, I'm not going
to switch from enums to some static constexpr int. Unless this
changed in recent standards, it still means one can take an address of
it. Which shouldn't be possible for a constant as that could
unnecessarily pessimize its perf.
The wording was so insufficient that it made people think it's a fatal
error, and subsequently made them suspicious because it seemed like the
fatal error is ignored.
The more I looked at it, the more useless it felt. Also, since it's so
broken, I'm also completely removing it from the test because there's no
point in even testing it.
I attempted to make it private only to discover it was used by Magnum
Player to make the workflow with opt-in tweakable constants more
efficient. So let's document that.
Unlike the Key enum, which shows what a user would perceive as given key
in a particular layout, the scancode is a layout-independent identifier
for e.g. WASD movement in games.
Unfortunately the API availability is wildly different among the
toolkits -- SDL's is the most complete, GLFW is second, and then there's
Emscripten / HTML5 which provides just string identifiers. I tried to
add these for X11 as well, but quick googling led to a SO question where
it was left unanswered. Not worth my time.
There's the obvious advantage of them now being shorter to type, as one
no longer needs to prefix them with KeyEvent::. But the main reason I
did this was to allow various direct keyboard state queries to be
implemented, such as isKeyPressed(). With them being hidden in the event
class the only way would be to put the query directly there as well,
which isn't nice and is also not very discoverable.
A similar case was with mouse buttons, but that was already fixed with
the PointerEvent rework that happened in earlier commits. There the
additional complication was that MouseEvent::Button and
MouseMoveEvent::Button were incompatible enums. Application::Pointer
fixes that now as well.
Partially reverts 589b3e594d -- I got it
backwards. It actually makes more sense from a user perspective to have
layout-dependent key identifiers, because for for e.g. using Ctrl-Z as
the "Undo" shortcut it's the most important what key the user perceives
as Z, not where that key is placed on some (again, from the user PoV
basically arbitrary) layout. For game-y usage, e.g. the WASD movement,
scancodes matter (and appropriate getters will get added), but for 90%
of actual user interfaces the local layout is how the keys should be
defined. This is consistent with e.g. how Qt does it (and it has
scancodes as an additional, completely untyped getter), another data
point that's in favor of keycodes is that SDL's SDLK_* defines are far
shorter than the corresponding SDL_SCANCODE_* scancodes.
Ubuntu 18.04 has 3.2 so this should be safe. Need to use
glfwGetKeyName() to undo keyboard layout weirdness, would be nasty to
have to make a fallback for older versions.
AbstractXApplication and GlfwApplication don't implement touch events,
but for painless portability now expose also source(), isPrimary() and
id() like the touch-aware app implementations. The Screen abstraction
now exposes also the PointerEventSource enum.
As usual, the most trash fire platform of them all. Ugh. I chose to
ignore certain aspects and suggestions and made it behave more like
Emscripten and SDL2, because that makes more sense to me.
Co-authored-by: nodoteve <nodoteve@yandex.com>
The impossible-to-reliably-disable behavior with compatibility mouse
events is quite a headache. I wish Emscripten implemented pointer events
already so I could ditch this mess -- especially the array of 32 touches
where all of them but one will be unchanged is stupid.
For the internals unfortunately, EmscriptenMouseEvent and
EmscriptenTouchEvent have no common base, so I had to give up on the
current way of querying the event struct directly from event getters, as
that'd be too nasty with the branching and casts. Instead the relevant
fields are put directly into the events themselves.
HTML5 also doesn't provide any relative pointer position. For the mouse
it was rather straightforward, but for the up-to-32 touches I have to
maintain an array of per-finger positions and match them by ID.
Hopefully the linear lookup is fine. I'll probably use the same approach
for the AndroidApplication.
This makes 2.0.6 as the oldest supported because in older versions it's
not possible to disable touch to mouse event translation, and it'd be
too annoying to have it special-cased there. The version bump should be
fine as Ubuntu 18.04 has 2.0.8.
Vladimír Vondruš