Edgar Simo 2011-02-20 10:27:52 PST
Adding patch that adds a simplified API for the haptic subsystem built ontop of
the "real one" for those who want simple rumble without jumping through hoops.
Adds 4 functions:
- extern DECLSPEC int SDLCALL SDL_HapticRumbleSupported(SDL_Haptic * haptic);
- extern DECLSPEC int SDLCALL SDL_HapticRumbleInit(SDL_Haptic * haptic);
- extern DECLSPEC int SDLCALL SDL_HapticRumblePlay(SDL_Haptic * haptic, float
strength, Uint32 length );
- extern DECLSPEC int SDLCALL SDL_HapticRumbleStop(SDL_Haptic * haptic);
Also provided is test/testrumble.c which does test this.
This has all been tested on linux and has worked, but due to being built ontop
of the other haptic API it should work on all OS the same.
Edgar Simo 2011-02-20 09:02:31 PST
Linux uses fname, which is the name of the device path like for example
/dev/input/event3 so it shouldn't have the issue. However I can confirm that it
looks like haptic->index never gets properly set on windows. Have to look at
mac os x also. I'll see if I can fix it real quick now.
Patrick Baggett 2011-02-16 22:58:33 PST
This enhancement is for both x86/x64 Windows.
The SDL implementation of mutexes uses the Win32 API interprocess
synchronization primitive called a "Mutex". This implementation is subpar
because it has a much higher overhead than an intraprocess mutex. The exact
technical details are below, but my tests have shown that for reasonably high
contention (10 threads on 4 physical cores), it has 13x higher overhead than
the Win32 CriticalSection API.
If this enhancement is accepted, I will write a patch to implement SDL mutexes
using the critical section API, which should dramatically reduce overhead and
improve scalability.
-- Tech details --
Normally, Win32 Mutexes are used across process boundaries to synchronize
separate processes. In order to lock or unlock them, a user->kernel space
transition is necessary, even in the uncontented case on a single CPU machine.
Win32 CriticalSection objects can only be used within the same process virtual
address space and thus to lock one, does not require a user->kernel space
transition for the uncontended case, and additionally may spin a short while
before going into kernel wait. This small spin allows a thread to obtain the
lock if the mutex is released shortly after the thread starts spinning, in
effect bypassing the overhead of user->kernel space transition which has higher
overhead than the spinning itself.
Even if we're blitting between two different surfaces their pixels might still overlap, because of SDL_CreateRGBSurfaceFrom(), so always use SDL_BlitCopy() and check for overlap in that function.
When handling overlapping surfaces, don't assume that memcpy() iterates forward, instead use memmove() correctly, and provide a fallback implementation of SDL_memmove() that handles the different cases.
Fixed a bug with SDL_memset() not completely filling lengths that aren't a multiple of 4.
Optimized SDL_memcpy() a bit using the same technique as SDL_memset().
Chusslove Illich 2011-02-13 04:30:28 PST
Currently SDL_JOYSTICK_DEVICE environment variable can be used to add
exactly one topmost device. I think it would be nice if one could also set
several devices (e.g. a stick and a throttle) in this way, as a colon-
separated list. The attached patch implements this
Bruno 2010-12-16 02:41:51 PST
Fix segfault in ALSA_OpenDevice()
When alsa is linked to libsdl instead of being loaded on demand at runtime the
alsa macro snd_pcm_hw_params_alloca(ptr); misbehaves.
That macro calls snd_pcm_hw_params_sizeof() in order to determine the amount of
memory to allocate but due to mis-placed define that function is replaced with
ALSA_snd_pcm_hw_params_sizeof by preprocessor (and in case of link to alsa that
function pointer is initialized to itself).
Attached patch fixes the issue.
