Because the library still links to the old crappy opengl32.dll, we need
to load all symbols above OpenGL 1.1, not just those that are above
OpenGL ES 2.0/3.0.
The SDL2 variant works better than expected, however the GLFW variant
underdelivers -- no key names for modifier keys, the accent keys are not
UTF-8... I don't care ATM, will solve it once someone actually
complains.
Fixes an issue when creating the context more than once in a single
application. Also changed the API calls to be explicitly "W" and added
proper error reporting to this part of code.
Note that the `Plus` and `Percent` keys are not available without using
the SHIFT key on the typical US English keyboard layout, and as such do
not have dedicated `#define`'s in `GLFW.h`.
Detected in WindowlessWglApplication, added it to both Sdl2Application
and WindowlessWglApplication. Renamed the workaround to reflect that it
is for all three major vendors.
Enabled by default, makes the current Magnum context a thread-local
variable instead of a global one, so it's possible to have multiple
thread-local contexts. Might have some performance implications, that's
why it's possible to disable it (but enabled by default is the safer
option).
GCC 4.7 and Apple platforms don't support thread_local, but __thread
does the job too (though on iOS not until Xcode 7.3). Also had to move
it to file-local because MSVC doesn't like having thread local variables
as part of DLL interface. (And there is *of course* no way to disable
exporting one particular member. F' that.)
Each Windowless*Application has now a companion Windowless*Context that
manages just the GL context creation and nothing else, with the ability
to just create the context and not make it current, so it doesn't affect
current thread state and can be moved to another thread and make current
there.
Other things that were done:
* Using `NoCreateT` instead of `nullptr` for creating the application
without creating GL context.
* Properly handling failed creation of Magnum context instance -- if it
errors out, also the GL context is destroyed to make it possible to
create the context with a different configuration.
* Reworked AMD and NVidia binary driver workaround, where core context
created with specific version doesn't automatically choose the newest
available (creating compatibility context on the other hand causes
the version to get stuck on 2.1 on Mesa and OSX).
* Added the above workaround also for WindowlessWglApplication to avoid
driver issues in the future.
* Reworked WindowlessWglApplication to not be so crazily entangled. It
was a misunderstanding on my side about how WINAPI works. Much
simpler now (and I hope still working :D).
The original implementation tried to mimic the behavior of GLUT, which
treats mouse wheel as a button. SDL2, GLFW and NaCl all treat scroll
event separately, so it was quite nastily hacked in, with horizontal
scrolling ignored and scrolling offset treated as cursor position.
Moreover, wheel up/down buttons were confused with extra mouse buttons
in SDL2.
Now there is a dedicated MouseScrollEvent, which has just the offset and
modifiers, no cursor position. The original way with WheelUp/WheelDown
buttons in mouse press event is still preserved, though it is marked as
deprecated and will be removed in future release. Sdl2Application had
WheelUp/WheelDown buttons also for mouse move event, which was
completely useless (try moving a mouse while the wheel is rotating, ha),
so it's removed.
Scroll event offset is now also consistently Vector2 across all toolkits
-- it was integer in SDL2, float in NaCl and double in GLFW.
The X1 and X2 buttons in Sdl2Application are not confused with wheel
up/down anymore and are a new Mouse*Event::Button::X1 and
Mouse*Event::Button::X2 enums -- on my mouse they are actually wheel
left and wheel right (though wheel left and wheel right is not treated
as horizontal scrolling, weird).
The docs weren't correct in 90% cases -- mainly in case of
createContext() function, docs of which were extended to clearly specify
what's done inside.
Otherwise the ANativeActivity_onCreate() won't get exported and the
app will fail to start. Of course they just don't care and produce
crappy code that apparently nobody uses in production environment.
Vladimír Vondruš