kmx git

Commit	Date	Message
ed1d8558	2020-04-14T07:41:00	Fixed bug 4299 - A recent change requires Core Bluetooth framework on iOS Caleb Cornett Just ran into this, and from my testing, whatever re-added the dependency is a _major_ regression. Not only is your app forced to link with CoreBluetooth, but iOS has apparently tightened up security and won't even let you _test_ your app unless it specifies the NSBluetoothAlwaysUsageDescription in an Info.plist. It doesn't even pop up an error message, it just straight up crashes. Adding the permission isn't a good solution either, since I'd really, really rather not have my app request users' bluetooth to always be enabled, especially if the only apparent reason is for Steam Controller support.
e6c640f3	2020-04-13T08:18:16	Enable the virtual joystick API by default
bd7b4f39	2020-04-13T08:05:29	Partial fix for bug 5086 - CMake builds on Windows broken by sensor support (thanks DominikD!)
d292f6bd	2020-04-10T12:17:14	stdlib: Add SDL_trunc and SDL_truncf
a7916890	2020-04-10T00:37:35	metal: Added some support interfaces to Apple's Metal API (thanks, Caleb!). Caleb Cornett's comments: "A few weeks ago, Alex added a partial Metal API to SDL2: https://hg.libsdl.org/SDL/rev/22c8e7cd8d38 I noticed it was missing a few features that would help Metal become a first-class citizen in SDL, so I went ahead and wrote them! Here are the new APIs: 1. SDL_WINDOW_METAL flag for SDL_CreateWindow(). This allows the programmer to specify that they intend to create a window for use with SDL_MetalView. The flag is used to ensure correct usage of the API and to prevent accidentally defaulting to OpenGL on iOS. 2. SDL_Metal_GetLayer(). This function takes a SDL_MetalView and returns a pointer to the view's backing CAMetalLayer. This simplifies things considerably, since in the current version of the SDL_Metal API the programmer is required to bridge-cast a SDL_MetalView handle to an NSView or UIView (depending on the platform) and then extract the layer from there. SDL_Metal_GetLayer automatically handles all of that, making the operation simple and cross-platform. 3. SDL_Metal_GetDrawableSize(). This function already exists in the current SDL_Metal API (and is used behind-the-scenes for SDL_Vulkan_GetDrawableSize on Apple platforms) but was not publicly exposed. My patch exposes this function for public use. It works just like you'd expect. Tested on macOS 10.14 and iOS 12.4." Fixes Bugzilla #4796.
3180ba81	2020-04-08T08:34:27	First pass at Windows sensor implementation
b6eb09ff	2020-03-20T15:55:02	Updated documentation so people know to set the SDL_HINT_NO_SIGNAL_HANDLERS hint before SDL_Init()
4c22a21e	2020-03-17T14:18:05	Fixed bug 3446 - The haptic API does not allow to select the direction axes meyraud705 Added Linux implementation, otherwise you get "Unsupported direction type" error. Added documentation to explain why one would use SDL_HAPTIC_FIRST_AXIS.
73799917	2020-03-16T13:28:38	Fixed bug 3446 - The haptic API does not allow to select the direction axes Mathieu Laurendeau Consider a device supporting effects on multiple axes. There's currently no way to play effects against a single-axis direction. A device supporting effects against X and Y may not allow to play effects with a two-axis direction coordinate, even if one of the coordinates is null. My current (ugly) work around for this is to add a direction type SDL_HAPTIC_X_FORCE to play effects against a X-axis only direction (patch attached). This issue impacted two GIMX users using the following wheels: - Leo Bodnar SimSteering force feedback wheel - Accuforce direct drive wheel Playing constant/spring/damper effects against a X-axis direction worked well for the first wheel, but not for the second one. A better strategy seems to play the effects against the first axis reported by the DirectInput enumeration. This strategy also works with Logitech wheels (at least the DFGT). It's been more than a year that I have the latest patch (playing effects against the first axis only) in the GIMX software. It's being used by thousands of people, mostly for adapting their FFB wheel to the PS4. I had no report that proves this strategy to be wrong.
4dea340c	2020-03-16T12:23:38	Fixed bug 4477 - Support more than 4 XInput-capable devices on Windows Jimb Esser Add new RawInput controller API, and improved correlation with XInput/WGI Reorder joystick init so drivers can ask the others if they handle a device reliably Do not poll disconnected XInput devices (major perf issue) Fix various cases where incorrect correlation could happen Simple mechanism for propagating unhandled Guide button presses even before guaranteed correlation Correlate by axis motion as well as button presses Fix failing to zero other trigger Fix SDL_HINT_JOYSTICK_HIDAPI not working if set before calling SDL_Init() Add missing device to device names Disable RawInput if we have a mismatch of XInput-capable but not RawInput-capable devices Updated to SDL 2.0.13 code with the following notes: New HID driver: xbox360w - no idea what that is, hopefully urelated SDL_hidapijoystick.c had been refactored to couple data handling logic with device opening logic and device lists caused some problems, yields slightly uglier integration than previously when the 360 HID device driver was just handling the data. SDL_hidapijoystick.c now often pulls the device off of the joystick_hwdata structure for some rumble logic, but it appears that code path is never reached, so probably not a problem. Looks like joystick_hwdata was refactored to not include a mutex in other drivers, maintainers may want to do the same refactor here if that's useful for some reason. Something changed in how devices get names, so getting generic names. Had to fix a (new?) bug where removing an XInput controller caused existing controllers (that moved to a new XInput index) to get identified as 0x045e/0x02fd ("it's probably Bluetooth" in code), rendering the existing HIDAPI_IsDevicePresent and new RAWINPUT_IsDevicePresent unreliable.
cc37ee8a	2020-03-16T00:21:22	virtual joysticks: add autotools-build support (Bug 5028) Autotools support for virtual-joysticks turns it OFF by default. To turn it on, pass the following into configure: --enable-joystick-virtual
d6476155	2020-03-15T13:35:03	virtual joysticks: improved docs for SDL_JoystickSetVirtual* functions
cc908756	2020-03-15T13:25:49	virtual joysticks: removed ball support (Bug 5028)
1ff483d1	2020-03-13T21:28:09	Added SDL_GetErrorMsg() to get the error message in a thread-safe way
2be75c6a	2020-03-13T19:08:45	Fixed bug 5028 - Virtual Joysticks (new joystick backend) David Ludwig I have created a new driver for SDL's Joystick and Game-Controller subsystem: a Virtual driver. This driver allows one to create a software-based joystick, which to SDL applications will look and react like a real joystick, but whose state can be set programmatically. A primary use case for this is to help enable developers to add touch-screen joysticks to their apps. The driver comes with a set of new, public APIs, with functions to attach and detach joysticks, set virtual-joystick state, and to determine if a joystick is a virtual-one. Use of virtual joysticks goes as such: 1. Attach one or more virtual joysticks by calling SDL_JoystickAttachVirtual. If successful, this returns the virtual-device's joystick-index. 2. Open the virtual joysticks (using indicies returned by SDL_JoystickAttachVirtual). 3. Call any of the SDL_JoystickSetVirtual* functions when joystick-state changes. Please note that virtual-joystick state will only get applied on the next call to SDL_JoystickUpdate, or when pumping or polling for SDL events (via SDL_PumpEvents or SDL_PollEvent). Here is a listing of the new, public APIs, at present and subject to change: ------------------------------------------------------------ /** * Attaches a new virtual joystick. * Returns the joystick's device index, or -1 if an error occurred. / extern DECLSPEC int SDLCALL SDL_JoystickAttachVirtual(SDL_JoystickType type, int naxes, int nballs, int nbuttons, int nhats); /* * Detaches a virtual joystick * Returns 0 on success, or -1 if an error occurred. / extern DECLSPEC int SDLCALL SDL_JoystickDetachVirtual(int device_index); /* * Indicates whether or not a virtual-joystick is at a given device index. / extern DECLSPEC SDL_bool SDLCALL SDL_JoystickIsVirtual(int device_index); /* * Set values on an opened, virtual-joystick's controls. * Returns 0 on success, -1 on error. / extern DECLSPEC int SDLCALL SDL_JoystickSetVirtualAxis(SDL_Joystick joystick, int axis, Sint16 value); extern DECLSPEC int SDLCALL SDL_JoystickSetVirtualBall(SDL_Joystick * joystick, int ball, Sint16 xrel, Sint16 yrel); extern DECLSPEC int SDLCALL SDL_JoystickSetVirtualButton(SDL_Joystick * joystick, int button, Uint8 value); extern DECLSPEC int SDLCALL SDL_JoystickSetVirtualHat(SDL_Joystick * joystick, int hat, Uint8 value); ------------------------------------------------------------ Miscellaneous notes on the initial patch, which are also subject to change: 1. no test code is present in SDL, yet. This should, perhaps, change. Initial development was done with an ImGui-based app, which potentially is too thick for use in SDL-official. If tests are to be added, what kind of tests? Automated? Graphical? 2. virtual game controllers can be created by calling SDL_JoystickAttachVirtual with a joystick-type of SDL_JOYSTICK_TYPE_GAME_CONTROLLER, with naxes (num axes) set to SDL_CONTROLLER_AXIS_MAX, and with nbuttons (num buttons) set to SDL_CONTROLLER_BUTTON_MAX. When updating their state, values of type SDL_GameControllerAxis or SDL_GameControllerButton can be casted to an int and used for the control-index (in calls to SDL_JoystickSetVirtual* functions). 3. virtual joysticks' guids are mostly all-zeros with the exception of the last two bytes, the first of which is a 'v', to indicate that the guid is a virtual one, and the second of which is a SDL_JoystickType that has been converted into a Uint8. 4. virtual joysticks are ONLY turned into virtual game-controllers if and when their joystick-type is set to SDL_JOYSTICK_TYPE_GAMECONTROLLER. This is controlled by having SDL's default list of game-controllers have a single entry for a virtual game controller (of guid, "00000000000000000000000000007601", which is subject to the guid-encoding described above). 5. regarding having to call SDL_JoystickUpdate, either directly or indirectly via SDL_PumpEvents or SDL_PollEvents, before new virtual-joystick state becomes active (as specified via SDL_JoystickSetVirtual* function-calls), this was done to match behavior found in SDL's other joystick drivers, almost all of which will only update SDL-state during SDL_JoystickUpdate. 6. the initial patch is based off of SDL 2.0.12 7. the virtual joystick subsystem is disabled by default. It should be possible to enable it by building with SDL_JOYSTICK_VIRTUAL=1 Questions, comments, suggestions, or bug reports very welcome!
983bbf9e	2020-03-10T18:35:31	Backed out changeset 51622f74dc85
93ed3c8b	2020-03-10T18:25:47	Updated SDL to version 2.0.13 for development builds
4fb06a2a	2020-03-10T18:25:47	Updated SDL to version 2.0.13 for development builds
611403dd	2020-03-08T21:02:40	Clarified that the clip rectangle is defined relative to the viewport, and added a clip test to testviewport.c
aa384ad0	2020-03-02T15:21:07	Fixed bug 5001 - Feature request: SDL_isupper & SDL_islower
4572dd2a	2020-03-02T10:37:28	Fixed bug 4854 - Add a way to extend the values in controller_type.h Added a hint SDL_HINT_GAMECONTROLLERTYPE to allow overriding the built-in controller type database
74ed2156	2020-03-01T14:58:16	Updated version to 2.0.12 for release candidate build
d7ece7ee	2020-02-17T13:54:45	Made SDL_GetAndroidSDKVersion() available for applications
afb70f26	2020-02-12T13:09:38	test: Reimplemented SDLTest_CommonUsage() to restore binary compatibility. Fixes Bugzilla #4975.
232b7fee	2020-02-11T08:26:46	Make it possible for the application to use different C runtime begin/end thread functions
9feabd35	2020-02-11T08:01:44	Make sure SDL_CreateThread has the same signature regardless of how the DLL was created.
4b585e75	2020-02-03T08:06:52	Fixed bug 4833 - Use EGL for X11? Martin Fiedler To be precise, this is about desktop OpenGL on X11. For OpenGL ES, EGL is already used (as it's the only way to get an OpenGL ES context), as Sylvain noted above. To shine some light on why this is needed: In 99% of all cases, using GLX on X11 is fine, even though it's effectively deprecated in favor of EGL [1]. However, there's at least one use case that requires the OpenGL context being created with EGL instead of GLX, and that's DRM_PRIME interoperability: The function glEGLImageTargetTexture2DOES simply doesn't work with GLX. (Currently, Mesa actually crashes when trying that.) Some example code: https://gist.github.com/kajott/d1b29c613be30893c855621edd1f212e Runs on Intel and open-source AMD drivers just fine (others unconfirmed), but with #define USE_EGL 0 (i.e. forcing it to GLX), it crashes. The same happens when using SDL for window and context creation. The good news is that most of the pieces for EGL support on X11 are already in place: SDL_egl.c is pretty complete (and used for desktop OpenGL on Wayland, for example), and SDL_x11opengl.c has the aforementioned OpenGL-ES-on-EGL support. However, when it comes to desktop OpenGL, it's hardcoded to fall back to GLX. I'm not advocating to make EGL the default for desktop OpenGL on X11; don't fix what ain't broken. But something like an SDL_HINT_VIDEO_X11_FORCE_EGL would be very appreciated to make use cases like the above work with SDL. [1] source: Eric Anholt, major Linux graphics stack developer, 7 years ago already - see last paragraph of https://www.phoronix.com/scan.php?page=news_item&px=MTE3MTI
37278066	2020-01-30T14:51:33	Export SDL functions for iOS application delegates
355f0b54	2020-01-29T20:09:11	Added support for the Steam Controller on mobile devices
b4c2e29e	2020-01-27T10:58:30	video: Added a hint to override the display's usable bounds.
a8780c6a	2020-01-16T20:49:25	Updated copyright date for 2020
981e0d36	2020-01-16T08:52:59	Fixed bug 4903 - Lack of color multiply with alpha (SDL_BLENDMODE_MOD + SDL_BLENDMODE_BLEND) blending mode for all renderers Konrad This kind of blending is rather quite useful and in my opinion should be available for all renderers. I do need it myself, but since I didn't want to use a custom blending mode which is supported only by certain renderers (e.g. not in software which is quite important for me) I did write implementation of SDL_BLENDMODE_MUL for all renderers altogether. SDL_BLENDMODE_MUL implements following equation: dstRGB = (srcRGB * dstRGB) + (dstRGB * (1-srcA)) dstA = (srcA * dstA) + (dstA * (1-srcA)) Background: https://i.imgur.com/UsYhydP.png Blended texture: https://i.imgur.com/0juXQcV.png Result for SDL_BLENDMODE_MOD: https://i.imgur.com/wgNSgUl.png Result for SDL_BLENDMODE_MUL: https://i.imgur.com/Veokzim.png I think I did cover all possibilities within included patch, but I didn't write any tests for SDL_BLENDMODE_MUL, so it would be lovely if someone could do it.
5e19e66c	2019-12-22T13:39:44	Fixed bug 4914 - Expose SDL_ScaleMode and add SDL_SetTextureScaleMode/SDL_GetTextureScaleMode Konrad This was something rather trivial to add, but asked at least several times before (I did google about it as well). It should be possible to dynamically change scaling mode of the texture. It is actually trivial task, but until now it was only possible with a hint before creating a texture. I needed it for my game as well, so I took the liberty of writing it myself. This patch adds following functions: SDL_SetTextureScaleMode(SDL_Texture * texture, SDL_ScaleMode scaleMode); SDL_GetTextureScaleMode(SDL_Texture * texture, SDL_ScaleMode *scaleMode); That way you can change texture scaling on the fly.
46e1377d	2019-12-20T20:12:03	Automatically assign player indexes to game controllers, and allow changing the player index for game controllers and joysticks. Added the functions SDL_JoystickFromPlayerIndex(), SDL_JoystickSetPlayerIndex(), SDL_GameControllerFromPlayerIndex(), and SDL_GameControllerSetPlayerIndex()
e22e77da	2019-12-19T15:01:35	Added an untested driver for the Nintendo GameCube adapter, based on code contributed by Ethan Lee
54748a39	2019-12-08T11:33:06	Fixed bug 4890 - Add hint for SDL that the graphics context is externally managed Aaron Barany Add SDL_HINT_VIDEO_EXTERNAL_CONTEXT hint to notify SDL that the graphics context is external. This disables the automatic context save/restore behavior on Android and avoids using OpenGL by default when SDL_WINDOW_VUKLAN isn't set. When the application wishes to manage the OpenGL contexts on Android, this avoids cases where SDL unbinds the context and creates new contexts, which can interfere with the application's operation. When using Vulkan and Metal renderer implementations, this avoids SDL forcing OpenGL to be enabled on certain platforms. While using the SDL_WINDOW_VULKAN flag can be used to achieve the same thing, it also causes Vulkan to be loaded. If the application uses Vulkan directly, this is not necessary, and fails window creation when using Metal due to Vulkan not being present. (assuming MoltenVK isn't installed)
6fc38864	2019-11-23T03:28:02	SDL_gamecontroller.h: remove comma at end of enumerator list
b5aff9d7	2019-11-22T13:12:12	Added SDL_GameControllerTypeForIndex() and SDL_GameControllerGetType() to return the type of controller attached.
f7df146d	2019-11-21T11:33:50	updated os/2 config file
8cdb4526	2019-11-21T10:33:56	CMakeLists.txt: add several missing function checks for unix case.
65096446	2019-11-20T16:42:50	Improved XInput VID/PID detection and added SDL_wcsstr() and SDL_wcsncmp()
eb8f14bb	2019-11-20T20:40:50	added SDL_strtokr() as a replacement for POSIX strtok_r (bug #4046.)
9a76bebf	2019-11-13T14:24:48	SDL_HINT_GAMECONTROLLER_USE_BUTTON_LABELS defaults to true, to match Steam's default behavior
b22fb9e2	2019-11-11T16:44:40	haiku: Implement message box for Haiku Add implementation for functions: SDL_ShowSimpleMessageBox() SDL_ShowMessageBox() Add simple customization support also. Fix build for x86_gcc2. Partially fixes Bugzilla #4442.
20ddf45e	2019-11-02T22:58:52	Added SDL_PIXELFORMAT_BGR444
b70222d0	2019-11-01T04:32:44	Fixed a comment typo (thanks, Dominus!). https://twitter.com/iniquitatis/status/1190064278365188102
b7df2603	2019-10-24T23:17:19	cmake: added support for enabling the ARM SIMD/NEON code.
a6bfdd10	2019-10-24T21:17:05	ARM: Create configure option --enable-arm-neon to govern assembly optimizations
6a6a0528	2019-10-24T21:12:08	ARM: Create configure option --enable-arm-simd to govern assembly optimizations
9530ccba	2019-10-21T22:22:28	SDL_endian.h: Use endian.h for OpenBSD. Patch from OpenBSD CVS, authored by Donovan Watteau.
7c7801f1	2019-10-21T10:20:25	Fix typo with __MIPSEB__ preprocessor check (bug #4836.) Patch from Simon Howard
b3470f04	2019-10-17T17:32:47	Added the hint SDL_HINT_GAMECONTROLLER_USE_BUTTON_LABELS to control whether Nintendo Switch controllers use their button labels or button positions for game controller button reporting.
ed7483f8	2019-10-15T22:36:08	x11: On macOS, look for X11 install in /opt/X11 instead of /usr/X11R6. This is where Apple installs XQuartz now (and apparently, the compatibility symlink at /usr/X11R6 can be missing). Fixes Bugzilla #4706.
eb066a71	2019-10-15T14:17:32	include: Removed a FIXME comment. Using (1 << 14) instead of 0x4000 might be clearer for the maintainer, but it makes it harder to look up these flags when debugging an app. The value has to be written once by one person, the has to be read by tons of people over and over.
e5198bd2	2019-10-11T06:18:24	Remove 'Enum' suffixes (bug 4813)
a0934a23	2019-10-10T17:40:00	Fixed bug 4813 - Give enums their own name * SDL_PIXELTYPE_ * SDL_BITMAPORDER_ * SDL_PACKEDORDER_ * SDL_ARRAYORDER_ * SDL_PACKEDLAYOUT_ * SDLK_ * SDL_LOG_CATEGORY_
ffc7d091	2019-10-01T14:00:02	endpointvolume.h checks not needed since changeset 13078:8ab094a9df6b .
0918903f	2019-09-30T22:54:16	render: add a hint for toggling relative scaling Fixes Bugzilla #4811.
1ae61f10	2019-09-30T20:58:44	Added a helper function SDL_LockTextureToSurface() Similar to SDL_LockTexture(), except the locked area is exposed as a SDL surface.
68985371	2019-09-24T16:36:48	offscreen: Add new video driver backend Offscreen 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
a74d33b7	2019-09-22T21:41:20	SDL_messagebox.h: remove comma at end of enumerator list
3fe2d836	2019-09-22T10:37:16	Updated SDL development builds to version 2.0.11
3efea5ea	2019-09-11T15:08:37	Don't have Windows headers define min/max, in case they're defined by application code
e5580e18	2019-09-04T09:27:58	x11: add a hint to force the VisualID used when creating a window.
f49c07b5	2019-09-04T00:39:47	stdinc: On macOS and iOS, use memset_pattern4() for SDL_memset4(). Fixes Bugzilla #4724.
b13c951c	2019-08-27T11:07:43	CMake: iOS support added 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
cbdee4d6	2019-08-08T13:26:05	[ SDL ] Fix compile error building for Windows/ARM64 on Visual Studio 2017 Win10 SDK 10.0.18362.0 which requires ar,74intr.h/arm64_neon.h header instead of armintr.h/arm_neon.h for intrinsics. @saml
aebaa316	2019-08-05T12:35:32	Add public APIs for creating a Metal view attached to an SDL window. Add SDL_metal.h.
63197c43	2019-08-02T17:19:50	Fix bug where the wrong button was the default in the old message box because buttons were added backwards, breaking the indexing used by GetButtonIndex. Add messagebox flags to explicilty request left-to-right button order or right-to-left. If neither is specified it'll be some platform default.
d5ec735a	2019-08-01T18:22:12	Add a windowID field to SDL_TouchFingerEvent (bug #4331). This is unimplemented on some platforms and will cause compile errors when building those platform backends for now.
f7d82e56	2019-07-31T12:20:55	hidapi: Add SDL_hidapi.c, allows support for multiple hidapi backends. This is currently supported on Linux and macOS. iOS and Android are not supported at all, Windows support could be added with some changes to the libusb backend. The Visual Studio and Xcode projects do not use this feature. Based on Valve Software's hid.cpp, written in collaboration with Andrew Eikum.
7a47c292	2019-07-31T01:22:02	Fix bug 4746 - introduce SDL_zeroa macro.
39e8b007	2019-07-27T14:08:51	macOS: fix atomics using deprecated functions instead of compiler intrinsics, when SDL is built with the Xcode project.
66d4d8e2	2019-07-08T16:46:52	cmake: Added HIDAPI support.
959cfc42	2019-06-30T23:58:31	Fixed memory barrier macro check so it isn't quite so fragile
cc47810d	2019-06-30T23:26:16	Fixed bug 4683 - SDL_atomic infinite recursion on armv6/armv5 w/ thumb The real problem is that SDL_atomic.c was built in thumb mode instead of ARM mode, which is required to use the mcr instruction on ARM platforms. Added a compiler error to catch this case so we don't generate code that does infinite recursion. I also added a potentially better way to handle things on Linux ARM platforms, based on comments in the Chromium headers, which we can try out after 2.0.10 ships.
282b2b93	2019-06-25T11:47:02	define __ARM_NEON for Windows only if _M_ARM or _M_ARM64 is defined. fixes Visual Studio builds.
be6cda9f	2019-06-19T15:54:21	Rolling back GameCube HIDAPI support It causes the HIDAPI devices to always be opened on enumeration, which causes crashes in the Windows drivers when multiple applications are reading and writing at the same time. We can revisit this after 2.0.10 release.
eb71cd80	2019-06-18T06:53:32	Make sure we haven't changed the size of the SDL_Event structure and broken binary compatibility.
67c67f3a	2019-06-17T10:13:28	Updated version to 2.0.10
69d27a69	2019-06-11T18:13:46	Fixed bug 4570 - Support Vulkan Portability rather than MoltenVK specifically Dzmitry Malyshau Current code, search paths, and error messages are written to only consider MoltenVK on macOS as a Vulkan Portability implementation. It's not the only implementation available to the users. gfx-portability [1] has been shown to run a number of titles well, including Dota2, Dolphin Emulator, and vkQuake3, often out-performing MoltenVK in frame rate and stability (see Dolphin benchmark [2]). There is no reason for SDL to be that specific, it's not using any MVK-specific functions other than the WSI initialization ("VK_MVK_macos_surface"). gfx-portability exposes this extension as well, and a more generic WSI extension is in process. It would be good if SDL was written in a more generic way that expect a Vulkan Portability library as opposed to MoltenVK specifically. [1] https://github.com/gfx-rs/portability [2] https://gfx-rs.github.io/2019/03/22/dolphin-macos-performance.html
9891c31b	2019-06-10T08:46:20	Fixed bug 4641 - clang and clang-cl builds on windows create -Wpragma-pack warnings
762b788f	2019-06-09T12:46:10	Cleanup on bug 3894 - Fuzzing crashes for SDL_LoadWAV Simon Hug Attached is a minor cleanup patch. It changes the option name of one hint to something better, puts one or two more checks in, and adds explicit casting where warnings could appear otherwise. I hope the naming of the hints and their options is acceptable. It would be kind of awkward to change them after they get released with an official SDL version.
990e166a	2019-06-08T19:02:42	Fixed bug 3894 - Fuzzing crashes for SDL_LoadWAV Simon Hug I had a look at this and made some additions to SDL_wave.c. The attached patch adds many checks and error messages. For some reason I also added A-law and ?-law decoders. Forgot exactly why... but hey, they're small. The WAVE format is seriously underspecified (at least by the documents that are publicly available on the internet) and it's a shame Microsoft never put something better out there. The language used in them is so loose at times, it's not surprising the encoders and decoders behave very differently. The Windows Media Player doesn't even support MS ADPCM correctly. The patch also adds some hints to make the decoder more strict at the cost of compatibility with weird WAVE files. I still think it needs a bit of cleaning up (Not happy with the MultiplySize function. Don't like the name and other SDL code may want to use something like this too.) and some duplicated code may be folded together. It does work in this state and I have thrown all kinds of WAVE files at it. The AFL files also pass with it and some even play (obviously just noise). Crafty little fuzzer. Any critique would be welcome. I have a fork of SDL with a audio-loadwav branch over here if someone wants to use the commenting feature of Bitbucket: https://bitbucket.org/ChliHug/SDL I also cobbled some Lua scripts together to create WAVE test files: https://bitbucket.org/ChliHug/gendat
316ff384	2019-06-08T17:43:23	Fixed bug 4526 - replace SDL_RW* macros with functions for using in bindings ace I got this bug in SDL_ttf: https://bugzilla.libsdl.org/show_bug.cgi?id=4524 Sylvain proposed solution: SDL_RWseek(RWops, 0, RW_SEEK_SET); And it works, but i can use it my project, because it written in C# with SDL2-CS wrapper and there not export for macroses: #define SDL_RWsize(ctx) (ctx)->size(ctx) #define SDL_RWseek(ctx, offset, whence) (ctx)->seek(ctx, offset, whence) #define SDL_RWtell(ctx) (ctx)->seek(ctx, 0, RW_SEEK_CUR) #define SDL_RWread(ctx, ptr, size, n) (ctx)->read(ctx, ptr, size, n) #define SDL_RWwrite(ctx, ptr, size, n) (ctx)->write(ctx, ptr, size, n) #define SDL_RWclose(ctx) (ctx)->close(ctx) Therefore, I suggest replacing this macros with functions so that they can be exported and used in bindings
8728ce44	2019-06-08T14:54:37	Fixed bug 4557 - SDL_SIMDAlloc and *Free should be in the public interface Martin Gerhardy These functions are really useful and should get exposed imo.
b5d3b6fc	2019-05-28T17:39:13	test: unify all the command line usage logging.
00e5eeb4	2019-05-19T01:45:15	test: added SDLTest_CommonDefaultArgs() This is for test apps that don't need custom command line arguments; it lets us reduce the boilerplate code a tiny bit.
53a6196b	2019-04-23T16:57:34	Don't redefine __SSE__ and related macros if they're already defined
f79190f4	2019-04-23T07:59:31	Use _Exit() when available
9eac91dd	2019-04-05T08:10:12	Set SDL_HINT_MOUSE_TOUCH_EVENTS for iPhone and iPad as well
05333a6e	2019-04-05T09:16:30	Android: add hint SDL_HINT_ANDROID_BLOCK_ON_PAUSE to set whether the event loop will block itself when the app is paused.
b470cd9b	2019-04-05T08:36:31	Android: default SDL_HINT_MOUSE_TOUCH_EVENTS to 1 as previous behaviour
bfdd0b22	2019-04-04T17:01:02	Android: remove SDL_HINT_ANDROID_SEPARATE_MOUSE_AND_TOUCH java layer runs as if separate mouse and touch was 1, Use SDL_HINT_MOUSE_TOUCH_EVENTS and SDL_HINT_TOUCH_MOUSE_EVENTS for generating synthetic touch/mouse events
e4157618	2019-04-04T16:51:50	Add hint SDL_HINT_MOUSE_TOUCH_EVENTS for mouse events to generate touch events controlling whether mouse events should generate synthetic touch events By default SDL will not generate touch events for mouse events
a0ac5ffc	2019-03-19T10:59:41	Fixed building with C++
03fc5eeb	2019-03-19T10:56:46	Fixed building with C++
8177388e	2019-03-19T08:29:34	Fixed declaration of SDL_main_func for C++
de82759c	2019-03-19T07:53:33	Added support for building SDL as a dynamic library on iOS
911bf624	2019-03-15T14:08:30	events: Make debug logging of the event queue a hint instead of an #ifdef. This makes it easy to toggle it on when debugging a new platform (or just getting more visibility into an app) without having to rebuild SDL.

ed1d8558

2020-04-14T07:41:00

Fixed bug 4299 - A recent change requires Core Bluetooth framework on iOS Caleb Cornett Just ran into this, and from my testing, whatever re-added the dependency is a _major_ regression. Not only is your app forced to link with CoreBluetooth, but iOS has apparently tightened up security and won't even let you _test_ your app unless it specifies the NSBluetoothAlwaysUsageDescription in an Info.plist. It doesn't even pop up an error message, it just straight up crashes. Adding the permission isn't a good solution either, since I'd really, really rather not have my app request users' bluetooth to always be enabled, especially if the only apparent reason is for Steam Controller support.

e6c640f3

2020-04-13T08:18:16

Enable the virtual joystick API by default

bd7b4f39

2020-04-13T08:05:29

Partial fix for bug 5086 - CMake builds on Windows broken by sensor support (thanks DominikD!)

d292f6bd

2020-04-10T12:17:14

stdlib: Add SDL_trunc and SDL_truncf

a7916890

2020-04-10T00:37:35

metal: Added some support interfaces to Apple's Metal API (thanks, Caleb!). Caleb Cornett's comments: "A few weeks ago, Alex added a partial Metal API to SDL2: https://hg.libsdl.org/SDL/rev/22c8e7cd8d38 I noticed it was missing a few features that would help Metal become a first-class citizen in SDL, so I went ahead and wrote them! Here are the new APIs: 1. SDL_WINDOW_METAL flag for SDL_CreateWindow(). This allows the programmer to specify that they intend to create a window for use with SDL_MetalView. The flag is used to ensure correct usage of the API and to prevent accidentally defaulting to OpenGL on iOS. 2. SDL_Metal_GetLayer(). This function takes a SDL_MetalView and returns a pointer to the view's backing CAMetalLayer. This simplifies things considerably, since in the current version of the SDL_Metal API the programmer is required to bridge-cast a SDL_MetalView handle to an NSView or UIView (depending on the platform) and then extract the layer from there. SDL_Metal_GetLayer automatically handles all of that, making the operation simple and cross-platform. 3. SDL_Metal_GetDrawableSize(). This function already exists in the current SDL_Metal API (and is used behind-the-scenes for SDL_Vulkan_GetDrawableSize on Apple platforms) but was not publicly exposed. My patch exposes this function for public use. It works just like you'd expect. Tested on macOS 10.14 and iOS 12.4." Fixes Bugzilla #4796.

3180ba81

2020-04-08T08:34:27

First pass at Windows sensor implementation

b6eb09ff

2020-03-20T15:55:02

Updated documentation so people know to set the SDL_HINT_NO_SIGNAL_HANDLERS hint before SDL_Init()

4c22a21e

2020-03-17T14:18:05

Fixed bug 3446 - The haptic API does not allow to select the direction axes meyraud705 Added Linux implementation, otherwise you get "Unsupported direction type" error. Added documentation to explain why one would use SDL_HAPTIC_FIRST_AXIS.

73799917

2020-03-16T13:28:38

Fixed bug 3446 - The haptic API does not allow to select the direction axes Mathieu Laurendeau Consider a device supporting effects on multiple axes. There's currently no way to play effects against a single-axis direction. A device supporting effects against X and Y may not allow to play effects with a two-axis direction coordinate, even if one of the coordinates is null. My current (ugly) work around for this is to add a direction type SDL_HAPTIC_X_FORCE to play effects against a X-axis only direction (patch attached). This issue impacted two GIMX users using the following wheels: - Leo Bodnar SimSteering force feedback wheel - Accuforce direct drive wheel Playing constant/spring/damper effects against a X-axis direction worked well for the first wheel, but not for the second one. A better strategy seems to play the effects against the first axis reported by the DirectInput enumeration. This strategy also works with Logitech wheels (at least the DFGT). It's been more than a year that I have the latest patch (playing effects against the first axis only) in the GIMX software. It's being used by thousands of people, mostly for adapting their FFB wheel to the PS4. I had no report that proves this strategy to be wrong.

4dea340c

2020-03-16T12:23:38

Fixed bug 4477 - Support more than 4 XInput-capable devices on Windows Jimb Esser Add new RawInput controller API, and improved correlation with XInput/WGI Reorder joystick init so drivers can ask the others if they handle a device reliably Do not poll disconnected XInput devices (major perf issue) Fix various cases where incorrect correlation could happen Simple mechanism for propagating unhandled Guide button presses even before guaranteed correlation Correlate by axis motion as well as button presses Fix failing to zero other trigger Fix SDL_HINT_JOYSTICK_HIDAPI not working if set before calling SDL_Init() Add missing device to device names Disable RawInput if we have a mismatch of XInput-capable but not RawInput-capable devices Updated to SDL 2.0.13 code with the following notes: New HID driver: xbox360w - no idea what that is, hopefully urelated SDL_hidapijoystick.c had been refactored to couple data handling logic with device opening logic and device lists caused some problems, yields slightly uglier integration than previously when the 360 HID device driver was just handling the data. SDL_hidapijoystick.c now often pulls the device off of the joystick_hwdata structure for some rumble logic, but it appears that code path is never reached, so probably not a problem. Looks like joystick_hwdata was refactored to not include a mutex in other drivers, maintainers may want to do the same refactor here if that's useful for some reason. Something changed in how devices get names, so getting generic names. Had to fix a (new?) bug where removing an XInput controller caused existing controllers (that moved to a new XInput index) to get identified as 0x045e/0x02fd ("it's probably Bluetooth" in code), rendering the existing HIDAPI_IsDevicePresent and new RAWINPUT_IsDevicePresent unreliable.

cc37ee8a

2020-03-16T00:21:22

virtual joysticks: add autotools-build support (Bug 5028) Autotools support for virtual-joysticks turns it OFF by default. To turn it on, pass the following into configure: --enable-joystick-virtual

d6476155

2020-03-15T13:35:03

virtual joysticks: improved docs for SDL_JoystickSetVirtual* functions

cc908756

2020-03-15T13:25:49

virtual joysticks: removed ball support (Bug 5028)

1ff483d1

2020-03-13T21:28:09

Added SDL_GetErrorMsg() to get the error message in a thread-safe way

2be75c6a

2020-03-13T19:08:45

Fixed bug 5028 - Virtual Joysticks (new joystick backend) David Ludwig I have created a new driver for SDL's Joystick and Game-Controller subsystem: a Virtual driver. This driver allows one to create a software-based joystick, which to SDL applications will look and react like a real joystick, but whose state can be set programmatically. A primary use case for this is to help enable developers to add touch-screen joysticks to their apps. The driver comes with a set of new, public APIs, with functions to attach and detach joysticks, set virtual-joystick state, and to determine if a joystick is a virtual-one. Use of virtual joysticks goes as such: 1. Attach one or more virtual joysticks by calling SDL_JoystickAttachVirtual. If successful, this returns the virtual-device's joystick-index. 2. Open the virtual joysticks (using indicies returned by SDL_JoystickAttachVirtual). 3. Call any of the SDL_JoystickSetVirtual* functions when joystick-state changes. Please note that virtual-joystick state will only get applied on the next call to SDL_JoystickUpdate, or when pumping or polling for SDL events (via SDL_PumpEvents or SDL_PollEvent). Here is a listing of the new, public APIs, at present and subject to change: ------------------------------------------------------------ /** * Attaches a new virtual joystick. * Returns the joystick's device index, or -1 if an error occurred. */ extern DECLSPEC int SDLCALL SDL_JoystickAttachVirtual(SDL_JoystickType type, int naxes, int nballs, int nbuttons, int nhats); /** * Detaches a virtual joystick * Returns 0 on success, or -1 if an error occurred. */ extern DECLSPEC int SDLCALL SDL_JoystickDetachVirtual(int device_index); /** * Indicates whether or not a virtual-joystick is at a given device index. */ extern DECLSPEC SDL_bool SDLCALL SDL_JoystickIsVirtual(int device_index); /** * Set values on an opened, virtual-joystick's controls. * Returns 0 on success, -1 on error. */ extern DECLSPEC int SDLCALL SDL_JoystickSetVirtualAxis(SDL_Joystick * joystick, int axis, Sint16 value); extern DECLSPEC int SDLCALL SDL_JoystickSetVirtualBall(SDL_Joystick * joystick, int ball, Sint16 xrel, Sint16 yrel); extern DECLSPEC int SDLCALL SDL_JoystickSetVirtualButton(SDL_Joystick * joystick, int button, Uint8 value); extern DECLSPEC int SDLCALL SDL_JoystickSetVirtualHat(SDL_Joystick * joystick, int hat, Uint8 value); ------------------------------------------------------------ Miscellaneous notes on the initial patch, which are also subject to change: 1. no test code is present in SDL, yet. This should, perhaps, change. Initial development was done with an ImGui-based app, which potentially is too thick for use in SDL-official. If tests are to be added, what kind of tests? Automated? Graphical? 2. virtual game controllers can be created by calling SDL_JoystickAttachVirtual with a joystick-type of SDL_JOYSTICK_TYPE_GAME_CONTROLLER, with naxes (num axes) set to SDL_CONTROLLER_AXIS_MAX, and with nbuttons (num buttons) set to SDL_CONTROLLER_BUTTON_MAX. When updating their state, values of type SDL_GameControllerAxis or SDL_GameControllerButton can be casted to an int and used for the control-index (in calls to SDL_JoystickSetVirtual* functions). 3. virtual joysticks' guids are mostly all-zeros with the exception of the last two bytes, the first of which is a 'v', to indicate that the guid is a virtual one, and the second of which is a SDL_JoystickType that has been converted into a Uint8. 4. virtual joysticks are ONLY turned into virtual game-controllers if and when their joystick-type is set to SDL_JOYSTICK_TYPE_GAMECONTROLLER. This is controlled by having SDL's default list of game-controllers have a single entry for a virtual game controller (of guid, "00000000000000000000000000007601", which is subject to the guid-encoding described above). 5. regarding having to call SDL_JoystickUpdate, either directly or indirectly via SDL_PumpEvents or SDL_PollEvents, before new virtual-joystick state becomes active (as specified via SDL_JoystickSetVirtual* function-calls), this was done to match behavior found in SDL's other joystick drivers, almost all of which will only update SDL-state during SDL_JoystickUpdate. 6. the initial patch is based off of SDL 2.0.12 7. the virtual joystick subsystem is disabled by default. It should be possible to enable it by building with SDL_JOYSTICK_VIRTUAL=1 Questions, comments, suggestions, or bug reports very welcome!

