Otherwise we might get UB if the value we cast is larger than the
max value of the underlying type that the compiled picked for the enum.
I haven't done any extensive check through Dolphin to find cases
of this, I'm just fixing the cases I already know of.
The advantage of std::list is that elements can be removed from the
middle efficiently, but we don't actually need that, because the
ordering of the elements doesn't matter for us. We can just replace the
element we want to remove with the last element and then call pop_back.
Replacing list with vector should speed up looping through the elements.
GameTracker's usage of GameFileCache is thread-safe even without
using a mutex. All of its access to GameFileCache happens on the
thread m_load_thread, except for the call to GameFileCache::Load,
which finishes before m_load_thread starts executing.
Starting with 5.0-5504, trying to launch DolphinQt2 from Visual Studio
shows the error message "The operation could not be completed. Undefined
error" instead of launching the exe file. (The exe gets created
correctly, it just doesn't get launched. It's possible to work around
the problem by launching the exe manually outside of Visual Studio, but
then you won't have an attached debugger automatically.) This commit
fixes that by removing headers from DolphinQt2.vcxproj's ClInclude list
that already are in the QtMoc list. (The problem was originally about
LogWidget.h and LogConfigWidget.h, but 5.0-5600 made the problem be
about CheatWarningWidget.h and GeckoCodeWidget.h instead.)
Note: By "HandleInit" in this commit message, I mean the code that is
in HandleInit in master except the part that launches EmulationActivity.
In other words, I mean the call to SetUserDirectory and the call to
DirectoryInitializationService.startService. Couldn't think of
something more accurate to call that than "HandleInit"...
In master, HandleInit only runs when the main activity is launched.
This is a problem if the app ends up being launched in some other way,
such as resuming EmulationActivity after the app has been killed in
order to reclaim memory. It's important that we run HandleInit, because
otherwise the native code won't know where the User and Sys folders are.
In order to implement this, I'm dropping the ability to set a custom
User folder in an intent. I don't think anyone is using that anyway.
It's not impossible to support it, but I can't see a way to support
it that doesn't involve something ugly like having code for calling
HandleInit in every activity (or at least MainActivity + TvMainActivity
+ EmulationActivity, with more activities potentially needing it in
the future if we expand the usage of native code for e.g. settings).
If we want to support setting a custom user directory, we should
consider another way to do it, such as a setting that's stored in
getFilesDir() or getExternalStorageDirectory(). Intents are intended
to control the behavior of a specific activity, not the whole app.
There are two reasons for this change:
1. It removes many repetitive lines of code.
2. I think it's a good idea to enable the use of old-style section
names even for settings that previously haven't been settable in game
INIs. Mixing the two styles in INIs (using the new style only for new
settings) is not ideal, and people on the forums don't even seem to
know that the new style exists (nobody knew a way to set ubershader
settings per game, for instance). Encouraging everyone to start using
only the new style might work long-term, but it would take take time
and effort to make everyone get used to it. Considering that this commit
*reduces* the amount of code by adding the ability to use old-style
names for more settings, I'd say that adding this ability is worth it.
Trying to force the XSI version by undefining _GNU_SOURCE can lead
to compilation errors on some systems because of headers expecting
that _GNU_SOURCE is defined.
This commit uses define checks to detect which version we have.
I tried making an overloaded function (int and const char*) instead,
but that led to a warning about one of the variants being unused.
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...
We need this because VS currently doesn't consider
std::is_trivially_copyable<typename
std::remove_volatile<SCPFifoStruct>::type>::value
to be true and because no compiler should consider it
to be true if we replace the volatiles with atomics.
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.
JosJuice