Added the functions SDL_JoystickFromPlayerIndex(), SDL_JoystickSetPlayerIndex(), SDL_GameControllerFromPlayerIndex(), and SDL_GameControllerSetPlayerIndex()
The Offscreen video driver is intended to be used for headless rendering
as well as allows for multiple GPUs to be used for headless rendering
Currently only supports EGL (OpenGL / ES) or Framebuffers
Adds a hint to specifiy which EGL device to use: SDL_HINT_EGL_DEVICE
Adds testoffscreen.c which can be used to test the backend out
Disabled by default for now
This fills in the CFBundleVersion and CFBundleShortVersionString fields,
if and when SDL's test-apps are built via CMake. This is needed to install
the .app bundles on iOS 13+ (using 'xcrun simctl install booted path/to/testsuchandsuch.app')
When using a recent version of CMake (3.14+), this should make it possible to:
- build SDL for iOS, both static and dynamic
- build SDL test apps (as iOS .app bundles)
- generate a working SDL_config.h for iOS (using SDL_config.h.cmake as a basis)
To use, set the following CMake variables when running CMake's configuration stage:
- CMAKE_SYSTEM_NAME=iOS
- CMAKE_OSX_SYSROOT=<SDK> (examples: iphoneos, iphonesimulator, iphoneos12.4, /full/path/to/iPhoneOS.sdk, etc.)
- CMAKE_OSX_ARCHITECTURES=<semicolon-separated list of CPU architectures> (example: "arm64;armv7s")
Examples:
- for Simulator, using the latest, installed SDK:
cmake path/to/SDL -DCMAKE_SYSTEM_NAME=iOS -DCMAKE_OSX_SYSROOT=iphonesimulator -DCMAKE_OSX_ARCHITECTURES=x86_64
- for Device, using the latest, installed SDK, 64-bit only
cmake path/to/SDL -DCMAKE_SYSTEM_NAME=iOS -DCMAKE_OSX_SYSROOT=iphoneos -DCMAKE_OSX_ARCHITECTURES=arm64
- for Device, using the latest, installed SDK, mixed 32/64 bit
cmake path/to/SDL -DCMAKE_SYSTEM_NAME=iOS -DCMAKE_OSX_SYSROOT=iphoneos -DCMAKE_OSX_ARCHITECTURES="arm64;armv7s"
- for Device, using a specific SDK revision (iOS 12.4, in this example):
cmake path/to/SDL -DCMAKE_SYSTEM_NAME=iOS -DCMAKE_OSX_SYSROOT=iphoneos12.4 -DCMAKE_OSX_ARCHITECTURES=arm64
- for Simulator, using the latest, installed SDK, and building SDL test apps (as .app bundles):
cmake path/to/SDL -DSDL_TEST=1 -DCMAKE_SYSTEM_NAME=iOS -DCMAKE_OSX_SYSROOT=iphonesimulator -DCMAKE_OSX_ARCHITECTURES=x86_64
First: disable d'n'd events by default; most apps don't need these at all, and
if an app doesn't explicitly handle these, each drop on the window will cause
a memory leak if the events are enabled. This follows the guidelines we have
for SDL_TEXTINPUT events already.
Second: when events are enabled or disabled, signal the video layer, as it
might be able to inform the OS, causing UI changes or optimizations (for
example, dropping a file icon on a Cocoa app that isn't accepting drops will
cause macOS to show a rejection animation instead of the drop operation just
vanishing into the ether, X11 might show a different cursor when dragging
onto an accepting window, etc).
Third: fill in the drop event details in the test library and enable the
events in testwm.c for making sure this all works as expected.
Michael Sartain
This is a quick pass at adding Linux RealtimeKit thread priority support to SDL.
It allows me to bump the thread priority to high without root privileges or setting any caps, etc.
rtkit readme here:
http://git.0pointer.net/rtkit.git/tree/README
This is commented out in SDLActivity.java, with the note #CURSORIMPLEENTATION because it requires API 24, which is higher than the minimum required SDK
Eric Wasylishen
Patch to support building the tests with cmake.
Disabled by default, use: "cmake .. -DSDL_TEST=YES" to enable the tests.
Tested on macOS 10.13 with the ninja, makefile, and Xcode generators, and Windows 10 with the Visual Studio 2017 generator.
New functions get and set the YUV colorspace conversion mode:
SDL_SetYUVConversionMode()
SDL_GetYUVConversionMode()
SDL_GetYUVConversionModeForResolution()
SDL_ConvertPixels() converts between all supported RGB and YUV formats, with SSE acceleration for converting from planar YUV formats (YV12, NV12, etc) to common RGB/RGBA formats.
Added a new test program, testyuv, to verify correctness and speed of YUV conversion functionality.
Ozkan Sezer
The attached patch makes testautomation_sdltest.c more compatible wrt
LLONG_{MIN|MAX} macros and makes it to compile on older systems (e.g.
glibc-2.8) too, by replacing LLONG_{MIN|MAX} with INT64_{MIN|MAX}.
c.f.: bug #3494, where the same issue was described for SDL_test_fuzzer.c
Ozkan Sezer
An array defined like int xPositions[] = {-1, 0, 1, w-1, w, w+1 };
errors with Open Watcom: it strictly wants constants. Small patch
like below makes things more compatible.
Sylvain
This still happens with the current trunk version. (software renderer of testdrawchessboard.c)
When there is a rotation, the window size changed and the internal surface is marked as "surface_valid == SDL_FALSE".
And all further call fails.
SDL_video.c :
2478 void
2479 SDL_OnWindowResized(SDL_Window * window)
2480 {
2481 window->surface_valid = SDL_FALSE;
2482 SDL_SendWindowEvent(window, SDL_WINDOWEVENT_SIZE_CHANGED, window->w, window->h);
2483 }
some error set to :
2233 return SDL_SetError("Window surface is invalid, please call SDL_GetWindowSurface() to get a new surface");
So, this seems to be the behavior of the API ...
In the loop() function of testdrawchessboard.c, we can recreate the surface/renderer :
65 if (e.type == SDL_WINDOWEVENT)
66 {
67 if (e.window.event == SDL_WINDOWEVENT_SIZE_CHANGED)
68 {
69 surface = SDL_GetWindowSurface(window);
70 renderer = SDL_CreateSoftwareRenderer(surface);
71 }
72 /* Clear the rendering surface with the specified color */
73 SDL_SetRenderDrawColor(renderer, 0xFF, 0xFF, 0xFF, 0xFF);
74 SDL_RenderClear(renderer);
75 }
And it displays correctly.
Fabian Greffrath
we use SDL_GetPrefPath() in Chocolate Doom to get a reasonable directory to save and restore config files and savegames:
https://github.com/chocolate-doom/chocolate-doom/blob/sdl2-branch/src/m_config.c#L2162
However, since there is no "organization" behind Chocolate Doom and there is really only one "product" called Chocolate Doom, we pass an empty string for the org parameter and the package string for app.
This leads to two consecutive slashes in the path returned by SDL_GetPrefPath() like this:
/home/user/.local/share//chocolate-doom/
While this is harmless, it sure looks bad.
I believe that it should be possible to either pass a NULL pointer for the org parameter or at least have the function detect an empty string as a means to express "there is no origanization, just a single product". The generation of the path string to be returned by the function will have to get adapted accordingly.
Eric Wasylishen
Small change to checkkeys so you can toggle text input mode with a mouse click.
This is needed for testing how dead keys react to toggling mouse input, i.e. these bugs:
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.
Sam Lantinga
Cameron Cawley
Brandon Schaefer
David Ludwig
Ozkan Sezer
Ryan C. Gordon
Jeremy Ong
Brandon Schaefer
Philipp Wiesemann