Use strings internally, use a multimap and std::function for callbacks (instead
of a flat vector + loop over the vector to find the right callback type), fix
coding style issues. Simplify MainAndroid code a bit.
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.
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.
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.
Feedback is in logs as suggested by skid_au. The checkbox is still there, but
mostly for people who would like to opt out (unfortunately, I can not be sure
how this feature may behave for some routers - there's a hell of a lot of bad
UPnP implementations.)
The Visual Studio stuff is a little messy, so I apologize if anything is a bit
off. I tested most configurations and it worked.
I also tested CMake on Debian Wheezy, Ubuntu Saucy, and Mac OS X Mountain Lion.
All seemed to be OK.
Also keep a PNG version of bin2c'd resources in order to make these kind of
changes easier in the future.
Fixes recent versions of libpng complaining loudly about our images.