Mark Callow
The attached patch does the following for the X11 and Windows platforms, the only ones where SDL attempts to use context_create_es_profile:
- Adds SDL_HINT_OPENGL_ES_DRIVER by which the application can
say to use the OpenGL ES driver & EGL rather than the Open GL
driver. (For bug #2570)
- Adds code to {WIN,X11}_GL_InitExtensions to determine the maximum
OpenGL ES version supported by the OpenGL driver (for bug #3145)
- Modifies the test that determines whether to use the OpenGL
driver or the real OpenGL ES driver to take into account the
hint, the requested and supported ES version and whether ES 1.X
is being requested. (For bug #2570 & bug #3145)
- Enables the testgles2 test for __WINDOWS__ and __LINUX__ and adds
the test to the VisualC projects.
With the fix in place I have run testdraw2, testgl and testgles2 without any issues and have run my own apps that use OpenGL, OpenGL ES 3 and OpenGL ES 1.1.
Fixed a case where partial trigger pull could be bound to another button
There is a fundamental problem not resolved by this commit:
Some controllers have axes (triggers, pedals, etc.) that don't start at zero, but we're guaranteed that if we get a value that it's correct. For these controllers, the current code works, where we take the first value we get and use that as the zero point and generate axis motion starting from that point on.
Other controllers have digital axes (D-pad) that assume a zero starting point, and the first value we get is the min or max axis value when the D-pad is moved. For these controllers, the current code thinks that the zero point is the axis value after the D-pad motion and this doesn't work.
My hypothesis is that the first class of devices is more common and that we should solve for that, and add an exception to SDL_JoystickAxesCenteredAtZero() as needed for the second class of devices.
Ciro Santilli
GCC 6, Ubuntu 16.10, cd test; ./configure; make
/bin/sh config.status Makefile
config.status: creating Makefile
gcc -o loopwave loopwave.c -g -O2 -D_REENTRANT -I/usr/include/SDL2 -DHAVE_OPENGLES2 -DHAVE_OPENGL -DHAVE_SDL_TTF -g -lSDL2_test -lSDL2
gcc -o testatomic testatomic.c -g -O2 -D_REENTRANT -I/usr/include/SDL2 -DHAVE_OPENGLES2 -DHAVE_OPENGL -DHAVE_SDL_TTF -g -lSDL2_test -lSDL2
In file included from /usr/include/SDL2/SDL_main.h:25:0,
from /usr/include/SDL2/SDL.h:32,
from testatomic.c:14:
/usr/include/SDL2/SDL_stdinc.h:261:20: error: variably modified ?SDL_dummy_size? at file scope
typedef int SDL_dummy_ ## name[(x) * 2 - 1]
^
testatomic.c:106:1: note: in expansion of macro ?SDL_COMPILE_TIME_ASSERT?
SDL_COMPILE_TIME_ASSERT(size, CountTo>0); /* check for rollover */
^~~~~~~~~~~~~~~~~~~~~~~
Makefile:114: recipe for target 'testatomic' failed
make: *** [testatomic] Error 1
If I remove the line SDL_COMPILE_TIME_ASSERT(size, CountTo>0); /* check for rollover */ it works, lazy to figure out the best way to do this.
Mark Pizzolato
On Windows with Visual Studio, when building SDL as a static library using the x86 (32bit) mode, several intrinsic operations are implemented in code in SDL_stdlib.c.
One of these, _allshr() is not properly implemented and fails for some input. As a result, some operations on 64bit data elements (long long) don't always work.
I classified this bug as a blocker since things absolutely don't work when the affected code is invoked. The affected code is only invoked when SDL is compiled in x86 mode on Visual Studio when building a SDL as a static library. This build environment isn't common, and hence the bug hasn't been noticed previously.
I reopened#2537 and mentioned this problem and provided a fix. That fix is provided again here along with test code which could be added to some of the SDL test code. This test code verifies that the x86 intrinsic routines produce the same results as the native x64 instructions which these routines emulate under the Microsoft compiler. The point of the tests is to make sure that Visual Studio x86 code produces the same results as Visual Studio x64 code. Some of the arguments (or boundary conditions) may produce different results on other compiler environments, so the tests really shouldn't be run on all compilers. The test driver only actually exercised code when the compiler defines _MSC_VER, so the driver can generically be invoked without issue.
