The joystick layer can't necessarily give us perfect centering, but we know
that the game controller level has logical absolute idle positions that have
nothing to do with the physical device.
So send game controller events to make it look like the device is completely
untouched before sending the final removal event.
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
meyraud705
On line 220 of SDL_hidapi_xbox360.c https://hg.libsdl.org/SDL/file/4608f0e6e8e3/src/joystick/hidapi/SDL_hidapi_xbox360.c#l220
if (!XINPUTGETSTATE(user_index, &xinput_state[user_index].state) == ERROR_SUCCESS) {
logical not is only applied to the left hand side of this comparison.
I think you mean:
if (XINPUTGETSTATE(user_index, &xinput_state[user_index].state) != ERROR_SUCCESS) {
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.
On Raspberry Pi 3 via the VC4 driver in firmware KMS mode, none of the
found configs match the desired format, causing the function to fall through
without any config being selected.
Fix by first iterating over the found configs, and if no match exists,
don't exclude the non-matching configs. This should fix RPI3 and possibly other
targets without breaking targets that have a matching native format (such as RPI4).
This allows you to bind surfaceless contexts on a background thread to, for
example, load assets in a separate context, for platforms that have different
requirements about sharing surfaces, etc.
Martin's notes on the matter:
"Here's a patch that enables passing NULL windows to SDL_GL_MakeCurrent, if
the involved APIs allow it. Currently, this is only the case for EGL, and
even then only if some specific extensions are present (which they usually
are).
If "surfaceless" contexts are not supported, SDL_GL_MakeCurrent continues to
generate an error (albeit with a more specific error message than it used to),
so this should not break anything that wasn't broken before."
(Please see https://bugzilla.libsdl.org/show_bug.cgi?id=3695 for more
discussion.)
Fixes Bugzilla #3695.
This behavior matches SDL_RecreateWindow and makes it less likely that
another piece of code (e.g. a DestroyWindowFramebuffer implementation)
will attempt to use or free the stale surface pointer.
A project being built entirely statically will call pkg-config with
--static, which utilises the Libs.private field. Conversely it will
not use --static when not being built entirely statically, even if
there is only a static build of SDL available. This will most likely
cause the build to fail due to underlinking unless we merge the Libs
fields.
This is what the Meson build system does when it generates pkg-config
files. This also also follows the behaviour of sdl2-config.
At the same time, the runtime linker flags are not applicable to
static-only builds so only add them for shared builds.
From hmk:
"When scaling is enabled (e.g. via SDL_RenderSetLogicalSize, size not equal
to window size), mouse motion events are also scaled. Small motions are
rounded up (SDL_max() when the value after scaling is less than 1), while
larger motions are truncated by the floating point -> integer conversion.
https://hg.libsdl.org/SDL/file/b18197f9bf9d/src/render/SDL_render.c#l658
The end result feels something like mouse reverse mouse acceleration + angle
snapping at low speeds, but less consistent (amount of truncation & rounding
depends on how fast the mouse is moved) and potentially much worse if the
scaling factor is large. This pretty much makes it useless for anything
where you need precise mouse aiming (think of games). I suspect this is why
aiming gets so terrible in some games that let you use scaling to reduce the
render resolution (e.g. Ion Fury).
With 4x4 scaling, I can reproduce a situation where it takes three fast flicks
of the mouse across the pad to undo one slow sweep across the pad. In other
words, extreme reverse acceleration. This does not happen when scaling is
disabled.
Furthermore, any game that uses relative mouse motion events for 3D camera
rotation probably wants the raw mouse deltas and not a value that depends on
scaling and resolution and rounding and truncation. Ideal camera rotation
just takes mouse input, multiplies it by sensitivity, and adds it to the
angle-in-radians or whatever measure is used for yaw & pitch. Pixels and
screen resolution or window dimensions should not be a part of the equation
at all, even if it could be implemented without rounding errors.
[...]
This [patch] completely eliminates angle snapping for me, and makes
sensitivity consistent. In other words, it's completely usable for, say,
aiming in a first person shooter."
Partially fixes Bugzilla #4811.
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.
Ryan C. Gordon
Sam Lantinga
Conn O'Griofa
Jay Petacat
James Le Cuirot
hmk
Charlie Birks
Charlie Birks