SDL 2.x recently accepted patches to enable OpenGL ES 2 support via Google's ANGLE library. The thought is to try to eventually merge SDL/WinRT's OpenGL code with SDL-official's.
To enable this, set the environment variable SDL_MOUSE_RELATIVE_MODE_WARP to "1"
When mouse relative mode is disabled, put the cursor back where the application expects it to be, instead of where it was when relative mode was enabled.
Based on the original port to Wayland by: Joel Teichroeb, Benjamin Franzke, Scott Moreau, et al.
Additional changes in this commit, done by me:
* Wayland uses the common EGL framework
* EGL can now create a desktop OpenGL context
* testgl2 loads GL functions dynamically, no need to link to libGL anymore
* Assorted fixes to the Wayland backend
Tested on the Weston Compositor (v1.0.5) that ships with Ubuntu 13.10,
running Weston under X. Tests ran: testrendercopyex (all backends), testgl2, testgles2,testintersections
SDL_GameControllerAddMappingsFromFile is now a convenience macro.
controllermap can now skip bindings by pressing space or clicking/touching the
screen.
Sylvain
Here's some code to add arc cosine, and arc sin functions to SDL_stdlib.c
There are plainly written using SDL_atan.
--HG--
extra : rebase_source : 3c92b648c11366af38fac18df85eb7d5da6fe292
Haiku uses most of the standard pthread API, with a few #ifdefs where we
still need to fallback onto the old BeOS APIs.
BeOS, however, does not support pthreads (or maybe doesn't support it well),
so I'm unplugging support for the platform with this changeset. Be Inc went
out of business in 2001.
--HG--
extra : rebase_source : c7227f47193228c898cc997ebcf9bb00ead329e6
This bumps the build SDK level to 12 (up from 10). Runtime requirements remain
the same (at API level < 12 joystick support is disabled).
Also enables building SDL for armv7 and x86.
A port of the ANGLE library (OpenGL ES 2.0 for Direct3D) to WinRT, via https://github.com/stammen/angleproject, is used as a base.
To enable, clone 'angleproject' into the directory one above where SDL/WinRT is, open the file SDL/include/SDL_config_winrt.h, and uncomment the #defines that begin with 'SDL_VIDEO_OPENGL'. From there, apps can create an OpenGL capable SDL_Window via the flag, SDL_WINDOW_OPENGL, and an OpenGL ES 2 context via SDL_GL_CreateContext. The Direct3D 11.1 renderer cannot be used alongside SDL_WINDOW_OPENGL. Only Windows 8/8.1 is supported for now. Shaders may need to be precompiled, in some (all?) cases.
To enable the Debug Layer, set the hint, SDL_HINT_RENDER_DIRECT3D11_DEBUG to '1'.
The Debug Layer will be turned off by default, both in Release and Debug builds (of SDL).
Jānis Rūcis
Reopening as compilation with ANSI C throws lots of unnecessary warnings, both using MinGW and using Linux GCC. (BTW, what happened? MinGW is broken to all hell. sdl2-config does not even link SDLMain anymore?)
I think this may have been lost somewhere, so again: GCC supports inlining via __inline__ in all known versions of GCC, regardless of the C standard in use. Please don't assume that __STRICT_ANSI__ implies no inlining support.
Andreas Ertelt
The problem in question is caused by changeset 7771 (http://hg.libsdl.org/SDL/rev/4434498bf4b9 / https://bugzilla.libsdl.org/show_bug.cgi?id=2121)
The redefinition of __inline__ (introduced by the addition of begin_code.h:128's "|| __STRICT_ANSI__") results in mingw's gcc throwing multiple
warning: always_inline function might not be inlinable [-Wattributes]
as well as a whole bunch of redefinitions of mingw internals which break linking of projects including the SDL2 headers.
norfanin
Fixes the version check for some functions that are only present with the MSVC 2013 CRT libraries.
I did my testing wrong and failed to see that 2012 doesn't have these functions. Microsoft implemented them in their upcoming 2013 version, though. The attached patch changes it to the check for the next version.
I also removed the HAVE_ITOA because that would require linking with oldnames.lib and it's easier to just let the SDL implementation take over.
This is part of an overall effort to use the name, "WinRT", rather than "WindowsRT" (or "Windows RT"), as the shorthand name often seems to mean something different than the longhand name. (WinRT is an API, Windows RT is a product name)
