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.

Cleaned up dependencies on generating SDL_revision.h
Fixed 'make install' if you are not building from a Mercurial repository

(See mailing list message with subject "Streaming textures not properly initialized?")

Don't remove the pseudo-generated headers because this command might be run from the repo directory and it confuses people, especially if they have no way of regenerating SDL_revision.h :)

Our minimum Windows version is Windows 2000, so it's okay to directly call InitializeCriticalSectionAndSpinCount()..

 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.