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.
IsDeviceUsable in IOhidapi.cpp uses errno to detect if hid_write failed because of an unconnected Wiimote on a Dolphinbar (it expects errno == EPIPE in this case).
macOS’s implementation of hid_write detected this specific error (IOHIDDeviceSetReport returns kUSBHostReturnPipeStalled) but didn’t set errno so the check failed.
This add errno assignment to failure cases of macOS’s hid_write.
If available, use the system-generated unique ID for HID device paths instead of a transport/vid/pid/location tuple.
The Mayflash Dolphinbar registers four HID devices (regardless of the number of connected Wiimotes) which had the same path with the previous path building method, causing a bit of confusion when detecting and connecting to Wiimotes.
The unique IDs do not change if the computer is suspended and resumed, but do change if the HID device is unplugged/replugged.
1. Allow users to pick games dircetory from external storage.
2. Better UX experince to distinguish between selecting a directory or
a game. The later is needed when we implement change disk for android.
Tested on a linux Intel Skylake integrated graphics with
blend_func_extended force-disabled, as it's the only platform I have
that doesn't crash with ubershaders and supports fb_fetch
It seems it doesn't like modifying inout variables in place - so instead
use a temporary for ocol0/ocol1 and only write them once at the end of
the shader
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.)
1) Most of the times the native heap is kept around even after the activity
is killed, we can ask the native code if it is still running and resume
the emulation if that is the case.
2) In case the native heap is freed and the emulation can't resume we used
a temporary state to load on the game boot.
I couldn't find a way to test this, if you want to test this schnario,
add this block to EmulationFragment.
public void onDestroy()
{
stopEmulation();
super.onDestroy();
}
onDestroy is only called if the acivity killed by the OS and not be rotation
change whihch in this case will make sure to kill the emulation and start
again when the activiy is re-created.