983bbf9e

2020-03-10T18:35:31

Backed out changeset 51622f74dc85

93ed3c8b

2020-03-10T18:25:47

Updated SDL to version 2.0.13 for development builds

4fb06a2a

2020-03-10T18:25:47

Updated SDL to version 2.0.13 for development builds

611403dd

2020-03-08T21:02:40

Clarified that the clip rectangle is defined relative to the viewport, and added a clip test to testviewport.c

aa384ad0

2020-03-02T15:21:07

Fixed bug 5001 - Feature request: SDL_isupper & SDL_islower

4572dd2a

2020-03-02T10:37:28

Fixed bug 4854 - Add a way to extend the values in controller_type.h Added a hint SDL_HINT_GAMECONTROLLERTYPE to allow overriding the built-in controller type database

74ed2156

2020-03-01T14:58:16

Updated version to 2.0.12 for release candidate build

d7ece7ee

2020-02-17T13:54:45

Made SDL_GetAndroidSDKVersion() available for applications

afb70f26

2020-02-12T13:09:38

test: Reimplemented SDLTest_CommonUsage() to restore binary compatibility. Fixes Bugzilla #4975.

232b7fee

2020-02-11T08:26:46

Make it possible for the application to use different C runtime begin/end thread functions

9feabd35

2020-02-11T08:01:44

