On the first boot of Pokemon Snap it copies a 144KB file to the Wii's
NAND, but it only copies 32 bytes per IPC write call.
This was causing dolphin to open and close the same file over 4000
times. This wouldn't usually be a huge issue, except some operating
systems (namely Windows) allow 3rd party programs (namely antivirus
software) to hook all accesses to the filesystem.
This causes the antivirus software to scan the same file for viruses
4000+ times, which is kind of slow.
This fix reduces the initial boot time of pokemon snap from 3+ min
to just a few seconds. Could also improve other games which write
things to NAND.
Will break a few things, see the next commit for an improved fix.
LIBAV_LDFLAGS has -L, LIBAV_LIBRARIES is just the names of the
I think this is not necessary for other dependencies because they
consist of a single library and go through a different path (check_lib)
that provides the full path to it. e.g. from my CMakeCache.txt:
ICONV_LIBRARIES:FILEPATH=/usr/lib/libiconv.dylib (good)
LIBAV_LIBRARIES:INTERNAL=avcodec;avformat;swscale;avutil (bad)
Previously, MacOpenFile only overrode anything on OS X; otherwise it was
just a useless method, which is presumably why it wasn't marked override
in the first place. Address this more sanely by wrapping it in #ifdef
__APPLE__.
...by telling CMake to use -isystem for the static wx include directory.
AFAICT, this is already done by CMake's FindwxWidgets script in the
shared case.
In particular this fixes the 6666 colour format
We were loading from the wrong location and it was causing /terrible/ colour changes.
This also fixes a bug in the all the colour formats(except 888) where the unaligned path was loading in to the wrong register.
This is a bit indirect, but since homebrew always boots in a European environment the framerate depends on the bPAL60 flag, which is always auto turned off if bNTSC is set to true as of 2e5e724f9401cb3dea28981a93b7467854f98dbb. By actually indicating that we're PAL on homebrew boot, the rest just falls into place.
Games without banners were not cached before, because a banner could
become available at any time, making the cache outdated without it
becoming invalidated. Instead of not caching anything, this change makes
Dolphin check for a banner every time a cache that lacks a banner is read.
This is faster than reading all metadata, because reading a Wii banner
only reads from the game's save file, not the volume and its filesystem.
The cache revision is incremented, because otherwise banners will be
missing if a cache without a banner is created in the new version and
the user switches to an old version and creates a savefile.
