Add internationalization support. There aren’t really any translations yet other than a little French thanks to DavidVag. So now the translators need to go to work. See http://wiki.wxwidgets.org/Internationalization for directions. The binary .mo files are generated at build time on linux. They are provided in Data/Languages for windows. I don’t know where they need to go on OSX, but they should be able to be generated there at least. I added a target to generate them on windows, but does not build by default as it requires that msgfmt.exe from the gnu gettext tools be installed and in the path.
Changed order of operations in Profiler.cpp to calculate non-zero values for ‘cost’. Integer division was too early. Credit to my brother, Joe, for figuring this one out.
Fixed Linux build.
Fixed small undiscovered bug in WII_IPC_HLE_Device_FileIO.cpp when looking at 0-length strings.
Fixed S3TC DXT1 decoder implementation. I see ~40% speed improvements running on x86 Intel hardware and 0% improvements running on x64 AMD hardware. Strange. More investigation to follow!
After removing the input queueing in IOdarwin.mm I was still seeing
the occasional HLE wiimote disconnection, although nowhere it was at
near the level before both the recent wiiuse integration and adding
the queue in the first place.
The callback-based bluetooth input method on OS X really requires
that packets be accepted immediately and the 1ms polling done by the
wiimote worker threads isn’t quite good enough.
So just play along with the native OS X model and send the packet up
our stack directly from the callback. With our current API, this is
kind of a layering violation, but it seems less messy than either
putting back internal queueing in IOdarwin.mm or adding the platform
support for higher-frequency polling than what usleep(3) offers.
Perhaps we should just change our own API to a callback model. While
this makes no real difference right now, it would make it a fair bit
cleaner to accept new wiimotes at any time instead of having to click
Refresh, although with the recent realmote changes, that feature can
probably just be hacked in by looping around FindWiimotes().
For other platforms having problems with HLE disconnections caused by
dropped bluetooth packets, as a first stop I would suggest trying to
do more than just one wiimote->Read() per iteration in the thread.
This change also conveniently sidesteps another new IOdarwin.mm bug
where the discovery and I/O code would clash during a refresh because
they use the same default CFRunLoop, so if we switch back to using a
run loop for I/O, must remember to create a separate one.