This resolves an irritating issue in the code editor where SDL2-specific functions could't be found. Not entirely sure about the SDL include file logic for other operating systems than Linux so the #ifdef directives may need to be updated further at a later date.
Also a general cleanup of CMakeLists.txt and many small code changes to satisfy Clang that complained quite a lot and actually wouldn't compile the binary at all at first.
As pugixml seems to be well supported nowadays and seems to ship with most distributions it's pretty pointless to keep bundling it with EmulationStation.
The hid-sony driver has both analog and digital buttons for the triggers,
and the analog values range from -32767 to 32767, which can cause two unwanted
input events (digital button and negative axis) per press.
Implement a function to filter out unwanted input events during configuration,
but isolate detection to known PS3 controllers with 6 axes so that older versions
of hid-sony and the sixad driver (which use 25+ axes) are not impacted negatively.
Some drivers (such as hid-sony) configure analog triggers (L2/R2) as axes
with axis range -32768-32767, but the resting value starts at -32768,
causing an initial or light press to register erroneously as a minus
axis value.
Fix by shifting ABS_Z and ABS_RZ axes that are detected to rest at
-32768 so that they will range from 0-32767 instead.
Patch based on Jools Wills' earlier commit: https://github.com/RetroPie/EmulationStation/pull/58
Replace boost::filesystem::is_directory
with Utils::FileSystem::isDirectory
Replace boost::filesystem::is_regular_file
with Utils::FileSystem::isRegularFile
Replace boost::filesystem::is_symlink
with Utils::FileSystem::isSymlink
Replace boost::filesystem::exists
with Utils::FileSystem::exists
Replace boost::filesystem::create_directory
with Utils::FileSystem::createDirectory
Replace boost::filesystem::remove
with Utils::FileSystem::removeFile
Unlike other axis, they don't default to 0, but instead start at -32768 and go to +32767 when pressed. This confuses the
current ES code axis code. As a workaround, we get the initial value and if it is -32767, we add 32767 and divide by two. This gives it
a range that can be handled with the current code (from 0 to 32767). Note on my X11 machine, I had to plug the joystick in after ES
was loaded or it get 0 as the initial axis value for the triggers. This seems ok on the RPI though, so possible some SDL issue.
With this change on a 360 controller the triggers should be correctly detected as +2 and +5 without seeing two presses for each trigger press.
