- Fix analog drift blocking touch input (could occur on overlay_next if physical inputs shown on overlay)
- Fix overlay_next buttons lighting up in unison
- Skip meta keys in input_overlay_add_inputs (not supported by input_state_internal)
Allows stretching hitboxes and handling their overlap
reach_up, reach_down, reach_left, reach_right:
- Stretches in one direction:
reach_x, reach_y
- Stretches symmetrically
exclusive:
- If true, blocks input from overlapped hitboxes
range_mod_exclusive:
- Similar, but only applies when this hitbox is extended by range_mod
- After range_mod takes effect, has priority over 'exclusive'
E.g. This creates a D-Pad area and extends its hitbox left & right 50%, up 15%, and down 30%. Then applies range_mod_exclusive:
overlay0_desc0 = "dpad_area,0.15,0.57,rect,0.166228,0.295516"
overlay0_desc0_reach_x = 1.5
overlay0_desc0_reach_up = 1.15
overlay0_desc0_reach_down = 1.3
overlay0_desc0_range_mod = 2.0
overlay0_desc0_range_mod_exclusive = true
- New descriptors: 'dpad_area' and 'abxy_area'
- Each has a diagonal sensitivity setting, 100% being 8-way symmetry
- Buttons can be redefined in the cfg file
E.g. This would create a d-pad area, then redefine it to use analog directions:
overlay0_desc0 = "dpad_area,0.85,0.57,rect,0.166228,0.295516"
overlay0_desc0_up = "r_y_minus"
overlay0_desc0_down = "r_y_plus"
overlay0_desc0_left = "r_x_minus"
overlay0_desc0_right = "r_x_plus"
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
* * Use flags for rarch_state
* Get rid of ^M linebreaks in retroarch_types.h
* Buildfixes for consoles
* (audio driver) use flags instead of bools
* (video) Use flags instead of bools
* Rewrite input driver state bools into flags
* Reduce snprintf and/or use them only for concatenating the
string formatting of numbers/values
* Reduce snprintfs
* Use snprintf for concatenation at parts
* * We don't need to NULL-terminate strings that get passed to strlcpy/strlcat
and friends
* Use snprintf for concatenation in certain instances
* Do away with some string intermediary copies where we can avoid it
* Fix warning unused variable
* * Reduce snprintf calls
* Rewrite snprintf calls into strlcpy where possible
* Use snprintf for concatenation when necessary
* Do away with some string intermediary copies in task_translation.c
* run_translation_service - make switch slightly smaller
(snprintf) Try to reduce or simplify snprintf calls, only tend to
use it for processing integers/numbers and avoid it for regular
string concatenation (NOTE: we try to be a bit safer about it to
address earlier cited criticism, although we don't consider concatenating
3 or 4 characters at the end to be insecure)
(msg_hash_to_str) Try to avoid duplicate calls to the same localized
string when we can just cache the results once instead locally
- (database_info.c) Optimizations for database_info_build_query_enum() -
it would call strlcat at the very least 3 times, normally more than that.
Every strlcat call is at least one or more strlens. Reduce it all down
to manual string concatenation and one strlcat
- (database_info_build_query_enum) - always NULL terminates string so no need for NULL termination done by callee
* (menu_displaylist) use smaller strings for basename paths, remove one unnecessary string
in menu_displaylist.c function
- (disk_index_file.c) Avoid another trivial string concatenation by doing
it manually after fill_pathname_join_special
- (fill_pathname_join_delim) since fill_pathname_join_delim() now has a return value, use it for
string concatenation
- (platform_unix) - Use BUFSIZ as size for a buffer in system_property_get
- some other trivial strlcat usage replacements
as deprecated.
* Use fill_pathname_join_special in the vast majority of cases where
we can ensure out_path is a new empty string
* Get rid of some extension concatenation with strlcat where encountered
* Some general cleanups with NULL termination of strings that get immediately
passed to strlcpy/strlcpy-adjacent functions
* (joypad_connection) Small optimizations -
* Turn functions static where possible
* Hose strlen call out of loop
* (input_driver.c) General cleanups:
* Some small code/style nits
task_screenshot.c:
* Move widget callback function for screenshots to task_screenshot.c
(file_path.c):
* Turn get_pathname_num_slashes into static function
* path_linked_list_free - always returns true, so get rid of return value
* path_linked_list_new - fix function signature
* path_get_archive_delim - do not NULL-terminate string, already done by strlcpy later on
General:
* Slight optimizations - use int/size_t for loop counter variable instead of unsigned
* Take advantage of fact that strlcpy already NULL-terminates, so don't do this explicitly
outside if we're just going to end up calling strlcpy/fill_pathname_join on it anyway
* 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
* Move more state to runloop state
* remove unused variable
* Cleanup
* Move more state to runloop_state
* Remove unused variable
* Cleanups
* move input_remapping functions over to input_driver.c
* Some buildfixes
== DETAILS
When I first implemented the Wii U HID architecture, I ended up
having to design my own implementation because, at the time, I did
not have a way to read the HID device string to allow the existing
code to successfully detect the gamepad.
After spending some time experimenting, I've figured out how to
do this. And that means I can better align the HID driver with other
platforms.
change summary:
- create a single state structure for all three sub-types of wiiu pads
(kpad, wpad, and hid)
- eliminate confusing duplicate pad lists
- eliminate confusing duplicate HID pad drivers (ds3, gamecube
adapter, etc)
- ensure the ds3 driver still works
sonninnos