The active challenges, aka the primed achievements, are displayed on screen as a series of icons in the bottom right corner of the screen via OnScreenUI.
This worked correctly on the JIT vertex loaders, and for the equivalent case with texture coordinates. I'm not aware of any games this affects (but libogc does mention a semi-related scenario at 6bc0317c7d/gc/ogc/gx.h (L1855-L1857).)
Jimmie Johnson's Anything with an Engine is known to use texture coordinate 7 (and only texture coordinate 7) in some cases. There are a lot of possible edge-cases, so this test brute-forces all combinations with coordinates 0, 1, and 2.
This is used as a base pointer inside CustomPipelineAction, so this
should probably really have a virtual destructor to ensure derived
objects are torn down properly.
This caused us to update the indirect texture information in shaders more often than we needed to, which probably doesn't matter in practice since it's only used in ubershaders and copyyscale and stride are generally only updated before EFB/XFB copies, which generally will have other changes afterwards.
As far as I can tell, it has nothing to do with the mipmap/half_scale functionality, but does change based on the width of the destination texture (and the destination texture is half the width if half_scale is set). The comment that was there (which dates back to the initial megacommit) seems to not have accounted for the width aspect; it was first used as an actual stride in bbbe898839467c312c31456334540c20fedc7be3 (the first commit that used it at all).
At the end of each frame automatically update the Current Value for
visible table rows in the selected and visible CheatSearchWidget (if
any). Also update all Current Values in all CheatSearchWidgets when the
State changes to Paused.
Only updating visible table rows serves to minimize the performance cost
of this feature. If the user scrolls to an un-updated cell it will
promptly be updated by either the next VIEndFieldEvent or the State
transitioning to Paused.
This is needed so that the checks added in the previous commit will be
reevaluated if the value of m_enable_dcache changes.
JitArm64 was already recompiling its asm routines on cache clear by
necessity. It doesn't have the same setup as Jit64 where the asm
routines are in a separate region, so clearing the JitArm64 cache
results in the asm routines being cleared too.
When the inverted depth range is unsupported and zRange is greater than farZ then min_depth becomes a negative value and far_depth will then exceed a depth of 1.0 (which is outside the scope of most backends and greater than GX_MAX_DEPTH of the console).
This happens when the backend supports depth clamping the min_depth is not clamped to zero.
