| Age | Commit message (Collapse) | Author |
|---|
|
Core: Add synchronization to state changes (Fix Frame Step and FIFO Player - Issue 8718)
|
|
Environment.getExternalStorageDirectory().getPath() covers the end of the path with a slash, get rid of the extra slash to fix the path.
|
|
And fix deprecation warning in script
|
|
|
|
Apply is asynchronous, and we aren't expecting a return value so there
is no reason not to use apply.
|
|
|
|
|
|
|
|
EndPlayInput runs on the CPU thread so it can't directly call
UpdateWantDeterminism. PlayController also tries to ChangeDisc
from the CPU Thread which is also invalid. It now just pauses
execution and posts a request to the Host to fix it instead.
The Core itself also did dodgy things like PauseAndLock-ing
from the CPU Thread and SetState from EmuThread which have been
removed.
|
|
Fix Frame Advance and FifoPlayer pause/unpause/stop.
CPU::EnableStepping is not atomic but is called from multiple threads
which races and leaves the system in a random state; also instruction
stepping was unstable, m_StepEvent had an almost random value because
of the dual purpose it served which could cause races where CPU::Run
would SingleStep when it was supposed to be sleeping.
FifoPlayer never FinishStateMove()d which was causing it to deadlock.
Rather than partially reimplementing CPU::Run, just use CPUCoreBase
and then call CPU::Run(). More DRY and less likely to have weird bugs
specific to the player (i.e the previous freezing on pause/stop).
Refactor PowerPC::state into CPU since it manages the state of the
CPU Thread which is controlled by CPU, not PowerPC. This simplifies
the architecture somewhat and eliminates races that can be caused by
calling PowerPC state functions directly instead of using CPU's
(because they bypassed the EnableStepping lock).
|
|
Those macros may be defined, or not. We should support both cases, so use std::string as it also defines the length of the string.
|
|
|
|
So new files will be added, eg the missed Wii directory.
|
|
Seems like this one was just missed, some games just did not start without it.
|
|
|
|
|
|
Update to MaJoR1's latest on screen buttons
|
|
|
|
|
|
|
|
|
|
Revert "Merge pull request #3578 from Armada651/forced-slow-depth"
|
|
Run pngout and zopflipng on every single PNG in this repo.
|
|
|
|
Improve stability of the Wii U Gamecube Controller adapter under Android.
|
|
This reverts commit e2a1a085b6a9f36b23128872de85da727d231882, reversing
changes made to 2aea549eef85ba165672c8355d0e90781d805efd.
|
|
|
|
[Android] Fix crash when we don't have access to a folder.
|
|
VideoConfig: Replace FastDepthCalc by ForcedSlowDepth.
|
|
Under failure conditions of the GC Adapter, When interface count is zero and we can't open the device.
Then there were race conditions on shutdown of the threads which could result in crashing.
Make adapter opening more robust like the Mayflash DolphinBar.
Make shutdown more robust by making the read thread control the write thread.
Make sure that there is actual data to be written when kicking the write thread. So it doesn't attempt a write a shutdown.
Make a toast on screen to tell the user that the adapter needs to be unplugged and plugged back in again for it to work.
|
|
|
|
|
|
|
|
|
|
This is the only way to get Wiimotes working under Android now.
This, just like the Wii U Gamecube Controller Adapter, completely goes around Android's limitations and talks with the device directly through USBManager.
Couple notes.
Continuous scanning must be enabled otherwise the Wiimotes won't be seen.
The UI doesn't expose support for this yet. One must change the Wiimote source and continuous scanning settings manually.
Testing up to two wiimotes in Taiko No Tatsujin, no reason to believe all four won't work.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Implement requesting permission for using the GC Wii U Adapter.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
