Instead of directly reading/storing settings from/to the SYSCONF, we
now store Wii settings to Dolphin's own configuration, and apply them
on boot. This prevents issues with settings not being saved, being
overridden and lost (if the user opens a dialog that writes to the
SYSCONF while a game is running).
This also fixes restoring settings from the config cache after a
graceful shutdown; for some reason, settings were only restored
after a normal shutdown.
Fixes issue 9825 and 9826
Using u8 as indexers is kind of silly, since the rest of the public API
essentially uses int for this sort of thing. Changing these to int also
gets rid of quite a few implicit truncations.
This also allows for getting rid of similar silliness in the netplay API.
There's no official implementation of the Vulkan API,
and Dolphin currently isn't set-up to work with the
single, commercially-available third-party implementation.
Some OSD messages were displayed in RenderBase.cpp using global variables and some code duplicated
in OnScreeDisplay.cpp.
Now all messages are displayed using functions in the OSD namepace.
* OSDChoice and OSDTime global variables are gone
* All OSD logic is kept at the same place
* All messages are properly aligned
* Clean characters for all OSD messages
Original commit:
commit f0ec61c05707c9657baaad096e21cf60abd267f9
Author: Aestek <thib.gilles@gmail.com>
Date: Sun Aug 7 16:08:41 2016 +0200
It doesn't make much sense to prefix g_ to static variables and for
some to be completely unprefixed.
Also renames a lot of other variables for the new conventions
This fixes an issue where the Bluetooth info section could be fully
filled up by syncing 5 Wiimotes in passthrough mode then switching to
emulated Bluetooth; emulated Wiimotes were then unable to be used.
The "real" SYSCONF section is now backed up before being replaced with
a blank section that the emulated BT adapter can always fill with 5
Wiimotes without issues.
This backup is restored by the passthrough code, instead of during
the Bluetooth mode switch because this should be done regardless of the
user interface, and even without UI (if the config file is edited
manually).
Homebrew programs seem to rely on getting a reply to the vendor
specific commands, without which Bluetooth initialisation will never
complete.
This vendor-specific command is typically used to patch the Wii's
Bluetooth module, so the replies are only faked when the passed through
adapter is not a Wii Bluetooth module.
This stores the address of paired devices and associated link keys.
It is needed because some adapters forget all stored link keys when
they are reset, which breaks pairings because the Wii relies on the
Bluetooth module to remember them.
It doesn't fix adapters that can't remember any link key
at all and always return 0 for the number of stored/written link keys.
For those adapters, there is no fix.
This also improves the usability of passthrough mode for adapters that
already work, since pairings will now keep working even if the link
keys get cleared by something else (for example by the host Bluetooth
stack).
Apparently, Nintendo's Bluetooth stack expects the ACL packet buffer
size to be limited to 10.
Reporting anything higher than that could cause memory corruption,
which can result in warning messages in the logs ("event mismatch"),
and more annoyingly, random disconnects.
Thanks to shuffle2 for the fix!
This adds the ability to passthrough a whole Bluetooth adapter and skip
the majority of the Bluetooth emulation code. We use libusb to send HCI
commands, receive HCI events and transfer ACL data directly to the
first adapter that is found or to a specific adapter (if configured to)
This is possible because the Wii's Bluetooth module is actually just
a pretty standard Bluetooth adapter…
…except for two vendor-specific commands, for which replies are faked,
and also for the sync button. This adds a hotkey that works in the
exact same way as the sync button would on a Wii: it triggers an HCI
event, which emulated software interpret as a command to perform
a BT inquiry.
This commit also changes the UI code to expose passthrough mode
and WII_IPC_HLE to be a bit more thread safe (for the device map).
This moves the unordered_map used to store connected Wiimotes IDs to
WiimoteReal, and makes the ID insert/erase logic common so we don't
have to duplicate this code in scanner backends.
The Balance board detection logic is already implemented in a simpler
way in Wiimote::IsBalanceBoard() (since hidapi also needs it).
Therefore, IOWin now only needs to check if a device is a Wiimote.
This is intended to make reconnecting Wiimotes easier with a DolphinBar.
Unfortunately, this change isn't enough as it doesn't always catch
disconnections for Wiimotes connected with a DolphinBar.
But it's better than nothing and eventually a disconnection will be
detected when something tries to write to the Wiimote, instead of never.
There is no other solution as the DolphinBar always exposes 4 HIDs even
when the associated Wiimotes are not connected.
We could try to detect this using the fake input reports sent by the
DolphinBar, but this only works for the first HID (probably because of
a bug in the firmware?), so this method is not an option.
If FindWiimotes() took more time than the UI shutting down, the scanner
would try connecting a Wiimote and sending an event to the UI code
long after it has shut down, which causes a segfault.
This fixes the race by ignoring any found Wiimotes during shutdown.
Normally this would have never happened, but it is possible with hidapi
since Wiimotes can be connected before Dolphin starts.
Based on ca0c2efe7ab19c85449d52dd1bf4beec8603bbfe. Credits go to flacs.
However, unlike the original commit, hidapi does not completely replace
the current implementations, so we can still connect Wiimotes with 1+2
(without pairing).
Also, it is only used on Linux and OS X for now. This removes the
advantage of having only one implementation but there is no other
choice: using hidapi on Windows is currently impossible because
hid_write() is implemented in a way that won't work with Wiimotes.
Additionally:
* We now check for the device name in addition to the PID/VID so we can
support the Balance Board and maybe third-party Wiimotes too. This
doesn't achieve anything with the DolphinBar but it does with hidraw.
* Added a check to not connect to the same device more than once.
Same thing but allows both GeckoCode and Code to be utilized directly
without predicates for equality/inequality in stardard algorithms
The size check for std::vectors is unnecessary, as this is built into std::vector's operator==
Because of the way this works, randomly overwriting the handler
when loading a savestate will break things because of the
self-modifying nature of the handler.
GeckoCodes require address hooks which don't correspond to any
symbol in the symbol table. The hooks get deleted when repatching
the game because they did not persist across calls to
HLE::PatchFunctions.
Dolphin emulates GeckoCodes by fiddling with the CPU state when a
VI Interrupt occurs. The problem with this is that we don't know
where the PC is so it's non-deterministic and not necessarily
suitable for use with the codehandler.
There are two options: Patch the game like Gecko OS either directly
or using HLE::Patch, or use a trampoline so we can branch from any
PC even if it would otherwise not be valid. The problem with Gecko OS
patches is there are 10 of them and they have to be configured
manually (i.e. Game INIs to would need to have a [Core]GeckoHookType
property).
HLE_Misc::GeckoReturnTrampoline enables the Code Handler to be
entered from anywhere, the trampoline restores all the registers that
had to be secretly saved to the stack.
If the installation fails because codehandler.bin is missing or
unusable then Dolphin will try again every single frame even though
it's highly unlikely a disk file will have changed. Better to just
fail once then only try again when the active code set is changed.
Suppresses generating 60 log messages per second.
Turns out one of the magic numbers was very magic. The gameid is
an ad-hoc comm protocol with HLE_Misc to control the number of times
the ICache is reset.
The code table builder cuts off the end of codes that won't fit
after already writing part of it. That seems quite unlikely to
work the way anyone would find useful since the codes can contain
actual PPC instructions.
The active codes vector cannot safely be used outside the mutex,
move the lock out into RunCodeHandler. s_code_handler_installed was
also racing against SetActiveCodes since it's being written both
inside and outside the lock.
General cleanup. Add s_ prefixes, use constexpr, remove C casts.
Executing PPC code inside an external events callback is a bad idea.
CoreTiming::Advance does not support recursion properly which will
cause timing glitches. The interpreter has a slice length hack that
counters this but without it this would cause a 20000 cycles time
skip. It isn't clear what this was supposed to accomplish that just
changing the current PC would not. Changing the PC works fine.
When standby mode is enabled, this causes games to ES_Launch the system
menu instead of directly asking IOS (the STM more precisely) to shut
down, which prevents graceful shutdown from working
(it'll appear to hang).
Dolphin never supported WC24 standby mode anyway, so this shouldn't
cause any issues. (This should be reverted if and when WC24 standby is
implemented…)
This adds support for triggering the power event (in the STM), so that
stopping emulation first triggers a shutdown event, which notably gives
emulated software time to save game data (issue 8979) and clean up
SYSCONF (to disconnect Wiimotes and update their state in the SYSCONF).
On the first press, the stop button/hotkey/whatever will trigger a STM
power event. On a second try, we will forcefully stop emulation, just
like how it was working before.
There was as far as I know no reason to put everything in the header.
Separating the declaration from the implementation reduces build
times in case the implementation is updated without changing
any declaration.
It looks like the debug output is also output as SJIS (similar to
OSReport text), so we need to convert it to UTF-8 to prevent it from
all showing up as �.
This doesn't fix all display issues, but fixes all SJIS/UTF-8 related
ones.
This changes GetSymbolFromName to not require the passed name to
completely match with the symbol name. Instead, we now match
against the stripped symbol name (i.e. only the function name).
This fixes a regression introduced by #4160, which prevented
HLE::PatchFunctions() from working properly.
Call Advance at the start of each timing slice instead of the end.
Possibly fixed a bug where a slice would randomly branch straight
back to Advance() because the flags were not set to the right
values before branching to the dispatcher entrypoint.
This fix a double break bug when hitting a memcheck and hitting play on the same instruction it broke to earlier. The state is put back to CPU_RUNNING after.
These are needed for the next commit. I had to modify the implementation of the DSP one too, but since it basically isn`t used, I don`t think it matters much. These options only matters when adding one.
It wouldn't impact performance until at least one memcheck is enabled. Because of this, it can be used in release builds without much impact, the only thing that woudl change is the use of HasAny method instead of preprocessor conditionals. Since the perforamnce decrease comes right when the first memcheck is added and restored when the last is removed, it basically is all beneficial and works the same way.
The min-heap provides no ordering when the key is the same on 2
nodes. Disambiguate identical times by tracking the order items
were added into the queue.
Now that our timings are much more accurate it doesn't look like we
need it anymore. And the instant ARAM DMA mode + scheduling fixes
ctually breaks ATV: Quad Power Racing 2 (causing all sorts of werid
bugs).
Fundamentally, all this does is enforce the invariant that we always
translate effective addresses based on the current BAT registers and
page table before we do anything else with them.
This change can be logically divided into three parts. The first part is
creating a table to represent the current BAT state, and keeping it up to
date (PowerPC::IBATUpdated, PowerPC::DBATUpdated, etc.). This does
nothing by itself, but it's necessary for the other parts.
The second part (mostly in MMU.cpp) is simply removing all the hardcoded
checks for specific untranslated addresses, and consistently translating
addresses using the current BAT configuration. Very straightforward, but a
lot of code changes because we hardcoded assumptions all over the place.
The third part (mostly in Memmap.cpp) is making the fastmem arena reflect
the current BAT configuration. We do this by redoing the mapping (calling
memmap()) based on the BAT table whenever it changes.
One additional minor change is that translation can fail in two ways:
either the segment is a direct store segment, or page table lookup failed.
The difference doesn't usually matter, but the difference affects cache
instructions, like dcbz.
For step over, it was updating twice which actually made the red display on the register view (when a register changes since) malfunction. Since it doesn't seem to be usefull to update before AND after the run, the one before the run was removed.
For step out, well, because there was no chances given for the thread to run as it is single stepping all the time, I only added a call to update after it was done.
Init cannot be called more than once because it registers the
CoreTiming callbacks, that trips the assertions and will cause
anyone with PanicAlerts disabled to crash.
CoreTiming gets restored before ExpansionInterface so CoreTiming
events need to already be registered before the save state loading
begins. This means that the callbacks must be registered
unconditionally instead of on-demand.
Replace adhoc linked list with a priority heap. Performance
characteristics are mostly the same, but is more cache friendly.
[Priority Queues have O(log n) push/pop compared to the linked
list's O(n) push/O(1) pop but the queue is not big enough for
that to matter, so linear is faster over linked. Very slight gains
when framelimit is unlimited (Wind Waker), 1900% -> 1950%]
When n was a multiple of 4, the old implementation would overwrite
the following register with 0.
This was causing Not64 to crash.
Thanks to Extrems for spotting this.
DVDInterface shouldn't need to know anything about
the DTM format's 40-character limitation.
Also replacing "filename" in variable names with "path"
to make it clearer which variables contain the whole path
and which ones only contain the filename.
This introduces speculative constants, allowing FIFO writes to be
optimized in more places.
It also clarifies the guarantees of the FIFO optimization, changing
the location of some of the checks and potentially avoiding redundant
checks.
I'm not sure this is the correct fix, but it looks like OSREPORT output
is Shift-JIS, so we need to convert it to UTF-8. Most characters work
fine without and with this conversion, but Japanese text completely
fails and results in outputting invalid UTF-8 (which gets shown as �).
When 5.0-211 updated wxWidgets to 3.1.0, some entries in the
wxLanguage enum were moved and added, changing the wxLanguage
values. Because we save Dolphin's interface language to disk
as a wxLanguage, the language you have set will mean something
different depending on whether you have the updated wx version
or not. For instance, setting the language to English with the
updated version and then using an older version will make
Dolphin use Dutch. Because we can't rely on the enum anymore,
I'm replacing the "Language" setting with a "LanguageCode"
setting that uses standard ISO 639 codes.
The gather pipe optimization postpones checking the FIFO until the end
of the current block (or 32 bytes have been written). This is usually
safe, but is not correct across EIEIO instructions.
This is inferred from a block in NBA2K11 which synchronizes the FIFO
by writing a byte to it, executing eieio, and checking if PI_FIFO_WPTR
has changed. This is not currently an issue, but will become an issue
if the gather pipe optimization is applied to more stores.
Let's stop pretending that we support Triforce emulation.
Keeping this code around just in case someone will make
major improvements in the future isn't really worth it.
I'm keeping the Triforce game INIs so users will know that
the compatibility rating for Triforce games is 1 star (broken).
