On D3D, we read from the depth buffer using the format
DXGI_FORMAT_R24_UNORM_X8_TYPELESS (essentially, the "r" component contains
the depth, and the other components contain nothing).
Make sure we don't have a texture bound as both an ShaderResourceView and
a RenderTargetView; this causes rendering glitches.
This isn't really the right place to do this... but I'm not sure
how the code should be structured.
Well, that's not strictly true, but trying to memcpy between two buffers
using different row lengths and different strides is at minimum extremely
unintuitive.
Intellisense doesn't like defines in PCH files, and it doesn't like the deleted
constructor for BitField. (I think it's being overly strict about the
"must have no non-default constructors" rule for classes in unions.)
The result might be a little iffy in complicated situations (i.e. you have
three graphics cards and monitors hooked up to two of them), but we really
need better UI for such cases anyway.
The key change is that for stores less than 5 bytes, the correct
place for the trampoline to return is immediately after the backpatched jump,
not somewhere inside it.
When we try to JIT from a block which doesn't exist, don't JIT any code;
just update the PPC state to indicate an ISI. This is a little simpler,
and avoids abusing the JIT block cache.
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.
magumagu