summaryrefslogtreecommitdiff
path: root/Source/Core/Common/ArmCPUDetect.cpp
diff options
context:
space:
mode:
authorMartino Fontana <tinozzo123@gmail.com>2026-09-14 15:30:33 +0200
committerMartino Fontana <tinozzo123@gmail.com>2026-10-03 09:12:52 +0200
commit8c1f30bb3043bff6b7d204fc162395d1fcd817c5 (patch)
treefeb697763293b0c83c45b6cfbc69fe3d4c1731d0 /Source/Core/Common/ArmCPUDetect.cpp
parenta96b5da8562c387acb2f43a4133c45c8bdcecd1e (diff)
VideoCommon: Option for byte to memset in RAM when `EFBToTextureEnable = True`
The main use case is for games that in theory should be compatible with `EFBToTextureEnable = True`, as the CPU never reads the EFB texture and only writes to it completely. However, if what the CPU writes is only zeros, if the texture in RAM was already zeros then Dolphin wouldn't notice the change in RAM and thus wouldn't invalidate the texture in VRAM. This happens in Rhythm Heaven Fever, and with this change it doesn't require `EFBToTextureEnable = False` anymore. But there are other use cases, like setting a clear value that is closer to what the EFB copy would be, like in Excite Truck. (`EFBToTextureEnable` is still `False` by default.) Other games are more subjective (and not changed here): for instance Mario Kart Wii samples the EFB copy to decide whether to display a sun flare. Currently with `EFBToTextureEnable = True` (default) it will never be shown, but maybe someone would prefer for the flare to always be shown, even behind walls. The option currently only supports setting a single byte (that will be memset to the entire texture), as setting a color would be more complex given that a texture can be in multiple formats, and there is no use case (yet) for it.
Diffstat (limited to 'Source/Core/Common/ArmCPUDetect.cpp')
0 files changed, 0 insertions, 0 deletions