We can't use RendererHasFocus for this purpose because of some issues
with exclusive fullscreen, and the new RendererHasFocus implementation
didn't work for non-Render to Main Window cases, since the renderer
window wasn't managed by wx.
This reverts commit ff918df889.
This changed it from "RendererHasFocus" to "UIHasFocus", which is
wrong. Specifically, it broke for non-Render to Main Window cases where
the renderer window isn't managed by wx. It also broke the pending
exclusive fullscreen support, which checks this function to determine if
the renderer is on top so it can full-screen it.
We'll add a new hook, "UIHasFocus", in the next commit.
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.
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!
Pad mapping and the UI behind it is significantly confusing,
and has been confusing users since NetPlay was introduced.
As part of a large code cleanup to help NetPlay more stable,
introduce a better pad mapping system where local pad mapping
is handled by the client. Now, all the server and other
clients know is which player have which controllers, and the
clients only know this so they can show the pad mapping in the
UI; they don't do anything else with it.
A future cleanup will use this pad mapping data to completely
ignore the pads configured in the settings pane on the host.
This can happen if the user does not have an up to date version of
the DirectX SDK, as Microsoft intentionally broke it and requires
users to install the W8 SDK.
If we don't do this, then when the game starts we'll send out the
buffer size to clients being a super large value of junk, and they'll
hang forever trying to accumulate an input buffer a size that they'll
never ever reach in a million years.
This never manifested in release builds for some reason.
Add a simple Python script that does a basic normalization on
the game INI files and run it across all the files we have. This
normalizes the sections, their order and comments, and the whitespace
within them.
It also removes the sections Video_Hardware, Gecko, and Wii, which
should not be in the game INI files we ship by default.
The MS INI parser and most other INI parsing libraries APIs only support
comments at the beginning of lines. Right now, some Game INI files use sections
like:
[OnFrame]#Add memory patches here
But these section headers are parsed separately, so this should not break
them.
This would allow a new socket to be created with the same port after
we close it. However, we can't reuse it immediately because of the TCP
TIME-WAIT state.
This should be transparent, but it may cause regressions.
The idea here is that now all players, including the host of the server,
talk to the server through TCP/IP networking. This significantly reduces
our codepaths through netplay, and will prevent strange local-only bugs
from happening.
The cleanup isn't 100% finished yet. The NetPlay dialog still drives the
server through private APIs. I eventually want to sanction off the server
entirely, so all communication is done through TCP/IP. This will allow us
to have high-traffic public servers that can relay multiple games and
lobbies at a time, and split off channel and game management to people
other than the host.
This is all still just a pipe dream, though.
Without clearing out the "accumulator" for the backtick parsing,
our control name was full of junk (the previous device name) causing
us to not correctly find the control.
Ensure that always we clear the "accumulator" string during backtick
parsing.
Jasper St. Pierre