The only reason we need a custom view is to handle right mouse down.
Implemented mouse grabbing, although it's kind of clunky right now. I'll be adding a relative mode that will be smoother soon.
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.
