Forcing people to use hacks is a bad idea in general, and there are
two practical problems with doing it for immediate XFB in particular:
1. It breaks the GC IPL, which some users run when launching games.
2. Competitive players don't necessarily want the lowest possible
latency - they might want the latency that's the closest to console,
so if they're playing locally with a low-latency monitor, they might
not want to use immediate XFB. (This isn't a theoretical concern -
I've seen Melee players want to increase their latency.)
Besides, it feels arbitrary that just these five specific games should
have immediate XFB forced on.
7f0834c9 moved the locations of the Real XFB (now XFB to RAM) and
Disabled XFB (now Immediate Mode) settings. There are programs
other than Dolphin that parse DTM headers, so this is not good.
Note that Immediate XFB actually is the inversion of Disabled XFB.
I hope that's not too much of a problem...
No code is relying on this unexplained null byte check, since
the only code that calls UTF16ToUTF8 on non-Windows systems
is UTF16BEToUTF8, which explicitly strips null bytes.
We shouldn't try to create folder names that contain characters
such as : or / since they are forbidden or have special meanings.
(No officially released disc uses such characters, though.)
The main problem was that the volume of the mixer wasn't savestated.
The volume is typically 0 at the beginning of a game, so loading a
savestate at the beginning of a game would lead to silent DTK audio.
I also added savestating to StreamADPCM.cpp.
Nowadays that Dolphin detects regions of discs properly and doesn't
force programs with unknown regions (such as homebrew) into running
under a certain region, the "Force Console as NTSC-J" option is
practically useless for making anything run correctly. Enabling it
is however an easy way to totally break many non-Japanese games.
The earlier code always tried to use TitleDatabase for getting
title names, but that didn't work for disc-based games, because
there was no way to get the maker ID.
Some lines of code in Dolphin just plainly grabbed the value of
g_ActiveConfig.iEFBScale, which resulted in Auto being treated as
0x rather than the actual automatically selected scale.
This reverts commit 1fc910b3ea,
replacing the old INI setting EFBScale with a new INI setting
called InternalResolution, which has a simpler mapping:
| EFBScale | InternalResolution
----------------- | -------------------- | --------------------
Auto (fractional) | 0 |
Auto (integral) | 1 | 0
1x | 2 | 1
1.5x | 3 |
2x | 4 | 2
2.5x | 5 |
3x | 6 | 3
4x | 7 | 4
5x | 8 | 5
6x | 9 | 6
All the fractional IRs were removed in f090a943.
"N/A" can be awkward to handle in translations.
I don't think there's much point in showing "N/A" rather than
leaving the description box blank, so let's just leave it blank.
This apparently fixes https://bugs.dolphin-emu.org/issues/10499 somehow.
The first changed line of this commit is just for performance - the
second changed line is where the difference in behavior is.
The class NonCopyable is, like the name says, supposed to disallow
copying. But should it allow moving?
For a long time, NonCopyable used to not allow moving. (It declared
a deleted copy constructor and assigment operator without declaring
a move constructor and assignment operator, making the compiler
implicitly delete the move constructor and assignment operator.)
That's fine if the classes that inherit from NonCopyable don't need
to be movable or if writing the move constructor and assignment
operator by hand is fine, but that's not the case for all classes,
as I discovered when I was working on the DirectoryBlob PR.
Because of that, I decided to make NonCopyable movable in c7602cc,
allowing me to use NonCopyable in DirectoryBlob.h. That was however
an unfortunate decision, because some of the classes that inherit
from NonCopyable have incorrect behavior when moved by default-
generated move constructors and assignment operators, and do not
explicitly delete the move constructors and assignment operators,
relying on NonCopyable being non-movable.
So what can we do about this? There are four solutions that I can
think of:
1. Make NonCopyable non-movable and tell DirectoryBlob to suck it.
2. Keep allowing moving NonCopyable, and expect that classes that
don't support moving will delete the move constructor and
assignment operator manually. Not only is this inconsistent
(having classes disallow copying one way and disallow moving
another way), but deleting the move constructor and assignment
operator manually is too easy to forget compared to how tricky
the resulting problems are.
3. Have one "MovableNonCopyable" and one "NonMovableNonCopyable".
It works, but it feels rather silly...
4. Don't have a NonCopyable class at all. Considering that deleting
the copy constructor and assignment operator only takes two lines
of code, I don't see much of a reason to keep NonCopyable. I
suppose that there was more of a point in having NonCopyable back
in the pre-C++11 days, when it wasn't possible to use "= delete".
I decided to go with the fourth one (like the commit title says).
The implementation of the commit is fairly straight-forward, though
I would like to point out that I skipped adding "= delete" lines
for classes whose only reason for being uncopyable is that they
contain uncopyable classes like File::IOFile and std::unique_ptr,
because the compiler makes such classes uncopyable automatically.
I'm not sure why this hasn't popped up as an error on the buildbots,
but the build fails on my new install of VS2017. The error is C2445:
result type of conditional expression is ambiguous: types 'wxString'
and 'const char [1]' can be converted to multiple common types
"Pad size" just doesn't make much sense. Let's go with "Buffer size"
instead, since the control for it is labeled "Buffer".
(Another possibility is "Pad buffer size", but I'm against that,
because we've stopped referring to controllers as "pads" in almost
all GUI strings.)
Sentret_C posted this comment on Transifex recently:
"What Dolphin refers to as "Table View" and "List View" are
similar to "List View" and "Grid View" in Steam, and I think
the Steam names describe them better."
I agree with that, so here's a commit that changes the names.
There were two problems with this:
1. If the starting offset was beyond the end of the disc,
we would dereference an invalid iterator.
2. The data beyond the end of the disc was non-deterministic.
Having DiscContents with size 0 would mean that some DiscContents
might not get added to the std::set because of them comparing
identically to another DiscContent.
This replaces an older piece of code in WriteDirectory that ensures
that no two files have the same starting offset. (We now care about
the ending offset, not the starting offset. The new solution both
ensures that no two files have the same ending offset and that no
two files have the same starting offset.)
JosJuice