1
0
mirror of https://github.com/Relintai/sdl2_frt.git synced 2024-12-20 22:16:49 +01:00
Commit Graph

768 Commits

Author SHA1 Message Date
Sam Lantinga
86517d3eda Fixed bug 5242 - KMOD_* flags unnecessarily macros; breaks OGRE
Rainer Deyke

While most of the KMOD_* flags are enums, the combination flags KMOD_CTRL, KMOD_ALT, KMOD_SHIFT and KMOD_GUI are defined as macros.  This breaks third-party code that uses these KMOD_* names for local identifiers, such as OGRE.  The correct thing to do is to make them all enums.
2020-08-10 08:42:35 -07:00
Ryan C. Gordon
af71510cca assert: Implement SDL_TriggerBreakpoint for Apple ARM hardware. 2020-07-16 04:43:08 -04:00
Ryan C. Gordon
6aec6da4c3 stdinc: Let Clang static analysis see more C runtime functions.
For systems without strlcpy and strlcat, just declare them as if they exist;
the analyzer possibly still knows the details of these functions and can
utilize that in its analysis.

Most of this patch was from meyraud705 at gmail and Martin Gerhardy. Thanks!

Fixes Bugzilla .
2020-06-28 17:45:07 -04:00
Sylvain Beucler
e594a6738a emscripten: Introduce SDL_HINT_EMSCRIPTEN_ASYNCIFY
See https://github.com/emscripten-core/emscripten/issues/10746

and

https://github.com/emscripten-ports/SDL2/pull/112

Fixes Bugzilla .
2020-06-27 16:25:47 -04:00
Ryan C. Gordon
1947ca7028 video: Changed SDL_VIDEO_MINIMIZE_ON_FOCUS_LOSS to default to FALSE.
Fixes Bugzilla .  (and probably many others, too!)
2020-06-26 20:16:43 -04:00
Sam Lantinga
7c0986fba4 Fixed bug 4938 - Suggestion: rename SDL_PIXELFORMAT_BGR888 to SDL_PIXELFORMAT_XBGR8888
Ellie

I just tripped over this: stb_image when requesting 3 channels with 8-bit actually returns them as 3 bytes per pixel with no alignment, so basically 4 pixels are 12 bytes with no padding (0...2, 3...5, 6...8, and 9...11). This I would have naively expected to be called RGB888 or BGR888, since there is no "dead" unused byte as I would expect for something called e.g. RGBX8888.

However, SDL2's SDL_PIXELFORMAT_BGR888 uses 4 bytes, same as SDL_PIXELFORMAT_BGRX8888, even though the latter appears to be a longer storage format - which it isn't, internally. It's just swapped, in byte order X, B, G, R (instead of BGRX). So why isn't the macro name also swapped, as "XBGR888" instead of just "BGR888"?

I find the formats therefore named inconsistently, and unless there is a reason for this I suggest these changes:

1. deprecate SDL_PIXELFORMAT_BGR888 in favor of a new SDL_PIXELFORMAT_XBGR8888

and

2. deprecate SDL_PIXELFORMAT_RGB888 in favor of a new SDL_PIXELFORMAT_XRGB8888
2020-06-12 10:30:46 -07:00
Ethan Lee
2aa8974f97 Add SDL_SIMDRealloc 2020-06-11 12:03:33 -04:00
Sam Lantinga
06267f5028 Fixed whitespace in SDL_vulkan.h 2020-06-02 16:59:54 -07:00
Sam Lantinga
2303d92188 Fixed bug 5145 - Fix whitespace in SDL_vulkan.h
Colin Caine

Everywhere else seems to use spaces.

See patch diffed from a fresh hg checkout yesterday.
2020-05-29 16:28:56 -07:00
Sam Lantinga
abd5841850 Make some changes to SDL_SetThreadPriority to try and have SDL transparently handle more of the work.
1. Comment that SDL_SetThreadPriority will make any necessary system changes when applying priority.
2. Add a hint to override SDL's default behavior for scheduler policy.
3. Modify the pthreads SDL_SetThreadPriority so that instead of just using the current thread scheduler policy it will change it to a policy that should work best for the requested priority.
4. Add hint checks in SDL_SetThreadPriority so that  can be overridden if desired.
5. Modify the Linux SDL_SetThreadPriority so that in the case that policy, either by SDL defaults or from the hint, is a realtime policy it uses the realtime rtkit API.
6. Prior to calling rtkit on Linux make the necessary thread state changes that rtkit requires.  Currently this is done every time as it isn't expected that SDL_SetThreadPriority will be called repeatedly for a thread.
2020-05-26 13:19:19 -07:00
Sam Lantinga
eadc8693dd Fixed bug 5103 - Port fcitx support to both fcitx 4 & 5
wengxt

Due to the new major fcitx version is coming close, the existing code need to be ported to use new Fcitx dbus interface.

The new dbus interface is supported by both fcitx 4 and 5, and has a good side effect, which is that it will work with flatpak for free. Also the patch remove the dependency on fcitx header. Instead, it just hardcodes a few enum value in the code so need to handle the different header for fcitx4 or 5.
2020-05-11 14:31:04 -07:00
Ryan C. Gordon
fa23e3d00b locale: Implemented SDL_GetPreferredLocales().
This was something I proposed a long time ago, Sylvain Becker did
additional work on it, then back to me.

Fixes Bugzilla .
2020-05-04 02:27:29 -04:00
Sam Lantinga
65ad45340d Improvement for bug 3446 - The haptic API does not allow to select the direction axes
meyraud705

I see how the documentation is confusing. I think that the choice of the axis is an implementation detail. The documentation should state the goal of this value, so I propose this wording:

    "Use this value to play an effect on the steering wheel axis. This provides
     better compatibility across platforms and devices as SDL will guess the
     correct axis."

