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.
All the new pointer events have float positions, this one was the odd one
out. And I didn't like the name anymore, so I took that as an opportunity
to change the position() data type without introducing a breaking change
for everyone.
Another considered change was adding Z offset to it, since HTML5 APIs
have that. However, all my googling led to just a single SO question from
2015, where someone said it's for trackballs that can navigate in 3D
space. I'm not sure if *scroll* is actually the best way to report those,
and since SDL3 didn't bother adding that and neither Android nor WINAPI
have anything like that, I'm not bothering either.
Unlike the previous commits, this is done for all apps at once, because
it's a comparatively simpler change. The only odd one out is
AbstractXApplication, where I introduced MouseScrollEvent just a few
commits back, so I simply renamed it without leaving a deprecated copy.
Then, ScreenedApplication needed some extra logic to handle the case of
apps not implementing any scroll event at all.
Because this overrides the base pointer*Event() implementations, it
additionally has to call into the parent implementation in order to fall
back to the deprecated mouse event if the new pointer event isn't
handled.
For the most part is the same as in Sdl2Application, except that here
GLFW already returned floating-point coordinates, which this finally
makes use of.
In short this means the users no longer need to care about FindSDL2 etc.,
it'll just get done automatically. They don't need to drag along
FindMagnum / FindCorrade anymore either, but having them gives a much
more reasonable error message if the library cannot be located at all, so
I still recommend having them.
This is just documentation-facing, instead of documenting an overload as
having a default-constructed argument simply show just one constructor
with a default value.
Also simplify the wording. They either create an OpenGL context or not
(or not implicitly).
This makes them consistent with window and framebuffer size queries,
that are also not cached but queried every time. It fixes a case where a
global UI scaling change in the OS triggered a viewport event but the
event didn't actually have the DPI scaling value updated.
It doesn't however handle actual explicit DPI change events yet, that's
another nightmare altogether.
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.
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.
The so-far-perfect impression of GLFW being a heaven to integrate just
got a bunch of tiny cracks. Good thing it's being fixed for the next
version, although I'd personally disable the docs as well.
Except CGL, iOS, AndroidApplication and AbstractXApplication which are
either too crappy or don't have the needed scaffolding for specifying
context flags yet.
With this flag set (which is done implicitly for all windowless apps
and, conversely, not done for all windowed apps), the default
framebuffer state isn't touched in any way, which should avoid potential
race conditions with default framebuffer on another thread.
This removes one unnecessary allocation from each application startup.
In some cases of the windowless apps the Platform::GLContext could be
put directly into the class, in other cases it had to be wrapped in an
Optional because we need delayed construction and/or earlier
destruction.
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.
There's four more new cursors and the _cursors array was too small.
At first I got confused because I thought the assertion on top is done
against the CursorMap, which didn't contain the Hidden cursors. So to
avoid confusing myself again in the future, I moved the assert after the
special cases and made both arrays the same size since it doesn't make
sense to have always-empty fields in there.
Similar change is done in Sdl2Application, and an assert is added to
avoid a nondescript crash if the window is not created yet.
Instead of first entering the main loop, processing events etc. This
also makes it finally possible to exit the application cleanly, with all
non-global destructors executed as well.
Vladimír Vondruš