To match Microsoft's recommendations better, Dolphin now has 16x16,
32x32 and 48x48 bitmaps in both 8-bit and 32-bit, in addition to the
256x256 32-bit bitmap. There used to be an 8-bit 32x32 bitmap but no
32-bit 32x32 bitmap, which led to Windows using the ugly 8-bit bitmap
at some sizes.
I'm not entirely sure what is happening, but this optimisation is causing an issue in Sonic Riders: Zero Gravity. Apparently the issue would also be fixed by PR#3747, but this PR should also fix similar issues.
Games that use partial updates might get slower with this, so some performance regression testing would be nice. Games like New Super Mario Bros, RS2, Zelda TP and Silent Hill. Testing with high graphics settings makes sense, since this would mostly end up in more work for the GPU.
Previously the default queryed the controller 4500 times a second,
Wasn't really a problem for most games as they set it to a sane
value. But fifoplayer didn't, and so in my profile dolphin spends
12% of the cpu time reading the controllers.
This new default value (I just took what the gamecube bios set)
drops that to 1.2% of cpu time and increase the framerate of the
silent hill fifo by 10-12%
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.
Events scheduled more than 4.12 seconds in the future (2.96 seconds for
Wii games) would overflow the sign bit and get scheduled in the past
instead, causing them to fire instantly.
Previously GlobalTimer was only updated at the end of each slice
when CoreTiming::Advance() was called, so it could be upto 20,000
cycles off.
This was causing huge problems with games which made heavy use of
the time base register, such as OoT (virtual console) and Pokemon
puzzle.
I've also made it so event scheduling will be accurate to the jit
block level, instead of accurate to the slice.
instead, leave all the management with the NANDContentLoader.
for file data (directly on the NAND), this opens the file on-demand and
returns the requested chunk when asked for it.
for on-the-fly decrypted WAD data, we just keep the decoded buffer in
memory, like we've done before - except that we don't give away any objects
we don't want to.
this fixes the crashes, but leaves the "else" part of ES_READCONTENT
temporarily broken until the next commit.
WAD access that are performed on the encrypted WAD will most likely fail
with this commit.
only fixes half the issues, since we still cache a pointer from
SContentAccess.m_pContent to SNANDContent.m_data (which is free'd along
with the rest of the NAND data cached inside the CNANDContentManager when
ClearCache is called)
- 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
Our x86_64 recompilers don't support PIE and fail amazingly if enabled.
Disable it so package maintainers(!) or other randoms don't accidently enable it when we don't support it.
This isn't necessary, as the member functions are deleted.
If someone tries to perform a copy, the compiler will now
indicate that the member functions/constructors are deleted,
rather than inaccessible.
Pringo