== 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
* the remote control presents itself as ID_INPUT_KEY, not
ID_INPUT_KEYBOARD. However, ID_INPUT_KEYBOARD is a subset of
ID_INPUT_KEY.
* the remote control lacks the backspace and enter keys, which are hard
coded in RetroArch. It has "back" and "ok" instead, so map those to
RETROK_BACKSPACE and RETROK_ENTER as well.
Remote controls also have no ESC key, but that one is customizable
and I used the Power key of the remote (which already has a mapping
to RETROK_POWER).
The functionality provided is really the bare minimum, but it is enough
to teach a kid "press the power button here to watch TV"; compared to
pressing L1+R1+START+SELECT and navigating to the RetroArch's "quit"
menu item, that hopefully has more chances of success.
* the remote control presents itself as ID_INPUT_KEY, not
ID_INPUT_KEYBOARD. However, ID_INPUT_KEYBOARD is a subset of
ID_INPUT_KEY.
* the remote control lacks the backspace and enter keys, which are hard
coded in RetroArch. It has "back" and "ok" instead, so map those to
RETROK_BACKSPACE and RETROK_ENTER as well.
Remote controls also have no ESC key, but that one is customizable
and I used the Power key of the remote (which already has a mapping
to RETROK_POWER).
The functionality provided is really the bare minimum, but it is enough
to teach a kid "press the power button here to watch TV"; compared to
pressing L1+R1+START+SELECT and navigating to the RetroArch's "quit"
menu item, that hopefully has more chances of success.
It has been tested with the ScummVM core on:
- NVIDIA Shield TV running Android Nougat 7.0
- NVIDIA Shield Tablet running Android Nougat 7.0
- NVIDIA Shield Tablet running Android Lollipop 5.1
- Huawei Honor 7 running Android Marshmallow 6.0
- HTC Desire 500 running Android Jelly Bean 4.1
It's been tested using the touch screen, a USB mouse/keyboard combo, and a bluetooth mouse.
The Android version running on the device limits the functionality and user experience of the external mouse support.
Android Nougat and/or an NVIDIA SHIELD device with NVIDIA extensions provides the best user experience:
Android API < 14:
- Only left mouse button supported
- The Android mouse cursor will be visible along with the in game mouse cursor
- When the Android mouse cursor hits the edge of the screen it will not be possible to move the in-game mouse cursor further in that direction
Android API < 24 and no NVIDIA extensions available:
- Both left and right mouse buttons supported
- The Android mouse cursor will be visible along with the in game mouse cursor
- When the Android mouse cursor hits the edge of the screen it will not be possible to move the in-game mouse cursor further in that direction
Android API > 23 and/or NVIDIA extensions available (SHIELD devices):
- Both left and right mouse buttons supported
- The Android mouse cursor will be hidden
- The mouse is not limited by the (hidden) Android mouse cursor hitting the edge of the screen
Description of how the the touchscreen mouse support works:
- You can move the in-game mouse cursor using the touch screen. The in-game mouse cursor will move relative to your movements on the touch screen, it will not be centered on where you press the screen.
- One quick tap on the touch screen results in the left mouse button being clicked
- Two taps on the screen and keeping the second tap pressed down results in a left mouse being held down until you release
- Two fingers on the touch screen results in the right mouse button being clicked
The touch screen mouse functionality is active at the same time as overlay support. This might cause some confusion when using cores that are designed for mouse support but where you have also enabled overlay controls. At the top of android_input.c there's a define that can be used to turn off this functionality if it causes more problems than it solves.
of other sources being set.
API level 9 doesn't support stylus, but still needs to be handled.
Current code throws out additional sources that it doesn't
recognize. This instead ignores whether other sources are set.
