* 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
- only call disconnect when we're actually disconnecting a remote
(e.g. read errors or remote goes to sleep).
- clean up some compile warnings introduced by others (mainly
unused variables)
* Add GET_THROTTLE_STATE environment callback
* Add RETRO_THROTTLE_UNBLOCKED
to report the case where neither vsync nor audio is limiting the call rate.
Also fix reporting of some special cases when the menu is open.
* Change throttle state mode to unsigned
Use #defines Instead of the untyped C enum to allow easier future additions.
* Spelling fixes
* Avoid any divide-by-zero
== DETAILS
Use a little trickery to ensure the GCA driver continues working
with other HID implementation.
I've expanded the joypad implementation to support multi-pad devices.
However, this requires changes to each HID implementation to actually
function.
I've made the necessary changes for WIIU, but I don't have the means
of making the change in the other HID implementations.
So, I've built in a backwards-compatibilty mode for the driver.
The trick is to have an identifier byte at the top of both data structs
that the driver returns. We can then use that byte to determine which
of the structs has been passed to the pad functions and act accordingly.
In the GCA case, for non-wiiu platforms, it will simply expose port 1
of the GCA and the other 3 ports do nothing.
== 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
== DETAILS
So, basically this back-and-forth is because we used fixed-size
data types (i.e. `uint32_t`) which maps to different primitive data
types on different platforms. So `uint32_t` might be a `long` on some
platforms (e.g. Wii U), while it's just a plain integer on others (PC).
And the format specifier works off primitive data type, not data type
size.
So, to resolve this, we:
- keep `%lx` as the format specifier
- cast the parameter to printf to unsigned long
This is better than the alternatives that could cause problems trying to
cast a long down to an int.
== DETAILS
These changes fall into a few broad categories:
1. Explicitly undefine things we want to re-define due to conflicts with
the version of devkitpro we're using
2. Clean up hex format specifiers to use `%lx` or `%lX` when working with
long integers
3. Move variables inside the ifdef they're used in to squelch "unused variable"
messages
4. Add parenthesis to make Wii U shader declarations stop complaining
And then there's a weird "misleading indent" warning that I fixed by just
rewriting a block of code to use a switch statement instead of if-then-else.
These changes work fine on Wii U, but we'll need to keep an eye on CI/CD to see
if other platform builds break.
* Fix for warning and fix for incorrect comment
* Fixed contrast to be more correct - now scales from 0-10 linearly and behaves more the way you'd expect it to - changed name to ditch legacy settings users may have
Added ability to skip inverse tonemapper to the shader via the constant buffer using 'inverse_tonemap' - set to 0.0f to skip
Fixed potential bug when swapping between hdr and sdr and the bit depth not being set correctly
Fixed dx11's blend, rasterizer and topology states not being set to the sames when using hdr and leaving the menu - caused issues with PCSX2's Shadow of the Colossus
Added numerous helper functions to help create the correct values to colour the UI - normally the white UI elements should be rendered at paper white not max brightness for various reasons
* Fix stylistic issues - * Don't use camelcase for variables and function names * Use '(void)' for function declarations instead of () in C code * Declare variables at the top of a function or code block * Make sure functions that return a value always have a default return path that is not encapsulated by an else block * Use more unique names for retro_math functions which are less likely to overlap with other libraries' function symbols
Co-authored-by: twinaphex <libretro@gmail.com>
gblues