Rather than rely on the developer to do the right thing,
just make the default behavior safely deallocate resources.
If shared semantics are ever needed in the future, the
constructor that takes a unique_ptr for shared_ptr can
be used.
The data passed in isn't modified in these functions
Also normalizes variables with prefixed underscores in the modified
functions (and normalizes outliers to our current coding style), as
single-underscore followed by any lowercased/uppercased character is
reserved for use in the global namespace (it's a common misconception this
is assumed to only be the case for underscores followed by a capital
character, but this is only the case in C, not C++).
It only marks a string for translation. It doesn't actually do anything
at runtime, so the message will always be displayed in English. Even if
we would've had a way to make the translation work, we shouldn't
translate this, because OSD doesn't support non-ASCII characters.
Caused by the recent merge 1c95cd5.
m_need_prepare needs to be set before the Device thread is started.
Otherwise the thread blocks on IORead and the LEDs and Rumble is executed
after the user presses a button on the Wiimote.
Also the Prepare-Call on Refresh doesn't need to reset the Index, because it is
set once on the initial Connect/Prepare. Therefore the index assignment
was refactored.
It was previously an important part of DVDInterface,
but since its usage there was replaced with DVDThread,
the only remaining uses of it are in Boot and Boot_BS2Emu.
ValidCopyRange incorrectly returned false and stopped a
CopyToEmu when pressing B+X+Start in some GameCube games
(for instance Metroid Prime) after the DVD thread was implemented
This 'absolutely not' a read of uninitialized memory is '100% not'
the cause of our non-deterministic behavior on the Intel NUC.
If there was a such an error, it would show up on all FifoCi
backends equally. This is 'probably' unrelated to the fact that
the Intel NUC is the only fifoci runner not running under virtualization.
This addresses a bit of thread unsafety mentioned in a comment, and
fixes a 'ScheduleEvent_Threadsafe from main thread' message.
To make this work nicely, make PauseAndLock call DeclareAsCPUThread -
i.e. while you have the CPU thread locked, you can consider yourself the
CPU thread.