Value could even be renamed 'SDL_HAPTIC_STEERING_AXIS'.

For Linux, sending an effect on the X axis with a Logitech wheel works. Others brands don't have driver for Linux as far as I know.
2020-05-04 13:17:43 -07:00
Ryan C. Gordon
8601996fbc hints: Allow specifying audio device metadata.
This is only supported on PulseAudio. You can set a description when opening
your audio device that will show up in pauvcontrol, which lets you set
per-stream volume levels.

Fixes Bugzilla .
2020-05-03 22:13:48 -04:00
Ryan C. Gordon
11fef299d1 hints: Fixed a doxygen comment. 2020-05-03 20:56:18 -04:00
Sam Lantinga
0f374b069b Fixed build on older Visual Studio, enable new features on newer Visual Studio 2020-04-22 15:42:32 -07:00
Sam Lantinga
116b8c17f2 Note which Windows SDK version is required for Windows Gaming Input support 2020-04-19 00:05:54 -07:00
Sam Lantinga
aba2792896 Added a Windows Gaming Input joystick driver
This driver supports the Razer Atrox Arcade Stick

Some of the quirks of this driver, inherent in Windows Gaming Input:
* There will never appear to be controllers connected at startup. You must support hot-plugging in order to see these controllers.
* You can't read the state of the guide button
* You can't get controller events in the background
2020-04-18 21:41:37 -07:00
Sam Lantinga
ed1d855865 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.
2020-04-14 07:41:00 -07:00
Sam Lantinga
e6c640f314 Enable the virtual joystick API by default 2020-04-13 08:18:16 -07:00
Sam Lantinga
bd7b4f39ed Partial fix for bug 5086 - CMake builds on Windows broken by sensor support (thanks DominikD!) 2020-04-13 08:05:29 -07:00
hmk
0918903f3c render: add a hint for toggling relative scaling
Fixes Bugzilla .
2019-09-30 22:54:16 +03:00
Ryan C. Gordon
d292f6bd4f stdlib: Add SDL_trunc and SDL_truncf 2020-04-10 12:17:14 -04:00
Ryan C. Gordon
a791689086 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 .
2020-04-10 00:37:35 -04:00
Sam Lantinga
3180ba81af First pass at Windows sensor implementation 2020-04-08 08:34:27 -07:00
Sam Lantinga
b6eb09ff13 Updated documentation so people know to set the SDL_HINT_NO_SIGNAL_HANDLERS hint before SDL_Init() 2020-03-20 15:55:02 -07:00
Sam Lantinga
4c22a21e06 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.
2020-03-17 14:18:05 -07:00
Sam Lantinga
7379991778 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.
2020-03-16 13:28:38 -07:00
Sam Lantinga
4dea340ca7 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.
2020-03-16 12:23:38 -07:00
David Ludwig
cc37ee8a0c 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
2020-03-16 00:21:22 -04:00
David Ludwig
d64761558c virtual joysticks: improved docs for SDL_JoystickSetVirtual* functions 2020-03-15 13:35:03 -04:00
David Ludwig
cc90875647 virtual joysticks: removed ball support (Bug 5028) 2020-03-15 13:25:49 -04:00
Sam Lantinga
1ff483d1f3 Added SDL_GetErrorMsg() to get the error message in a thread-safe way 2020-03-13 21:28:09 -07:00
Sam Lantinga
2be75c6a61 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!
2020-03-13 19:08:45 -07:00
Sam Lantinga
93ed3c8baf Updated SDL to version 2.0.13 for development builds 2020-03-10 18:25:47 -07:00
Sam Lantinga
983bbf9ef3 Backed out changeset 51622f74dc85 2020-03-10 18:35:31 -07:00
Sam Lantinga
4fb06a2a38 Updated SDL to version 2.0.13 for development builds 2020-03-10 18:25:47 -07:00
Sam Lantinga
611403dd0e Clarified that the clip rectangle is defined relative to the viewport, and added a clip test to testviewport.c 2020-03-08 21:02:40 -07:00
Sam Lantinga
aa384ad02b Fixed bug 5001 - Feature request: SDL_isupper & SDL_islower 2020-03-02 15:21:07 -08:00
Sam Lantinga
4572dd2ae6 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
2020-03-02 10:37:28 -08:00
Sam Lantinga
74ed215618 Updated version to 2.0.12 for release candidate build 2020-03-01 14:58:16 -08:00
Sam Lantinga
d7ece7ee6f Made SDL_GetAndroidSDKVersion() available for applications 2020-02-17 13:54:45 -08:00
Ryan C. Gordon
afb70f2681 test: Reimplemented SDLTest_CommonUsage() to restore binary compatibility.
Fixes Bugzilla .
2020-02-12 13:09:38 -05:00
Sam Lantinga
232b7feef6 Make it possible for the application to use different C runtime begin/end thread functions 2020-02-11 08:26:46 -08:00
Sam Lantinga
9feabd351c Make sure SDL_CreateThread has the same signature regardless of how the DLL was created. 2020-02-11 08:01:44 -08:00
Sam Lantinga
4b585e75d9 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
2020-02-03 08:06:52 -08:00
Sam Lantinga
37278066f2 Export SDL functions for iOS application delegates 2020-01-30 14:51:33 -08:00
Sam Lantinga
355f0b54ec Added support for the Steam Controller on mobile devices 2020-01-29 20:09:11 -08:00
Ryan C. Gordon
b4c2e29eed video: Added a hint to override the display's usable bounds. 2020-01-27 10:58:30 -05:00
Sam Lantinga
a8780c6a28 Updated copyright date for 2020 2020-01-16 20:49:25 -08:00