Moves render target restoring to RestoreAPIState, this also means no need
to manually restore after allocating in a buffer that caused execution,
because the manager restores it for us.
Remove a method that wasn't used from D3DUtil.cpp, and fixes a few errors
in EFB poke drawing.
This is not optimal, but for those texture packs with extremely large
images, it won't crash. Releasing after the frame completes is an option
too, however, there is the risk of running out of memory by doing this.
I have no clue what this special case shall be, but accessing g_main_cp_state within Flush() is not allowed.
We likely still have a bad behavior, but now it only depends on the current state, not on the next one after flushing.
The D3D backend was always forcing Anisotropic filtering when that is enabled regardless of how the game chose to configure the texture filtering registers; this causes the same issues as "Force Filtering" without Anisotropy, such as causing game UI elements to no longer line up adjacent correctly. Historically, OpenGL's Anisotropy support has always worked "better" than D3D's due to seeming to not have this problem; unfortunately, OpenGL's Anisotropy specification only gives GL_LINEAR based filtering modes defined behavior, with only the mipmap setting being required to be considered. Some OpenGL implementations were implicitly disabling Anisotropy when the min/mag filters were set to GL_NEAREST, but this behavior is not required by the spec so cannot be relied on.
- remove an outdated comment about the efb to ram and scaled efb restriction
- when upscaling efb copies, mark the new texture as efb copy
- dx12 fixes for the src box, especially the number of layers for 3D
This applies to callers that do not have full knowledge of the command
list state, and thus, cannot restore it should allocations cause command
list execution. Instead we reallocate a new buffer. Should not happen
often enough for this to be a concern, as it's mainly for the utility
classes.
Using CreateThread can create issues if any CRT calls are made, as
thread-specific data may not be initialized. Additionally, TerminateThread
is not a good idea for similar reasons, and may not free CRT resources.
Stenzek