Special shoutout to Android for not having RTL compatible
variants of nextFocusRight and nextFocusLeft.
Ideally we would have some way to block the user from using
the d-pad to switch between the two panes when in portrait mode,
or make the list pane act as if it's to the left of the details
pane rather than the right when the details pane is open, but I
don't know of a good way to do this. SlidingPaneLayout doesn't
really seem to have been implemented with d-pad navigation in mind.
Thankfully, landscape is the most important use case for gamepads.
The way I'm implementing events using LiveData feels rather
unorthodox, but I'm not aware of anything in the Android framework
that would let me do it in a better way... One option I did
consider was wrapping the cheat lists in LiveData and observing
those, but then CheatsAdapter wouldn't know which cheat had
changed, only that there was some kind of change to the list,
necessitating the use of the not recommended notifyDataSetChanged.
When RenderDoc is attached, wglShareLists fails for some reason (see baldurk/renderdoc#2361). wglCreateContextAttribsARB has a parameter for the share context, so there's no reason to use a separate wglShareLists call.
Co-authored-by: baldurk <baldurk@baldurk.org>
Previous code from #7950 only clamps correctly when the efb copies
left and top coordinates are (0, 0)
Now we should handle all situations.
Spyro: A hero's tail is an example of a game that does an oversized
EFB copy with a non-zero origin.
If W0 is locked when fpr.RW is called, the indirectly called
ConvertSingleToDoubleLower may need to emit a push+pop, so it's
better for fresx/frsqrtex to call RW before locking W0 than after.
This adjusts the NaN replacement logic introduced in #9928 to work around the HLSL compiler optimizing away calls to isnan, which caused that functionality to not work with ubershaders on D3D11 and D3D12 (it did work with specialized shaders, despite a warning being logged for both; that warning is also now gone). Note that the `D3DCOMPILE_IEEE_STRICTNESS` flag did not solve this issue, despite the warning suggesting that it might.
Suggested by @kayru and @jamiehayes.
This is a proper fix for the issue that 3071a1d was a workaround for.
It wasn't some kind of bug in the register cache that had laid dormant,
it was a simple mistake made in b24b79e.
