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 2e5e724f94. By actually indicating that we're PAL on homebrew boot, the rest just falls into place.
NTSC GameCubes have no Language setting, so the language byte in SRAM is always 0. Some NTSC games do react oddly and display unfinished translations and similar when the byte is set to a nonzero value that corresponds to a non-English language on a PAL GameCube. See issue 7731: https://code.google.com/p/dolphin-emu/issues/detail?id=7731.
NaNs always propagate, so we can get away with only checking for NaN
inputs in the rare case that the result is NaN (as already done in
Jit64::HandleNaNs()).
Fixes block dots in THP videos.
Nintendo's THP video uses paired U8 stores to write their THP videos after decoding with floating point operations.
Paired stores clamp the range to the minimum and maximum values(0 - 255 in this case).
In some instances the resulting float will be larger than what a U8 can fit(Typically white) and results in black dots due to how AArch64 handles
quantizing.
The new implementation has 3 options:
SyncGpuMaxDistance
SyncGpuMinDistance
SyncGpuOverclock
The MaxDistance controlls how many CPU cycles the CPU is allowed to be in front
of the GPU. Too low values will slow down extremly, too high values are as
unsynchronized and half of the games will crash.
The -MinDistance (negative) set how many cycles the GPU is allowed to be in
front of the CPU. As we are used to emulate an infinitiv fast GPU, this may be
set to any high (negative) number.
The last parameter is to hack a faster (>1.0) or slower(<1.0) GPU. As we don't
emulate GPU timing very well (eg skip the timings of the pixel stage completely),
an overclock factor of ~0.5 is often much more accurate than 1.0
Should fix Issue 8209: Emulated Wiimote tilt is incorrect since 4.0-4543.
Original changes can be looked at the link below and discussion about the issue can be followed within Issue 8209 at googlecode.
http://pastebin.com/yKA2nuGp
Thanks to hk.konpie for the fix.
When AccurateNaNs is enabled, NaNs are handled accurately by checking
for NaN results and choosing the correct input NaN or replacing x86's
generated -QNaN with +QNaN.
