Repurpose vibrate_on_keypress to enable device's standard keypress feedback on overlay key/button state changes
- Add keypress_vibrate function ptr to input_driver_t (only implemented on Android for now)
- (Android) Remove APP_CMD_VIBRATE_KEYPRESS
- (Android) Add doHapticFeedback, called directly to avoid latency
* Any pad can control the menu
== DETAILS
I am not sure I've quite got it so that any pad can *open* the
menu, but I do have it so any pad can control it.
- split out the input processing into a separate method
- track down and squish some hairy bugs that boiled down to
bad pointer math
- it looks like `menu_driver.c` has a mix of line endings, so I
ran it through `dos2unix` so it has consistent line endings
again.
- verified that this change did not impact actual cores
* optimize out cumulative_bits
* Incorporate PR feedback
Many thanks to @jdgleaver for providing these optimizations.
* apply one more optimization
== DETAILS
(I think)
- Uncomment the call in the read loop to start feeding packets to the
driver
- implement the GCA packet driver
- implement the pad interface
- fix indentations in GCA driver
== TESTING
Compiles. Haven't tested yet.
This code used a keyboardState size of 256 and indexed it with a
retro_key, which can be any value (RETROK_RALT is 307). This fixes
that by using RETROK_LAST as the array size.
Should fix#6322.
== DETAILS
The BIT256_GET() macro expects a bit number (from 0-255), and we're giving it
a 32-bit mask (0x000080000).
Solution:
- Define VPAD_BUTTON_xxx_BIT macros using the bit number
- Use said macro in wiiu_input.c
- organizational cleanup:
* put VPAD_BUTTON_TOUCH into the enum in stead of as a hokey define
* put the touch bits in the right order
* put in placeholder enums for (currently) unused bits
== DETAILS
- the free() method of the hid_driver_t interface needs its
parameter defined as const in order for the compiler to stop
complaining about losing const-ness.
- if a joypad list is created with <MAX_USERS slots in it, the
destroy() function will crash because it assumes there are MAX_USERS
entries.
To do this, the allocate function creates n+1 slots, and gives the
last slot a canary value that the destroy() method can then watch for
when iterating through the list.
== DETAILS
The current HID implementation assumes a very low-level USB library
is being used. This causes a problem on Wii U, because the Cafe OS
only exposes a high-level interface.
To get these functions exposed to the HID pad drivers, I had to make
three changes:
1. I added the legacy "send_control" function to the HID driver
interface
2. I modified the signature of pad_connection_pad_init() to send the
driver pointer instead of the function pointer
3. I updated the HID pad drivers to keep the pointer to the driver
instead of the function pointer, and updated the calls into the
send_control function as appropriate
4. I updated the HID drivers to use the new pad init signature
== TESTING
Untested, in theory it should work without a hitch because at this
point all I've done is abstract things a little. I still need to
update the HID pad drivers to use the Wii U-specific calls as
appropriate.
== DETAILS
Looking at the apple input driver gave me an idea--moving the
HID driver into the wiiu_input_t data instead of piggy-backing
it off the wiiu_joypad driver.
- Remove changes to wiiu_joypad
- Add equivalent to wiiu_input
This is probably broke as hell. Haven't tried to compile.
Oops! Didn't do this quite right the first time round.
This commit fixes RETRO_DEVICE_ID_POINTER_PRESSED, which would always
return 0 due to to an implicit case to int16_t. Basically, we'd do
(val & 0x00080000) & 0xFFFF; which would return 0 every time. Fixed that
by wrapping it in a ternary. Yes, I know we could use a rotation, but
for a boolean value it really doesn't matter.
I also rewrote scaleTP to deal entirely in integers. While the
floating-point math was theoretically faster on PowerPC; it gets awkward
to cast -0x7FFF to a float.
Speaking of, the driver now actually conforms to the libretro API. Not
sure how I managed to not see the spec; but hey, now its fixed.
RETRO_DEVICE_POINTER_ID_X/Y will now return values between -0x7FFF and
0x7FFF like they're supposed to.
Big thanks to @r-type for hounding me to fix this.
Partially addresses #5294; we still need mouse emulation.
Allow using the Gamepad's touch screen as a RETRO_DEVICE_POINTER.
Methodology could use some work, had to add an extra axis to
joypad in order to get the data transferred into the input driver.
Feel free to change this.
Needs to emulate RETRO_DEVICE_LIGHTGUN to really be useful.
Potential for Wiimote IR in future.
Partially addresses libretro/RetroArch#5294
