Now works with games that deliberately avoid invalidating TMEM because
they know textures are too large to fit:
* Sonic Riders
* Metal Arms: Glitch in the System
* Godzilla: Destroy All Monsters Melee
* NHL Slapshot
* Tak and the Power of Juju
* Night at the Museum: Battle of the Smithsonian
* 428: Fūsa Sareta Shibuya de
There are two reasons for this.
1. Using Dolphin's logging system lets the user decide whether
the printout should go to the terminal, the GUI, or a file.
fmt::print always prints to stdout... unless you're on Android, in
which case it does nothing at all, because Android disables stdout.
2. The Windows version of Dolphin crashes when you use fmt::print.
Yes, really. The crash happens because a call to std::fprint in
fmt::v7::detail::fwrite_fully returns that less characters were
written than requested, which fmt handles by throwing an exception.
(As always, Dolphin does not use exception handling.)
I'm not sure why std::fprint is doing this, but since switching
away from using fmt::print is a good idea due to the previous point
anyway, I'd say it's best to just switch.
Previously, if you have "Hotkeys Require Window Focus" disabled, you could repeatedly use the "Open" hotkey, for example, to stack File Open windows over top of each other over and over.
This commit allows the hotkey manager to disable/enable on QFileDialog creation and destruction.
Currently the logic for addressing the individual TexUnits is splattered all
across dolphin's codebase, this commit attempts to consolidate it all into a
single place and formalise it using our new TexUnitAddress struct.
MappingWindow is modal, yet the user can use hotkeys while the window is active. I believe hotkeys should not be recognized while this window is active.
This string is extremely likely to be mistranslated without the
proper context. Actually, it's probably impossible to translate
this string in a good way to some languages, but I'm not sure how
to solve that. Let's at least add an i18 comment for now.
PR #10066 added functionality to call std::abort when a panic alert occurs; however, that PR only implemented it for MsgAlert and not MsgAlertFmtImpl, meaning that the functionality was not used with PanicAlertFmt (only PanicAlert, which is not used frequently).
Yes, that's right! It's time to add even more NKit warnings,
because users still don't understand what NKit is or how it works!
More specifically, some users seem to be under the impression that
converting an NKit file to for instance RVZ using Dolphin's convert
feature will result in a normal RVZ file, when it in fact results in
an NKit RVZ file (since NKit is not a container format in the sense
that GCZ/WIA/RVZ/WBFS/CISO is, but rather a kind of trimmed ISO).
I can hardly blame users for not knowing this, because it's not
intuitive unless you know the technical details of how NKit works.
Previously, s_temp_input was being used for BOTH the savestate's and the movie's input printout in the panic alert.
This commit simply performs memcpy from the correct vector for the movInput printout.
Previously, the file dialog window was ambiguous between saving or loading a .dtm. This commit simply gives a bit more context to differentiate the two windows.