A number of games make an EFB copy in I4/I8 format, then use it as a
texture in C4/C8 format. Detect when this happens, and decode the copy on
the GPU using the specified palette.
This has a few advantages: it allows using EFB2Tex for a few more games,
it, it preserves the resolution of scaled EFB copies, and it's probably a
bit faster.
D3D only at the moment, but porting to OpenGL should be straightforward..
The obvious question here is, why does it matter if we round or truncate?
The key is that GC/Wii does fixed-point interpolation, where PC GPUs do
floating-point interpolation. Discarding fractional bits makes the conversion
from floating-point to fixed point give more consistent results.
I'm not confident this is really the right fix, or that my explanation is
completely correct; ideally, we don't want to depend on floating-point
interpolation at all.
We do a whole bunch of non-threadsafe stuff, especially in the UI, and I'm
probably not going to get around to implementing a threadsafe framework
for interaction between the UI and the CPU thread anytime soon. See issue
8220.
The PowerPC CPU has bits in MSR (DR and IR) which control whether
addresses are translated. We should respect these instead of mixing
physical addresses and translated addresses into the same address space.
This is mostly mass-renaming calls to memory accesses APIs from places
which expect address translation to use a different version from those
which do not expect address translation.
This does very little on its own, but it's the first step to a correct BAT
implementation.
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).
We don't need to profile explicit calls to CheckGatherPipe: we aleady know
where they are. Skip profiling, and explciitly insert an exception check.
While I'm here, get rid of unused code in JitIL.
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.
magumagu