On X11 Linux, every lightgun event was passed onto every lightgun
device within MAME. This obviously works for 1 gun, but with 2, it
causes both crosshairs to move in the same direction at the same
time.
This effectively reverts b380514764 and
c24473ddff, restoring the state at
598cd52272.
Before pushing, please check that what you're about to push is sane.
Check your local commit log and ensure there isn't anything out-of-place
before pushing to mainline. When things like this happen, it wastes
everyone's time. I really don't need this in a week when real work™ is
busting my balls and I'm behind where I want to be with preparing for
MAME release.
This one was triggered by batman.
Test case:
mame64 -nothrottle batman
Before: Average speed: 312.11% (20 seconds)
After: Average speed: 327.43% (19 seconds)
Signed-off-by: Andreas Müller <schnitzeltony@gmail.com>
SDL/X11 number mouse/lighgun buttons 1,2,3, while windows and other parts of
MAME like offscreen_reload expect 0,2,1. Transpose buttons 2 and 3, and then
-1 the button number to align the numbering schemes.
This fixes lightgun support on Linux - tested with an Ultimarc AimTrak and
the following config:
lightgun 1
lightgun_device lightgun
lightgunprovider x11
lightgun_index1 "Ultimarc Ultimarc"
offscreen_reload 1
Note: MAME must be compiled with XInput support:
make -j10 NO_USE_XINPUT=0
Fixes bug #4695
testkeys:
* Clean up and modernise code
* Use std::endl to end lines for its implicit flush
* Centre window (less likely to hide behind taskbar, etc.)
osdwin:
* Ensure new windows are positioned within the work area of a monitor
Keymaps must have been broken for ages:
- It is now possible to map every scancode SDL2 defines.
- Removed keycode field. This was a leftover from SDL1.x
- Fixed bug preventing keymaps from working.
- Fixed the DE keymap.
- Converted other keymaps to new format and added a
comment that they have to be reviewed and fixed.
Can we have these? I didn't attempt to add implementations for anything other than MSVC, but I believe gcc and clang for 64-bit targets have equivalents.
Reasoning: xaudio2 module was completely disabled for over 2 years and unmaintained. Using "auto", MAME actually chose dsound as default.
Plus I seem to be getting random buffer underflows/overflows with it, it needs to be more stable before it can be default.
related: 8889f182f1
* Fix compile for Android, set API to 24
* Update Android Studio project to API 24
* Fixed project file to latest Android Studio
* fix build with gradle alone
Previous code had several oddities. Like checks against buffer overflows
/ underflows done at several places in the code, usage of a spinlock,
unnecessary use of "volatile" qualifier, redundant informations about
the circular buffer and exposed details about the split nature of ranges
in the buffer. This lead to an unlikely deadlock once in a great while.
Signed-off-by: Celelibi <celelibi@gmail.com>
