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.
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.
A few StreamBuffer instances take arguments that are actually size_t,
and this will cause truncation warnings during argument forwarding
with make_unique.
We already bail out if the shader compilation fails.
Also, there would have already been a nullptr dereference in
InsertByteCode prior to reaching this point.
Stenzek