Start cleaning up the input interface #604
Conversation
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!
This doesn't have any functional changes, it just removes part of the mess by killing indentation.
Split out some math into a utility.
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 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.
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.
This makes it more clear and pretty much the analog stick code bog standard.
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.
This will allow us to move Background Input to a global setting rather than a local setting.
…ualization 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.
|
|
||
| if (use_accel) | ||
| if (use_accel) | ||
| { |
This comment was marked as off-topic.
This comment was marked as off-topic.
Sorry, something went wrong.
|
Looks good to me. |
|
Because GC adapters are mostly spotty, the fact that you cannot see the axises when background input is off is a huge deal. Needs to be fixed before I can thumbs up. Input still works, background input still works, just that appears to be a problem. Example: https://dl.dropboxusercontent.com/u/484730/cantsee.png |
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.
|
@dolphin-emu-bot rebuild |
|
So is everything fine with this, or no? |
|
@JMC47 said the last patch fixed all the issues. |
|
Cool, firing it into master then |
Start cleaning up the input interface
|
My Xbox 360 Wireless Joystick doesn't work anymore with this build |
|
How so, and why not? |
|
I don't know, in "Wiimote Emulation Settings" it works fine, but in game not. I downloaded a previous build and it works, |
|
Interesting. Are you sure that Background Input is checked, or the game window is focused? Do you have Render to Main Window enabled? What OS are you on? |
|
Background imput? game window is focused. |
|
Background Input is a checkbox in the input configuration window. Render to Main Window is somewhere in the graphics options. |
|
Render to main windows fix it, thank's you. |
|
Oh, I think I have an idea of what's going on with that then. I'll fix it when I get home from work today. |
|
Sorry, dolphin is trolling me, backgound imput fix it. |
|
If my idea is correct, then either of the two options will fix it, actually. |
|
Yes, background input solved the problem. Sorry for my english. |
|
After this change when im using classic controller my right analog stick is not responding correctly. None of above replies helps to fix it. So i cant use any new compilations with classic pad control... |
This removes a lot of the ugly details from HW / WiimoteEmu and punts them down lower in the stack. Eventually, long-term, I want to move away from the Background Input model entirely, since asking the display server every frame for new information is quite expensive. I'm quite sure we can come up with a new model that makes things work well for TASers, using only event delivery.