| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
This also better handles in-memory interlaced XFB data placed by the CPU
by considering the stride from the VI.
|
|
Since the copy X and Y coordinates/sizes are 10-bit, the game can configure a
copy region up to 1024x1024. Hardware tests have found that the number of bytes
written does not depend on the configured stride, instead it is based on the
size registers, writing beyond the length of a single row. The data written
for the pixels which lie outside the EFB bounds does not wrap around instead
returning different colors based on the pixel format of the EFB.
This suggests it's not based on coordinates, but instead on memory addresses.
The effect of a within-bounds size but out-of-bounds offset
(e.g. offset 320,0, size 640,480) are the same.
As it would be difficult to emulate the exact behavior of out-of-bounds reads,
instead of writing the junk data, we don't write anything to RAM at all for
over-sized copies, and clamp to the EFB borders for over-offset copies.
|
|
|
|
|
|
|
|
Also makes y_scale a dynamic parameter for EFB copies, as it doesn't
make sense to keep it as part of the uid, otherwise we're generating
redundant shaders.
|
|
|
|
|
|
swap32 has an overload that accepts a u8*, performing the same behavior
in a well-defined manner.
|
|
|
|
|
|
Tested on a linux Intel Skylake integrated graphics with
blend_func_extended force-disabled, as it's the only platform I have
that doesn't crash with ubershaders and supports fb_fetch
|
|
|
|
size. This saves on a number of multiplications and fixes an issue where we were multiplying the y-scaling factor by the srcRectangle's height + 1 which was causing a crash in some GC titles
|
|
|
|
VI stride does not match the VI width
|
|
|
|
|
|
|
|
display of PAL games that run in 50hz mode.
|
|
|
|
|
|
These are now incorporated into the blend state for all backends.
|
|
|
|
|
|
|
|
This is a remake of https://github.com/dolphin-emu/dolphin/pull/3749
Full credit goes to phire.
Old message:
"If none of the texture registers have changed and TMEM hasn't been invalidated or changed in other ways, we can blindly reuse the old texture cache entries without rehashing.
Not only does this fix the bloom effect in Spyro: A Hero's Tail (The game abused texture cache) but it will also provide speedups for other games which use the same texture over multiple draw calls, especially when safe texture cache is in use."
Changed the pr per phire's instructions to only return the current texture(s) if none of the texture registers were changed. If any texture register was changed, fall back to the default hashing and rebuilding textures from memory.
|
|
It was a no-op on all backends apart from GL anyhow.
|
|
VideoBackends: Set the maximum range when the depth range is oversized.
|
|
|
|
|
|
|
|
|
|
We have TOO many video backends.
|
|
|
|
|
|
Visual Studio's code analyzer complains about these.
|
|
|
|
|
|
This is only ever queried, making it a global isn't necessary.
|
|
Also remedies places where the video backends and core rely on things
being indirectly included.
|
|
|
|
|
|
It was only implemented in OpenGL, though the option was visible in both
backends, leading to memory leaks if you enabled it in DirectX.
And it wasn't particularly useful as a debug feature as it only showed
where in the EFB the copies were taken from, not what format it was, or
what the copy was used for, or what content was in the EFB at that point
in time.
Also, it stretched the copy regions relative to the window, so the
on-screen regions don't even line up with the window unless the game used
the full EFB (some pal games) and you game image stretched to the full
window.
|
|
|
|
|
|
Texture updates have been moved into TextureCache, while
TMEM updates where moved into bpmem. Code for handling
efb2ram updates was added to TextureCache.
There was a bug for preloaded RGBA8 textures, it only copied
half the texture. The TODO was wrong too.
|
|
|
