Age | Commit message (Collapse) | Author | Files | Lines |
|
|
|
Android
|
|
|
|
|
|
Patch provided by jintiao and Milan Nikolic, thanks!
|
|
XInput goes from 0 to 64k; we were feeding it values in the range of 0 to 32k.
Fixes Bugzilla #3002.
|
|
|
|
There are likely several more I missed.
|
|
Mathieu Laurendeau
Check the result of IDirectInputEffect_SetParameters and re-acquire the device to solve concurrency issues.
|
|
|
|
Patch contributed by Sylvain
|
|
|
|
|
|
|
|
|
|
Joe Thompson
With Direct Input device (MOMO Steering Wheel w/FF)
with SDL 2.0.3,
SDL_HapticOpenFromJoystick() would fail. (Can't set exclusive mode)
Now with 2.0.4 rc1,
SDL_HapticOpenFromJoystick() succeeds but the the returned SDL_Haptic* cannot be used. Calls to SDL_HapticNewEffect() fail with "Haptic error Unable to create effect"
If SDL_HapticOpen() is used instead of HapticOpenFromJoystick(), the device is usable. Calls to HapticNewEffect() succeed with the exact same parameters as the previous failing call.
I have attached a proposed patch for this issue.
When using SDL_HapticOpenFromJoystick(), the original code did not (re)enumerate the axes. This returned a new haptic device with 0 axes. Later, when a new effect is created, SDL_SYS_SetDirection() would set the flags to include DIEFF_SPHERICAL, regardless of what the caller actually set. (see Line 566 in SDL_dinputhaptic.c). This would cause the SDL_HapticNewEffect() to fail (or interpret the coordinates incorreclty.)
The patch moves the call to IDirectInputDevice8_EnumObjects() outside of the if() block so that the axes are (re)enumerated for the new haptic device.
Note: For steering wheels it is common for the joystick to have multiple axes (ie steering, throttle, brake), but the haptic portion of the joystick usually only applies to steering.
|
|
|
|
Fixes Bugzilla #3238.
|
|
|
|
This allows us to set an explicit stack size (overriding the system default
and the global hint an app might have set), and remove all the macro salsa
for dealing with _beginthreadex and such, as internal threads always set those
to NULL anyhow.
I've taken some guesses on reasonable (and tiny!) stack sizes for our
internal threads, but some of these might turn out to be too small in
practice and need an increase. Most of them are simple functions, though.
|
|
|
|
As Tiffany pointed out in Bugzilla, volatile is not useful for thread safety:
https://software.intel.com/en-us/blogs/2007/11/30/volatile-almost-useless-for-multi-threaded-programming/
Some of these volatiles didn't need to be, some were otherwise protected by
spinlocks or mutexes, and some got moved over to SDL_atomic_t data, etc.
Fixes Bugzilla #3220.
|
|
|
|
CR: Sam
|
|
Fixes Bugzilla #3014.
|
|
Technically this is caused by the haptic devices not being closed at quit time, which we need to fix anyway, but this is a bandaid for now.
|
|
It was called if file descriptor was none and -1.
|
|
(Maybe) Fixes Bugzilla #3001.
|
|
|
|
|
|
|
|
Fixes Bugzilla #2932.
|
|
|
|
|
|
|
|
|
|
(Thanks, Simon!)
Fixes Bugzilla #2881.
|
|
|
|
|
|
handled as time instead of angle; + direction clarification
Elias Vanderstuyft
Remove the dependency of the calculation of Linux "phase" on "period",
currently the "phase" parameter is interpreted as a time shift, instead of a phase shift.
The Linux input documentation is not clear about the exact units of the "phase" parameter (see http://lxr.free-electrons.com/source/include/uapi/linux/input.h?v=3.17#L1075 ),
but we're about to standardize the 'phase shift' interpretation into the Linux input documentation,
since this will ease the job of a driver to recalculate the effect's state when the user dynamically updates the "period" parameter.
|
|
handled as time instead of angle; + direction clarification
Elias Vanderstuyft
It's not obvious from the general "haptic direction" description what the SDL direction actually means in terms of force magnitude sign,
currently its meaning is only reflected by the example.
|
|
A negative periodic magnitude doesn't exist in Windows' and MacOS' FF APIs
The periodic magnitude parameter of the SDL Haptic API is based on the Linux
FF API, so it means they are not directly compatible:
'dwMagnitude' is a 'DWORD', which is unsigned.
Fixes Bugzilla #2701.
|
|
Thanks, Elias!
Partially fixes Bugzilla #2686.
|
|
There was a misconception that Linux's saturation and deadband parameters -
on which the corresponding SDL parameters were based - use only half of the
possible range.
Thanks, Elias!
Partially fixes Bugzilla #2686.
|
|
Thanks, Elias!
Partially fixes Bugzilla #2686.
|
|
Thanks, Elias!
Partially fixes Bugzilla #2686.
|
|
(or linux-direction 0xFFFF)
Thanks, Elias!
Partially fixes Bugzilla #2686.
|
|
Alex Szpakowski
Some minor changes to the Mac-specific backend code:
- Fixed up some code style issues (mostly brace style inconsistencies).
- Fixed a compiler warning in SDL_cocoaevents.m.
- Removed some useless code now that the 10.7 SDK is required to build SDL.
- Removed Gestalt(gestaltSystemVersion, ...) call and switched to NSAppKitVersionNumber for version checking code. Using Gestalt with gestaltSystemVersion will give 0x1090 in Mac OS 10.10+, and the whole Gestalt function was deprecated in Mac OS 10.8.
|
|
|
|
|