s_encodingPrograms is defined as an array with a length of 64
NUM_ENCODING_PROGRAMS is also defined as 64.
However 64 is out of bounds, so we want to be comparing for "equal to or
greater than here"
The logic of RendererHasFocus was extremely convoluted beforehand and
was too brittle and broke in certain circumstances, like when the
GCPad window was active. Simplify it and leave a comment explaining the
new logic. This fixes the GCPad window not working when Background Input
is unchecked.
Lessens the restrictions on the searching in the code view.
Now typing out the full 8 digit hex number isn't needed. For example, you don't need to type 000000FF to go to FF, you just literally type FF.
Also makes JumpToAddress a boolean function to remain consistent with the DSP code view.
This will also change the address search box to have a red background if
either an invalid hex number is given, or if it's longer than 8 characters
This will allow us to simplify the checks for background input and push
them further down into the architecture, into the ControllerEmu layer.
The new setting isn't actually used yet, though.
Do the scaling in the code that interprets the results.
This also removes the templatization of things and changes the interface
to always take a double.
This does add a bit more code to the users of GetState, especially when
having to deal with focus management, but this will be cleaned up very
soon, as focus and focus-related options will be centralized inside the
input platforms themselves, rather than spread out across all the input
plugins.
Most users will have something in the radius or deadzone fields, so
don't bother filtering out 'extra' work. This also lets us clean up
the modifier implementation.
It was only used for really old joypads which we really don't want to
support. If users have these joypads, they should look into using
something at the OS level, as games shouldn't need to have this
transformation; it should be done by the OS and driver.
Change our DrawCoordinate helper method to take raw coordinate
positions, and draw the rectangle using that. This is a lot better
and more friendly than applying various crazy constants in the GetState
for the base/range.
It substantially complicates the code and doesn't really provide any
functionality. According to the forums, the Android app is out of date
and has been broken for quite a while.
If we want to add this back, I'd write an app that speaks a more native
Wiimote protocol, and we can hook that up to the backend quite easily.
It could even be over our NetPlay protocol!
Lioncash