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).
OSD messages other than these one and a half aren't translated,
and OSD only supports ASCII. (Also, that "Wiimote %i %s" uses %s
like it does is bad for translation, but that's easy to fix.)
These operations should always take the same amount of time,
not the same amount of ticks. The number of ticks per second
is different for GameCube and Wii.
Replaces old and simple usages of std::atomic<bool> with Common::Flag
(which was introduced after the initial usage), so it's clear that
the variable is a flag and because Common::Flag is well tested.
This also replaces the ready logic in WiimoteReal with Common::Event
since it was basically just unnecessarily reimplementing Common::Event.
Specifically, don't make any assumptions about what effective addresses
are used for code, and correctly handle changes to MSR.DR/MSR.IR.
(Split off from dynamic-bat.)
Also fold the check in both functionss into 'slowmem' rather than having
a separate test. (jo.alwaysUseMemFuncs implies jo.memcheck anyway, as
makes sense.)
This adds RemoveDevice() to ControllerInterface, fixes ExpressionParser
and some other code to support device removals without crashing,
and adds an IsValid() method to Device, to prepare for hotplugging.
This adds RegisterHotplugCallback() to register a callback which will
be invoked by the input backends' hotplug threads when there is a new
device, so that Core (GCKeyboard, GCPad, Wiimote, Hotkey) can reload
the configuration without adding a dependency to Core from InputCommon.
Since we now support different scanner sources, g_wiimotes is not
guaranteed to only contain WiimoteLinux anymore.
This replaces the previous "already connected" check with one that
doesn't use g_wiimotes.
Instead of sleeping in NetPlayClient::GetNetPads and NetPlayClient::WiimoteUpdate,
now use std::condition_variable. This allows for finer control over these blocking
areas.
This makes WiimoteScanner support several scanner backends.
This adds a WiimoteScannerBackend base class, which scanner backends
derive from, and which allows backend-specific things to be moved out
of the common code.
Also removes IODummy which is not needed anymore.
* Focus "Hash Code" / "IP address" text box by default in "Connect"
* Focus game list in "Host" tab
* RETURN keypress now host/join depending on selected tab
* Remember last hosted game
* Remove PanicAlertT:
* Simply log message to netplay window
* Remove them when they are useless
* Show some netplay message in OSD
* Chat messages
* Pad buffer changes
* Desync alerts
* Stop the game consistently when another player disconnects / crashes
* Prettify chat textbox
* Log netplay ping to OSD
Join scenario:
* Copy netplay code
* Open netplay
* Paste code
* Press enter
Host scenario:
* Open netplay
* Go to host tab
* Press enter
UPNP_AddPortMapping needs our IP address, however enet_address_get_host
will return 0.0.0.0 or a host name in most cases.
This gets our IP address from the socket to the IGD.
5.0-56 broke reconnecting a Wiimote on button press; this is because
data reporting was now always stopped for real Wii remotes on
disconnect, making it impossible to know a button was pressed in the
first place (to reconnect the Wiimote).
This semi-reverts to the previous behaviour, where data reporting is
never stopped.
(Also, control channels now go through WiimoteEmu, just like before,
to make sure some things are reset on disconnection.)
Hopefully fixes issue 9711.
This fixes warnings in:
- Source/Core/InputCommon/ControllerEmu.h: avoid shadowing other
variables (my fault)
- Source/Core/Core/IPC_HLE/WII_IPC_HLE.h: made
SDIO_EventNotify_CPUThread static as it's not used anywhere else
POSIX specifies that inet_ntoa() is declared in arpa/inet.h, and that
POLLRDNORM, etc. are defined in poll.h.
gethostbyname() is not specified by POSIX, but the manpages in OpenBSD,
FreeBSD, OS X, and glibc all state that it is declared in netdb.h.
Without these headers, the build fails on OpenBSD and possibly other
systems.
The old implementation always polled the local 1st Wiimote and used that as input for the Wiimote that is mapped to the player. But the reporting mode for Wiimotes can be different, even when using the same extensions. So an input for Wiimote 1 with a data size 4 could be used for Wiimote 2, which actually requires data size 7 at that time for example.
The 2nd problem was that the code added a dummy input into the buffer, when the reporting mode changed. But when the data from the other player hasn't arrived yet, the data in the buffer is out of order. Well, i think this is the problem, i'm not 100% sure, because i don't fully understand how the buffer works. But on the other hand, i'm pretty sure this will just force sync the players on reporting mode changes, instead of allowing them to be apart.
Pros:
- No more desyncs caused by big bugs in the code.
- Can use different extensions for different players.
Cons:
- Higher latency, because instead of polling 1 controller per player at once, all controllers are polled in order, send to the other players, before the next is processed.
- Have to setup the Wiimote, which the player is going to use, instead of the 1st one.
Now, if the controller config could temporarily be overridden with the one from another slot, the 2nd problem could be fixed. But at the same time, we would lose the ability to use different extensions. (unless we hack around it somehow, or properly send the used extension to the other players)
Specifically, don't make any assumptions about what effective addresses
are used for code, and correctly handle changes to MSR.DR/MSR.IR.
(Split off from dynamic-bat.)
At first there weren't many enums in Volume.h, but the number has been
growing, and I'm planning to add one more for regions. To not make
Volume.h too large, and to avoid needing to include Volume.h in code
that doesn't use volume objects, I'm moving the enums to a new file.
I'm also turning them into enum classes while I'm at it.
This moves back the WiimoteScanner:Update() call to where it originally
was, since according to a comment it is intended to be called only when
"when not looking for more Wiimotes", and calling it too often causes
the Bluetooth module to be loaded/unloaded a lot of times.
The Setting class was used for both numeric values and booleans, and
other parts of the code had hacks to make it work with booleans.
By splitting Setting into NumericSetting and BooleanSetting, it is
clear which settings are numeric, and which are boolean, so there is
no need to guess by checking the default values or anything like that.
Also, booleans are stored as booleans in config files, instead of 1.0.
- Externals/soundtouch/CMakeLists.txt: add -w (since it's not our code) to
silence an unused variable warning
- Source/Core/Core/NetPlayClient.cpp: Work around a Clang/libc++ bug where
initializing a std::array the way the standard says you're supposed to produces
a warning. (libc++'s implementation of std::array, like any sane
implementation, has a C array as a field, so the most explicit form of
initialization would use two braces, one for the struct and one for the array.
Clang has a general warning for not being explicit with braces, which is
usually sane. But the standard only guarantees that initializing std::array
works with a single pair of braces!) There are other places in Dolphin that
incorrectly use double braces, presumably to avoid the warning, so maybe the
warning should just be turned off, but in any case here I just switch to an
equivalent .fill().
This changes Refresh() to use the existing scanning thread to scan for
devices, instead of running the scan on the UI thread and blocking it.
Also makes the UI thread not block when Continuous Scanning is disabled
and removes duplicated code.
Should fix issue 8992.
Under the hood:
* The scanning thread is now always active, even when continuous
scanning is disabled.
* The initialize code which waits for Wiimotes to be connected also
uses the scanning thread instead of scanning on yet another thread.
* The scanning thread now always checks for disconnected devices, to
avoid Dolphin thinking a Wiimote is still connected when it isn't. So
we now check if we need new Wiimotes or a Balance Board at scan time.
Before this variable was an u8, which could theoretically result in desyncs with a large buffer(greater than 255*120/200=153) filled with blank inputs. If this could actually happen, i don't know. But this part of the code on its own looks like it could break.
A static var is not a good idea, when the value needs to be reset for every session. Also, the variable holds the data size, so it makes sense to set the data size, where the data is added.
When Movie was calling ChangeDisc, it was moving execution to
the host thread just to then make the host thread the CPU thread.
We can simply run the code directly on the CPU thread instead.
The active codes normally get cleared when a game boots, because
LoadPatches gets called, replacing the codes from the previous game.
However, there were cases where LoadPatches doesn't get called, and
then codes from the previous game would be used for the current game.
This commit clears the codes on shutdown so that it doesn't matter
whether the boot process loads LoadPatches.
Simplification/reduction of duplicated code. Detect other constant GQR values and inline loads (5-10% speedup) and do direct dispatch to AOT methods for stores.
Fixes issue 8328.
As far as I know, this works the same way as console. Games will generally
react to the reset button the same way as Home->Reset, so this is
only marginally useful, but possibly nice to have in certain situations.
Note that if you try to use Reset, and you're running a WAD which isn't
installed, it will likely crash because WADs respond to the reset button
by launching themselves with ES_LAUNCH. It might be a good idea to add some
sort of hack to make this work as expected.
It would be easy to extend this to support the power button, but it's
unclear how exactly that should be exposed in the UI. See also issue 8979.
Needs to be rebased once PR #3811 is merged.
This changes Bluetooth device discovery on Linux to use LIAC (Limited
Dedicated Inquiry Access Code) since third-party Wiimotes (such as Rock
Candy Wiimotes) are not discovered without it.
Also added accessor function in IONix class to help with checking if
the discovered Wiimote has already been found.
[leoetlino: code review suggested changes, remove unused variable,
commit message formatting fixes, and build fix]
This commit makes real Wiimotes really disconnect when they are
disconnected by the emulated software, which is more similar to how
it works with a real Wii and allows Wiimotes to be disconnected after
timeout for power saving.
This is currently only enabled on Linux, because of limitations on
the other platforms.
Fully opt-in, reports to analytics.dolphin-emu.org over SSL. Collects system
information and settings at Dolphin start time and game start time.
UI not implemented yet, so users are required to opt in through config editing.
Cleanup code style.
Move ActionReplay code->INI saving into ActionReplay namespace.
Threadsafety Cleanup: ActionReplay is accessed from the Host, Emu
and CPU Threads so the internal storage needs to be protected by a
lock to prevent vectors/strings being deleted/moved while in use by
the CPU Thread.
UI Consistency: Make ARCodes behave like Gecko Codes - only apply
changes when Apply is pressed. Save changes to INI from CheatsWindow.
ISOProperties/CheatsWindow now synchronize with each other.
ISOProperties loads codes using ActionReplay::LoadCodes which actually applies
the codes to the global state. If a game is running then that games receives
all the codes (and ACTIVE status) from the second game being shown in
ISOProperties which is not desirable.
Donkey Kong Country Returns is writing new data to some files in /tmp
when loading each level. But the savestate code was opening the files
a second time and reading some old and stale data out.
As of #3798, dolphin now correctly restores that stale data to /tmp,
which broke DKCR (and probally countless other games).
This PR closes all file handles before saving and loading savestates,
which flushes the data out and pervents this issue. (old savestates
are corrupted and will still cause crashes if loaded)
On master, when polling the 1st in-game controller, Dolphin would poll all the 1st local controllers. With the 1st commit, each client waits its turn, which would dramatically increase the lag.
Now with this commit, it even polls all local controllers at once, so it should have even less latency than master in a few setups. Like one player with 3 controllers and the 2nd one with just one controller.
This fixes issues with setups like:
Player 1 uses port 1 and player 2 uses port 3, or
player 1 uses port 2 and player 2 uses port 3, so nobody uses port 1
So they share the same emitter, and so they are in the same 128MB range.
This allows us to use B() to jump to the dispatcher.
However, so we have to regenerate them on every cache clear.
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).
