Even in games that require MMU mode, loads outside the area specified by
the BAT are rare, so fastmem is a substantial improvement.
All of the interesting changes are in the backpatch handler, to make it
generate DSI exceptions correctly.
I'm planning on making changes to the memory code, so I don't want this
stuff to get in the way. The slight performance hit to JITIL isn't really
important at the moment.
The code actually handles this case correctly; the algorithm is linear
interpolation between the two closest samples, and the way it is written
should work correctly with any ratio.
The primary motivation here is to make sure we submit samples from the
CPU thread. This makes sure the timing of related interrupts accurate,
and generally keeps the different kinds of audio synchronized. This will also
allow improvements to audio dumping functionality.
The new code is also more concise because it gets rid of some duplicated
audio mixing code.
This change attempts to make calls to WII_IPC_HLE_Interface::Update()
more consistent. We should be calling it whenever there is something we
can pop from a queue, and this patch does that.
DeviceUpdate() now works independently of Update(): it's now just a periodic
timer for devices which need to regularly update state.
With this change, we need a non-zero default delay for IPC replies because
replies are popped off the queue much more aggressively.
This fixes launching channels from the the System Menu.
This reverts commit 4990b8910b.
The commit is causing substantial performance issues for the DSound
backend which I somehow didn't catch during testing.
Unfortunately, this appears to be necessary for the sake of performance;
the standard library equivalents don't work well enough on Visual Studio
2013. vector<bool>::insert() is way too slow in debug
builds to be usable, and std::bitset generates inefficient code in release
builds.
It doesn't really matter much at the moment given our current terrible MMU
emulation, but it will start mattering once our MMU emulation gets more
accurate.
The existing implementations produce answers which aren't consistent with
the hardware, and games care about correct floating point math.
These can be reimplemented at some point in the future, if someone cares
enough, but the general case is probably too much code to inline.
(I'm leaving the ARM implementations in place by request, even though they
suffer the same issues.)
For whatever reason, the hardware doesn't do a full divide by 255, but
instead uses an approximation with shifting, similar to the way it is done
in TEV.
Based on real measurements of a Gamecube disk on a Wii. (If anyone else
is interested in running more tests, I can upload my code; it's a mess at
the moment.)
This isn't a complete model, but it's a step in the right direction:
in Metroid Prime, the loading times are sane, and I think I managed to do it
without breaking anything.
Having a bunch of nearly identical code sitting around isn't a good idea,
so fix that. JITIL had a couple of extra entry points into the JIT main
loop, so adjust the code appropriately.
Also fixes Issue 7186.
The alert apparently triggers on Midway Arcade Treasures 2; given that the
game otherwise works fine, it's not a high priority to accurately emulate
the bit in question.
Fixes issue 7197.
We need to explicitly round when converting colors from float to uint
because multiplying a normalized float by 255 might not result in a whole
number. (The exact result here may vary depending on your
drivers/hardware.)
Ideally, we shouldn't be using floating point here, but fixing that is a
much more complicated patch.
Fixes gxtest TEV tests using Intel HD 4000.
CreateInputLayout requires a shader as an input, but it only cares about
the signature; we don't need to recompute it for different shaders with
the same inputs.
Pretty straightforward; IDirectSoundNotify lets you register for
notifications after a certain amount of sound has played, so use that
instead of depending on Update() notifications from the CPU thread.
Also, while I'm here, reduce the buffer size by a factor of 4; this seems
to reduce the latency, although the difference is sort of subtle.
Trying to use GetDepthMatrixProgram outside of
TCacheEntry::FromRenderTarget is a bad idea, so don't. Instead, use a
shader which only copies the input.
Fixes lens flare depth test in Twilight Princess. See
http://code.google.com/p/dolphin-emu/issues/detail?id=5999 .
This is good for a couple of reasons: one, it gets rid of duplicated code,
and two, DSP emulation shouldn't need to interact with audio in the first
place.
magumagu