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
This makes the links explicitly vertically centered in the DolphinWX
About dialog. It is not needed on Windows, because the links have the
same height as text (and look just like text links). However, this is
required on other platforms or the links would look misaligned.
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.
Most modern Unix environments use 64-bit off_t by default: OpenBSD,
FreeBSD, OS X, and Linux libc implementations such as Musl.
glibc is the lone exception; it can default to 32 bits but this is
configurable by setting _FILE_OFFSET_BITS.
Avoiding the stat64()/fstat64() interfaces is desirable because they
are nonstandard and not implemented on many systems (including
OpenBSD and FreeBSD), and using 64 bits for stat()/fstat() is either
the default or trivial to set up.
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.)
This makes the device ID assigning code common to all backends, by
moving it to AddDevice() instead of copy-pasting or replicating
the logic in the backends.
Also, to prepare for hotplugging, instead of relying on a name usage
count, the new ID assigning system always starts from ID 0 and tries
to assign the first ID that is not used.
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.
CScript must be run as 64-bit regardless of the MSBuild bitness. Otherwise it won't find 64-bit Git installations.
However the "Sysnative" redirector is not available for 64-bit processes. So a fix is needed when 64-bit MSBuild is run.
The "ProgramFiles(x86)" Macro is only set for 64-bit, otherwise it is empty. Therefore it can be used as condition to check whether the current MSBuild process is 32 or 64-bit.
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.
The values are expected to be in the 0.0-1.0 range (as indicated by the
comment), and other parts of Dolphin also expect it to be in that range
since the "full" axis has a -1.0 to 1.0 range. However, this is not
always the case and fvalue can end up being outside of the range. This
clamps fvalue to always be in the 0.0 and 1.0 range.
- 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.
This makes it clear that sending a signal a second time will force stop
Dolphin (which is useful in case the GUI is deadlocked or otherwise
unable to react to the signal).
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.
This makes DolphinWX shut down cleanly, just like it would with
File->Exit when it receives a SIGINT, SIGTERM (Unix) or some signals
on Windows.
The default signal handler will be restored after a first shutdown
signal so a second signal will exit Dolphin forcefully.
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.
From wxWidgets master 81570ae070b35c9d52de47b1f14897f3ff1a66c7.
include/wx/defs.h -- __w64 warning disable patch by comex brought forward.
include/wx/msw/window.h -- added GetContentScaleFactor() which was not implemented on Windows but is necessary for wxBitmap scaling on Mac OS X so it needs to work to avoid #ifdef-ing the code.
src/gtk/window.cpp -- Modified DoSetClientSize() to direct call wxWindowGTK::DoSetSize() instead of using public wxWindowBase::SetSize() which now prevents derived classes (like wxAuiToolbar) intercepting the call and breaking it. This matches Windows which does NOT need to call DoSetSize internally. End result is this fixes Dolphin's debug tools toolbars on Linux.
src/osx/window_osx.cpp -- Same fix as for GTK since it has the same issue.
src/msw/radiobox.cpp -- Hacked to fix display in HiDPI (was clipping off end of text).
Updated CMakeLists for Linux and Mac OS X. Small code changes to Dolphin to fix debug error boxes, deprecation warnings, and retain previous UI behavior on Windows.
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.
Note: It's not 100% perfect, as some of the GPU capablities leak into the
pixel shader UID.
Currently our UIDs don't get exported, so there is no issue. But someone
might want to fix this in the future.
As much as possible, the asserts have been moved out of the GetUID
function. But there are some places where asserts depend on variables
that aren't stored in the shader UID.
Bug Fix: It was theoretically possible for a shader with depth writes
disabled to map to the same UID as a shader with late depth
writes.
No known test cases trigger this.
Bug Fix: The normal stage UIDs were randomly overwriting indirect
stage texture map UID fields. It was possible for multiple
shaders with diffrent indirect texture targets to map to
the same UID.
Once again, it dpesn't look like this bug was ever triggered.
This frees up 21 bits and allows us to shorten the UID struct by an entire
32 bits.
It's not strictly needed (as it's encoded into the length) but I added a
bit for per-pixel lighiting to make my life easier in the following
commits.
The only code which touches xfmem is code which writes directly into
uid_data.
All the rest now read their parameters out of uid_data.
I also simplified the lighting code so it always generated seperate
codepaths for alpha and color channels instead of trying to combine
them on the off-chance that the same equation works for all 4 channels.
As modern (post 2008) GPUs generally don't calcualte all 4 channels
in a single vector, this optimisation is pointless. The shader compiler
will undo it during the GLSL/HLSL to IR step.
Bug Fix: The about optimisation was also broken, applying the color light
equation to the alpha light channel instead of the alpha light
euqation. But doesn't look like anything trigged this bug.
OS X uses a case insensitive filesystem by default: when I try to build,
a system header does #include <assert.h>, which picks up
Source/Core/Common/Assert.h. This only happens because CMakeLists adds
'${PROJECT_BINARY_DIR}/Source/Core/Common' as an include directory: in
an out-of-tree build, that directory contains no other source files, but
in an in-tree build PROJECT_BINARY_DIR is just the source root.
This is only used for scmrev.h. Change the include directory to
'${PROJECT_BINARY_DIR}/Source/Core' and the include to
"Common/scmrev.h", which is more consistent with normal headers anyway.
Small cleanup by using std::shared_ptr and getting rid of
ciface.Devices() which just returned the m_devices (which defeats the
point of making m_devices protected).
Incidentally, this should make the code safer when we have
different threads accessing devices in the future (for hotplug?).
A lot of code use Device references directly so there is
no easy way to remove FindDevice() and make those unique_ptrs.
Using a minimum width is a good compromise between
setting all buttons to the same width
and letting them all decide their own width.
This is because the small buttons are kept tidy and regular
while allowing the biggest buttons to fit their contents.
Previously, the devices vector would be passed to all backends. They
would then manually push_back to it to add new devices. This was fine
but caused issues when trying to add synchronisation.
Instead, backends now call AddDevice() to fill m_devices so that it is
not accessible from the outside.
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.
Fixes a major preformance regression in Skies of Arcadia during
battle transisions.
I had plans for a more advanced version of this code after 5.0,
but here is a minimal implemenation for now.
allthough this is a mesa bug, this is a simple enough workaround for context
creation fails with EGL_CONTEXT_OPENGL_FORWARD_COMPATIBLE_BIT_KHR set.
Otherwise dolphin will fail to create 3.3+ core context with current mesa
version
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
Also swaps the byte order from RGBA->BGRA to match GL/D3D12, and what
the read handler is expecting.
Depth reads will now return the minimum depth of all samples, instead of
the average of all samples.
Using glMapBufferRange to read back the contents of the SSBO is extremely
slow on NVIDIA drivers. This is more noticeable at higher internal
resolutions. Using glGetBufferSubData instead does not seem to exhibit
this slowdown.
make sure Reset() can’t be run concurrently with AddGCAdapter() or
ResetRumble() (which is called on other threads) which can cause
crashes (issue #9462)
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).
Sorts out references that cause some modules to be kept around after
backend shutdown.
Should also solve the issue with errors being thrown due to the config
being loaded after device creation, leading to the incorrect device being
used in a multi-adapter system.
Moves render target restoring to RestoreAPIState, this also means no need
to manually restore after allocating in a buffer that caused execution,
because the manager restores it for us.
Remove a method that wasn't used from D3DUtil.cpp, and fixes a few errors
in EFB poke drawing.
This is not optimal, but for those texture packs with extremely large
images, it won't crash. Releasing after the frame completes is an option
too, however, there is the risk of running out of memory by doing this.
NeoGamma is explicitly sending a nonsense command to the Bluetooth module;
make sure to respond with something sane.
Fixes issue 9470, a regression from PR #1856.
