The X11 XKeyEvent structure (and others) include a timestamp
field, with 1ms resolution.
This was previously ignored causing the input timestamps to be
set to the middle of each frame.
If the timestamps are passed through then the event timestamps are
not coupled to the framerate and the polling issues are resolved.
* Initialise variables to ensure input thread is started
m_bShutdown was not initialised. This meant that the input
thread would never be started seemingly at random.
In my case m_bShutdown was always false when running in fullscreen
but not in windowed mode for some reason
* XInput support for the DirectInput driver
The XBox360 controller driver for windows has a flaw where the DirectInput backwards-compatible driver registers dance pad arrows as a hat and will not allow opposite arrows to be pressed at the same time. This is not a problem in the XInput interface since the arrows are registered as a DPad and each arrow is a button.
This patch adds XInput support for the DirectInput driver. On initialization XInput controllers will be detected and registered first, followed by enumerating DirectInput devices. During DirectInput enumeration any XInput-capable controllers will be bypassed so that they aren't registered twice.
* Fix joystick input for xinput driver
Needed to compensate for deadzones, magnitude of the inputs, and that the Y axis was reversed.
* Remove unnecesarry using statement for vectors
The biggest obstacle right now deals with FFMPEG. I insist on being able to utilize the git clone/submodule (5_1_0) section. I'm just struggling with the commands.
As part of this commit, some linux files are restored in the compilation chain. This is for consistency with the old Makefile approach.
Assistance will be needed at this point to complete MinGW support.
This attempts to organize all needed items and places appropriate defines
in a single location. Redundant comparisons/defines were removed when noticed.
A few caveats, however:
* This may be better targeted towards the 5_1_0 branch instead of master right now.
* Cmake will run a little slower on configuration/generation now. That's due to the sanity checks it runs.
* There are some more checks to be added later, but this should be a solid start.
Thanks to the [libical](https://github.com/libical/libical) project for inspiration.
On my Fedora 20 system, closedir apparently frees the dirent, and
reading it afterwards returns garbage data. This prevented my dance pad
from being detected.
Old code would, by coincidence, map 1->16 to 1->16, then 17->32 to
1->32, leaving 1 and 17 on the same button number.
We still map 33->56 to 1->24, creating some overlap. But at least that's
because StepMania will have run out of buttons.
THIS PATCH WILL CHANGE THE CODES OF JOYSTICK BUTTONS 17 AND UP.
types and let the user try to use whatever they might have. Even if it can't be
mapped properly to something that will work it's still worth trying and
shouldn't cause any major problems (other than just not being able to play with
some weird devices, like lightguns for example).
that should fix a lot more pads that were being reported as not being detected.
Also added some debug log messages that output each device's type and name
so in the future if other devices fail to be detected we can easily see what it
is in the info log.
5f7001e: "Added a new branch"
01456ed: "Fixed a lot of memory leaks"
dac4493: "Fixed all remaining memory leaks that I could figure out"
0792db7: "Removed the smnew macro and the call to _CrtSetDbgFlag()"
Some of these caused destructor-time problems due to static initialization
order fiasco and related issues. Notably, the program would no longer exit on
OSX and had to be killed.
There were probably legitimate fixes in here, but since these are monolithic
commits it's too much work to extract them now. Let's reapply them
individually and in the forward direction.
the debug output for the Debug and FastDebug project configurations. This
requires replacing all instances of new with a macro, smnew, that defines a
special form of new which outputs file and line number information along with
the memory leak details. This makes finding memory leaks much easier since you
can just double-click the leak in the output window and it will take you to the
line that caused it.
General guide: if the parameter name and its typings
match almost exactly, the name goes away.
Otherwise, it's commented out to allow for some
documentation.
Gareth Francis