We just about get away with using a StateFlow in NetplaySession since the host sends AbortGameDigest when closing their own dialog. Without that it would be harder for the UI to distinguish between subsequent dialogs. If that wasn't the case then NetplaySession might need to expose the individual progress and result updates and have the view model assemble it into the overall GameDigestProgress.
Create a new NetplaySession each time we try to join a netplay game. Hold onto it in NetplayManager so its available to the different activities that need to access it. Close the session when backing out of the netplay UI. Some guardrails in case things go out of sync: creating a session closes the old one if it is still around for some reason, finalizer in NetplaySession to release native resources if not closed explicitly for some reason. Profiling done to ensure all kotlin and native objects are successfully cleared / garbage collected.
Boot session data is already handled when the game is booted so this is just fallback in case the game launch fails in some weird way.
Add missing @Keep annotations to functions called from C++
For some reason, NativeLibrary.kt calling Log for the alert message text
makes Dolphin die with a JNI error. Supposedly the jstring passed to the
logging function is invalid. I don't understand why, because the dialog
that we show right afterwards is able to read the string just fine. The
error happens even if I pass the string directly to Log without
prepending any extra text.
There's no real downside to having the logging in C++ instead of Kotlin,
so let's move it to C++ to avoid the JNI error.
Now with cancel button and an actual progress bar. For simplicity, we do
two passes on the progress bar, one for loading the NAND into memory and
one for extracting it. The user directory is likely on an SSD, making
the extraction pass invisibly fast.
The functions SaveToSYSCONF and LoadFromSYSCONF contain checks for
whether emulation is running. The intent of this is that when we're
emulating a Wii, the emulated system may write to SYSCONF whenever it
likes and does not expect anything else to write to SYSCONF, so the
host code shouldn't access SYSCONF while emulation is ongoing. However,
Core::IsRunning is an imperfect proxy for whether we've handed over
control of SYSCONF to the emulated system yet, as the actual handover
happens at a slightly different point in time than when the emulation
state is changed. This usually isn't a problem, but in theory it could
be a determinism problem if a setting is changed right as emulation is
starting, or it could cause the emulated software to briefly misbehave
if a setting is changed right as emulation is stopping.
Things got worse in 72cf2bdb87 when I
replaced the Core::IsRunning calls with !Core::IsUninitialized. With
IsRunning, there was be a period of time where SYSCONF should have been
protected but wasn't. With !IsUninitialized, there was a period of time
where SYSCONF shouldn't have been protected but was, and crucially, this
period of time included the moments where we do setup and teardown of
the emulated NAND, which broke transferring SYSCONF settings between the
host and the guest. 72cf2bdb87 was
reverted because of this.
This commit adds a flag that we explicitly flip when control is handed
over to or from the emulated system. This protects the SYSCONF file
for exactly as long as is needed.
Dr. Dystopia
Tom Pratt
JosJuice
Tillmann Karras
Simonx22
Jordan Woyak
Sintendo
Joshua Vandaële
LillyJadeKatrin