Make sure SDL_CreateThread has the same signature regardless of how the DLL was created.

4b585e75

2020-02-03T08:06:52

Fixed bug 4833 - Use EGL for X11? Martin Fiedler To be precise, this is about *desktop OpenGL* on X11. For OpenGL ES, EGL is already used (as it's the only way to get an OpenGL ES context), as Sylvain noted above. To shine some light on why this is needed: In 99% of all cases, using GLX on X11 is fine, even though it's effectively deprecated in favor of EGL [1]. However, there's at least one use case that *requires* the OpenGL context being created with EGL instead of GLX, and that's DRM_PRIME interoperability: The function glEGLImageTargetTexture2DOES simply doesn't work with GLX. (Currently, Mesa actually crashes when trying that.) Some example code: https://gist.github.com/kajott/d1b29c613be30893c855621edd1f212e Runs on Intel and open-source AMD drivers just fine (others unconfirmed), but with #define USE_EGL 0 (i.e. forcing it to GLX), it crashes. The same happens when using SDL for window and context creation. The good news is that most of the pieces for EGL support on X11 are already in place: SDL_egl.c is pretty complete (and used for desktop OpenGL on Wayland, for example), and SDL_x11opengl.c has the aforementioned OpenGL-ES-on-EGL support. However, when it comes to desktop OpenGL, it's hardcoded to fall back to GLX. I'm not advocating to make EGL the default for desktop OpenGL on X11; don't fix what ain't broken. But something like an SDL_HINT_VIDEO_X11_FORCE_EGL would be very appreciated to make use cases like the above work with SDL. [1] source: Eric Anholt, major Linux graphics stack developer, 7 years ago already - see last paragraph of https://www.phoronix.com/scan.php?page=news_item&px=MTE3MTI

37278066

2020-01-30T14:51:33

Export SDL functions for iOS application delegates

355f0b54

2020-01-29T20:09:11

Added support for the Steam Controller on mobile devices

b4c2e29e

2020-01-27T10:58:30

video: Added a hint to override the display's usable bounds.

a8780c6a

2020-01-16T20:49:25

Updated copyright date for 2020

981e0d36

2020-01-16T08:52:59

Fixed bug 4903 - Lack of color multiply with alpha (SDL_BLENDMODE_MOD + SDL_BLENDMODE_BLEND) blending mode for all renderers Konrad This kind of blending is rather quite useful and in my opinion should be available for all renderers. I do need it myself, but since I didn't want to use a custom blending mode which is supported only by certain renderers (e.g. not in software which is quite important for me) I did write implementation of SDL_BLENDMODE_MUL for all renderers altogether. SDL_BLENDMODE_MUL implements following equation: dstRGB = (srcRGB * dstRGB) + (dstRGB * (1-srcA)) dstA = (srcA * dstA) + (dstA * (1-srcA)) Background: https://i.imgur.com/UsYhydP.png Blended texture: https://i.imgur.com/0juXQcV.png Result for SDL_BLENDMODE_MOD: https://i.imgur.com/wgNSgUl.png Result for SDL_BLENDMODE_MUL: https://i.imgur.com/Veokzim.png I think I did cover all possibilities within included patch, but I didn't write any tests for SDL_BLENDMODE_MUL, so it would be lovely if someone could do it.

5e19e66c

2019-12-22T13:39:44

Fixed bug 4914 - Expose SDL_ScaleMode and add SDL_SetTextureScaleMode/SDL_GetTextureScaleMode Konrad This was something rather trivial to add, but asked at least several times before (I did google about it as well). It should be possible to dynamically change scaling mode of the texture. It is actually trivial task, but until now it was only possible with a hint before creating a texture. I needed it for my game as well, so I took the liberty of writing it myself. This patch adds following functions: SDL_SetTextureScaleMode(SDL_Texture * texture, SDL_ScaleMode scaleMode); SDL_GetTextureScaleMode(SDL_Texture * texture, SDL_ScaleMode *scaleMode); That way you can change texture scaling on the fly.

46e1377d

2019-12-20T20:12:03

Automatically assign player indexes to game controllers, and allow changing the player index for game controllers and joysticks. Added the functions SDL_JoystickFromPlayerIndex(), SDL_JoystickSetPlayerIndex(), SDL_GameControllerFromPlayerIndex(), and SDL_GameControllerSetPlayerIndex()

e22e77da

2019-12-19T15:01:35

Added an untested driver for the Nintendo GameCube adapter, based on code contributed by Ethan Lee

54748a39

2019-12-08T11:33:06

Fixed bug 4890 - Add hint for SDL that the graphics context is externally managed Aaron Barany Add SDL_HINT_VIDEO_EXTERNAL_CONTEXT hint to notify SDL that the graphics context is external. This disables the automatic context save/restore behavior on Android and avoids using OpenGL by default when SDL_WINDOW_VUKLAN isn't set. When the application wishes to manage the OpenGL contexts on Android, this avoids cases where SDL unbinds the context and creates new contexts, which can interfere with the application's operation. When using Vulkan and Metal renderer implementations, this avoids SDL forcing OpenGL to be enabled on certain platforms. While using the SDL_WINDOW_VULKAN flag can be used to achieve the same thing, it also causes Vulkan to be loaded. If the application uses Vulkan directly, this is not necessary, and fails window creation when using Metal due to Vulkan not being present. (assuming MoltenVK isn't installed)

6fc38864

2019-11-23T03:28:02

SDL_gamecontroller.h: remove comma at end of enumerator list

b5aff9d7

2019-11-22T13:12:12

Added SDL_GameControllerTypeForIndex() and SDL_GameControllerGetType() to return the type of controller attached.

f7df146d

2019-11-21T11:33:50

updated os/2 config file

8cdb4526

2019-11-21T10:33:56

CMakeLists.txt: add several missing function checks for unix case.

65096446

2019-11-20T16:42:50

Improved XInput VID/PID detection and added SDL_wcsstr() and SDL_wcsncmp()

eb8f14bb

2019-11-20T20:40:50

added SDL_strtokr() as a replacement for POSIX strtok_r (bug #4046.)

9a76bebf

2019-11-13T14:24:48

SDL_HINT_GAMECONTROLLER_USE_BUTTON_LABELS defaults to true, to match Steam's default behavior

b22fb9e2

2019-11-11T16:44:40

haiku: Implement message box for Haiku Add implementation for functions: SDL_ShowSimpleMessageBox() SDL_ShowMessageBox() Add simple customization support also. Fix build for x86_gcc2. Partially fixes Bugzilla #4442.

20ddf45e

2019-11-02T22:58:52

Added SDL_PIXELFORMAT_BGR444

b70222d0

2019-11-01T04:32:44

Fixed a comment typo (thanks, Dominus!). https://twitter.com/iniquitatis/status/1190064278365188102

b7df2603

2019-10-24T23:17:19

cmake: added support for enabling the ARM SIMD/NEON code.

a6bfdd10

2019-10-24T21:17:05

ARM: Create configure option --enable-arm-neon to govern assembly optimizations

6a6a0528

2019-10-24T21:12:08

ARM: Create configure option --enable-arm-simd to govern assembly optimizations

9530ccba

2019-10-21T22:22:28

SDL_endian.h: Use endian.h for OpenBSD. Patch from OpenBSD CVS, authored by Donovan Watteau.

7c7801f1

2019-10-21T10:20:25

Fix typo with __MIPSEB__ preprocessor check (bug #4836.) Patch from Simon Howard

b3470f04

2019-10-17T17:32:47

Added the hint SDL_HINT_GAMECONTROLLER_USE_BUTTON_LABELS to control whether Nintendo Switch controllers use their button labels or button positions for game controller button reporting.

ed7483f8

2019-10-15T22:36:08

x11: On macOS, look for X11 install in /opt/X11 instead of /usr/X11R6. This is where Apple installs XQuartz now (and apparently, the compatibility symlink at /usr/X11R6 can be missing). Fixes Bugzilla #4706.

eb066a71

2019-10-15T14:17:32

include: Removed a FIXME comment. Using (1 << 14) instead of 0x4000 might be clearer for the maintainer, but it makes it harder to look up these flags when debugging an app. The value has to be written once by one person, the has to be read by tons of people over and over.

e5198bd2

2019-10-11T06:18:24

Remove 'Enum' suffixes (bug 4813)

a0934a23

2019-10-10T17:40:00

Fixed bug 4813 - Give enums their own name * SDL_PIXELTYPE_ * SDL_BITMAPORDER_ * SDL_PACKEDORDER_ * SDL_ARRAYORDER_ * SDL_PACKEDLAYOUT_ * SDLK_ * SDL_LOG_CATEGORY_

ffc7d091

2019-10-01T14:00:02

endpointvolume.h checks not needed since changeset 13078:8ab094a9df6b .

0918903f

2019-09-30T22:54:16

render: add a hint for toggling relative scaling Fixes Bugzilla #4811.

1ae61f10

2019-09-30T20:58:44

Added a helper function SDL_LockTextureToSurface() Similar to SDL_LockTexture(), except the locked area is exposed as a SDL surface.

68985371

2019-09-24T16:36:48

offscreen: Add new video driver backend Offscreen 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

a74d33b7

2019-09-22T21:41:20

SDL_messagebox.h: remove comma at end of enumerator list

3fe2d836

2019-09-22T10:37:16

Updated SDL development builds to version 2.0.11

3efea5ea

2019-09-11T15:08:37

Don't have Windows headers define min/max, in case they're defined by application code

e5580e18

2019-09-04T09:27:58

x11: add a hint to force the VisualID used when creating a window.

f49c07b5

2019-09-04T00:39:47

stdinc: On macOS and iOS, use memset_pattern4() for SDL_memset4(). Fixes Bugzilla #4724.

b13c951c

2019-08-27T11:07:43

CMake: iOS support added 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

cbdee4d6

2019-08-08T13:26:05

[ SDL ] Fix compile error building for Windows/ARM64 on Visual Studio 2017 Win10 SDK 10.0.18362.0 which requires ar,74intr.h/arm64_neon.h header instead of armintr.h/arm_neon.h for intrinsics. @saml

aebaa316

2019-08-05T12:35:32

Add public APIs for creating a Metal view attached to an SDL window. Add SDL_metal.h.

63197c43

2019-08-02T17:19:50

Fix bug where the wrong button was the default in the old message box because buttons were added backwards, breaking the indexing used by GetButtonIndex. Add messagebox flags to explicilty request left-to-right button order or right-to-left. If neither is specified it'll be some platform default.

d5ec735a

2019-08-01T18:22:12

Add a windowID field to SDL_TouchFingerEvent (bug #4331). This is unimplemented on some platforms and will cause compile errors when building those platform backends for now.

f7d82e56

2019-07-31T12:20:55

hidapi: Add SDL_hidapi.c, allows support for multiple hidapi backends. This is currently supported on Linux and macOS. iOS and Android are not supported at all, Windows support could be added with some changes to the libusb backend. The Visual Studio and Xcode projects do not use this feature. Based on Valve Software's hid.cpp, written in collaboration with Andrew Eikum.

7a47c292

2019-07-31T01:22:02

Fix bug 4746 - introduce SDL_zeroa macro.

39e8b007

2019-07-27T14:08:51

macOS: fix atomics using deprecated functions instead of compiler intrinsics, when SDL is built with the Xcode project.

66d4d8e2

2019-07-08T16:46:52

cmake: Added HIDAPI support.

959cfc42

2019-06-30T23:58:31

Fixed memory barrier macro check so it isn't quite so fragile

cc47810d

2019-06-30T23:26:16

Fixed bug 4683 - SDL_atomic infinite recursion on armv6/armv5 w/ thumb The real problem is that SDL_atomic.c was built in thumb mode instead of ARM mode, which is required to use the mcr instruction on ARM platforms. Added a compiler error to catch this case so we don't generate code that does infinite recursion. I also added a potentially better way to handle things on Linux ARM platforms, based on comments in the Chromium headers, which we can try out after 2.0.10 ships.

282b2b93

2019-06-25T11:47:02

define __ARM_NEON for Windows only if _M_ARM or _M_ARM64 is defined. fixes Visual Studio builds.

be6cda9f

2019-06-19T15:54:21

Rolling back GameCube HIDAPI support It causes the HIDAPI devices to always be opened on enumeration, which causes crashes in the Windows drivers when multiple applications are reading and writing at the same time. We can revisit this after 2.0.10 release.

eb71cd80

2019-06-18T06:53:32

Make sure we haven't changed the size of the SDL_Event structure and broken binary compatibility.

67c67f3a

2019-06-17T10:13:28

Updated version to 2.0.10

69d27a69

2019-06-11T18:13:46

Fixed bug 4570 - Support Vulkan Portability rather than MoltenVK specifically Dzmitry Malyshau Current code, search paths, and error messages are written to only consider MoltenVK on macOS as a Vulkan Portability implementation. It's not the only implementation available to the users. gfx-portability [1] has been shown to run a number of titles well, including Dota2, Dolphin Emulator, and vkQuake3, often out-performing MoltenVK in frame rate and stability (see Dolphin benchmark [2]). There is no reason for SDL to be that specific, it's not using any MVK-specific functions other than the WSI initialization ("VK_MVK_macos_surface"). gfx-portability exposes this extension as well, and a more generic WSI extension is in process. It would be good if SDL was written in a more generic way that expect a Vulkan Portability library as opposed to MoltenVK specifically. [1] https://github.com/gfx-rs/portability [2] https://gfx-rs.github.io/2019/03/22/dolphin-macos-performance.html

9891c31b

2019-06-10T08:46:20

Fixed bug 4641 - clang and clang-cl builds on windows create -Wpragma-pack warnings

762b788f

2019-06-09T12:46:10

Cleanup on bug 3894 - Fuzzing crashes for SDL_LoadWAV Simon Hug Attached is a minor cleanup patch. It changes the option name of one hint to something better, puts one or two more checks in, and adds explicit casting where warnings could appear otherwise. I hope the naming of the hints and their options is acceptable. It would be kind of awkward to change them after they get released with an official SDL version.

990e166a

2019-06-08T19:02:42

Fixed bug 3894 - Fuzzing crashes for SDL_LoadWAV Simon Hug I had a look at this and made some additions to SDL_wave.c. The attached patch adds many checks and error messages. For some reason I also added A-law and ?-law decoders. Forgot exactly why... but hey, they're small. The WAVE format is seriously underspecified (at least by the documents that are publicly available on the internet) and it's a shame Microsoft never put something better out there. The language used in them is so loose at times, it's not surprising the encoders and decoders behave very differently. The Windows Media Player doesn't even support MS ADPCM correctly. The patch also adds some hints to make the decoder more strict at the cost of compatibility with weird WAVE files. I still think it needs a bit of cleaning up (Not happy with the MultiplySize function. Don't like the name and other SDL code may want to use something like this too.) and some duplicated code may be folded together. It does work in this state and I have thrown all kinds of WAVE files at it. The AFL files also pass with it and some even play (obviously just noise). Crafty little fuzzer. Any critique would be welcome. I have a fork of SDL with a audio-loadwav branch over here if someone wants to use the commenting feature of Bitbucket: https://bitbucket.org/ChliHug/SDL I also cobbled some Lua scripts together to create WAVE test files: https://bitbucket.org/ChliHug/gendat

316ff384

2019-06-08T17:43:23

Fixed bug 4526 - replace SDL_RW* macros with functions for using in bindings ace I got this bug in SDL_ttf: https://bugzilla.libsdl.org/show_bug.cgi?id=4524 Sylvain proposed solution: SDL_RWseek(RWops, 0, RW_SEEK_SET); And it works, but i can use it my project, because it written in C# with SDL2-CS wrapper and there not export for macroses: #define SDL_RWsize(ctx) (ctx)->size(ctx) #define SDL_RWseek(ctx, offset, whence) (ctx)->seek(ctx, offset, whence) #define SDL_RWtell(ctx) (ctx)->seek(ctx, 0, RW_SEEK_CUR) #define SDL_RWread(ctx, ptr, size, n) (ctx)->read(ctx, ptr, size, n) #define SDL_RWwrite(ctx, ptr, size, n) (ctx)->write(ctx, ptr, size, n) #define SDL_RWclose(ctx) (ctx)->close(ctx) Therefore, I suggest replacing this macros with functions so that they can be exported and used in bindings

8728ce44

2019-06-08T14:54:37

Fixed bug 4557 - SDL_SIMDAlloc and *Free should be in the public interface Martin Gerhardy These functions are really useful and should get exposed imo.

b5d3b6fc

2019-05-28T17:39:13

test: unify all the command line usage logging.

00e5eeb4

2019-05-19T01:45:15

test: added SDLTest_CommonDefaultArgs() This is for test apps that don't need custom command line arguments; it lets us reduce the boilerplate code a tiny bit.

53a6196b

2019-04-23T16:57:34

Don't redefine __SSE__ and related macros if they're already defined

f79190f4

2019-04-23T07:59:31

Use _Exit() when available

9eac91dd

2019-04-05T08:10:12

Set SDL_HINT_MOUSE_TOUCH_EVENTS for iPhone and iPad as well

05333a6e

2019-04-05T09:16:30

Android: add hint SDL_HINT_ANDROID_BLOCK_ON_PAUSE to set whether the event loop will block itself when the app is paused.

b470cd9b

2019-04-05T08:36:31

Android: default SDL_HINT_MOUSE_TOUCH_EVENTS to 1 as previous behaviour

bfdd0b22

2019-04-04T17:01:02

Android: remove SDL_HINT_ANDROID_SEPARATE_MOUSE_AND_TOUCH java layer runs as if separate mouse and touch was 1, Use SDL_HINT_MOUSE_TOUCH_EVENTS and SDL_HINT_TOUCH_MOUSE_EVENTS for generating synthetic touch/mouse events

e4157618

2019-04-04T16:51:50

Add hint SDL_HINT_MOUSE_TOUCH_EVENTS for mouse events to generate touch events controlling whether mouse events should generate synthetic touch events By default SDL will *not* generate touch events for mouse events

a0ac5ffc

2019-03-19T10:59:41

Fixed building with C++

03fc5eeb

2019-03-19T10:56:46

Fixed building with C++

8177388e

2019-03-19T08:29:34

Fixed declaration of SDL_main_func for C++

de82759c

2019-03-19T07:53:33

Added support for building SDL as a dynamic library on iOS

911bf624

2019-03-15T14:08:30

events: Make debug logging of the event queue a hint instead of an #ifdef. This makes it easy to toggle it on when debugging a new platform (or just getting more visibility into an app) without having to rebuild SDL.

kc3-lang/SDL/include

include

Log