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.
In a particular hashing heavy scene in Crazy Taxi the Murmur3 hash used 3.11% CPU time.
The new CRC32 hash in the same scene used 1.86%
This was tested on a Nvidia SHIELD Android TV with Cortex-A57s.
This will be a bit slower on the Nexus 9, the Denver CPU core is a bit slower with CRC32 texture hashing than Murmur3 texture hashing.
- Refactored Light Attenuation into inline function in Software Renderer
- Corrected zero length light direction vector to resolve with normal direction (essentially becomes LIGHTDIF_NONE which was what I was after)
- Change the API of this shared function to use points for output variables (degasus)
- Fixes remaining lighting issues (Mario Tennis, etc)
- Apply same fixes to Software Renderer
- Corrected zero length light direction vector to resolve with normal direction (essentially becomes LIGHTDIF_NONE which was what I was after)
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.
