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.
Scheduling an event for zero cycles in the future actually means zero
cycles with new timing changes, but the code for IPC ACKs was depending on
it meaning "soon".
Fixes#9511.
I'm not at all confident this is actually right... but it seems to work.
This commit does 4 things:
* It increases the default small size of the NetPlay window to a larger
and more appealing size.
* It cleans up and reorganizes a bit of the NetPlay Setup UI code.
* It moves the Direct or Transversal Selector to be more appealing and
nice looking.
* The Direct or Transversal also gets a label and nicer text, and a
spacer.
I have no clue what this special case shall be, but accessing g_main_cp_state within Flush() is not allowed.
We likely still have a bad behavior, but now it only depends on the current state, not on the next one after flushing.
Call the appropriate rumble function for each SI Device, Should fix#9331.
Ideally we wouldn’t have to do this, but since the way things are wired,
fixing the root cause it out of the picture for now.
They all handled it diffrently, so I've just moved it into Advance()
This fixes Pokemon Box booting in JIT/JITIL which shared a bug where
exceptions set in a scheduled event would be ignored untill the next
slice (upto 20,000 cycles).
DriveReader::m_size was never initialized which was indirectly
causing CGameListCtrl to crash Dolphin when it tried to insert a
character at a negative index in a string.
Reading one sector at a time is very inefficient and appears to
be causing timing issues during boot so SectorReader has been
enhanced to support batching.
SectorReader has been given a working cache system.
Because the file handles were open, the recursive delete was
failing. The previous commit stopped the crash but this should
make the restore actually happen has expected.
If the game sent a command to a disconnected controller, the
wii u adapter code would return a diffrent response.
This simply deletes the speclized version of RunBuffer for the
wii-u adapter as the only diffrence was the code which detected
disconnected controllers and returned a error.
Disclaimer: I can't test if this works on xbox one controllers, i don't have one. But i have conformed that this UpdateMotors() is related to rumble for emulated wiimotes.
This partially reverts commit "XInput: Apply immediately as well" (1958a10b6f) from pr # https://github.com/dolphin-emu/dolphin/pull/1560
Hopefully this fixes the xbox one controller rumble issue:
https://bugs.dolphin-emu.org/issues/9071
And in theory it might reduce the used usb bandwidth, as it was originally intended before pr 1560.
@JMC47: Please do a good amount of testing, to see if this breaks rumble for wiimotes or gamecube controllers emulated with xinput devices.
Closing Dolphin's main frame and clicking "no" does not clear
m_bClosing which means that pressing the "stop" button triggers
OnClosed which suddenly and unexpectedly closes the main frame.
This was done because showing a column was broken:
Showing a column repopulates the column with no regard for the sorted
order. This results in a seemingly random order.
(actually the order of m_ISO_FILES)
VideoInterface::Preset was not initializing all registers, this is a problem
because it leaks register settings across games. Xenoblade Chronicles does
not like m_DisplayControlRegister having random bit patterns in it.
bool is not always guaranteed to be the same size on every platform.
On some platforms it may be one byte, on others it can be 8 bytes if the
platform dictates it. It's implementation-defined.
This can be problematic when it comes to storing this
data to disk (it can also be space-inefficient, but that's not really an
issue). Also say for some reason you moved your savestates to another
platform, it's possible they won't load correctly due to differences in size.
This change stores all bools to savestates as if they were a byte in size
and handles the loading of them accordingly.
During boot of Other M, there is momentarily a period when VICallback's
cycles late is larger than GetTicksPerHalfLine(). Because
GetTicksPerHalfLine() returns a u32 and c++'s weird type promotion rules,
cycleslate gets promoted from a s32 to a u32 and the result of the
substraction is a really large u32.
Before ScheduleEvent accuracy improvements, ScheduleEvent took a s32, so
the result got cast back to the small negitave we expect. But it now takes
a s64 and the u32 to s64 conversion gives us a really large number (around
two seconds) and Other M times out while waiting for something.
Now that the accuracy of ScheduleEvent has changed, 0 cycles will
schedule an event as soon as possible. But this breaks ATV 2.
So we schedule it 100 cycles out (unless it's a really short copy)
The NES games on the Zelda Collecters Edition disk use a XFB which is
only 256 pixels wide, but has a stide of 640 pixels.
This fits our definition of a interlaced xfb, as a second line of data
could fit in the extra space. The solution is to check that we are
actually in a interlaced video mode before activating the force
progressive hack.
MSVC's implementation of numeric_limits currently generates incorrect
signaling NaNs. The resulting values are actually quiet NaNs instead.
This commit is based off of a solution by shuffle2. The only
difference is a template specialization for floats is also added
to cover all bases
This is an oversight from pr https://github.com/dolphin-emu/dolphin/pull/3266 . Thanks to degasus for pointing this out.
It's possible that MAX_TEXTURE_BINARY_SIZE can be optimised, but i wanted to play it safe considering the 5.0 stable release.
Reading uninitalized memory is non-deterministic. We used to only
clear the memory when using EmulatedBS2_GC or FifoPlayer, but we
now do it during Memory::Init instead so it always gets done.
Drivers that don't support GL_ARB_shading_language_420pack require that
the storage qualifier be specified even when inside an interface block.
AMD's driver throws a compile error when "centroid in/out" is used within
an interface block.
Our previous behavior was to include the storage qualifier regardless, but
this wasn't working on AMD, therefore we should check for the presence of
the extension and include based on this, instead.
I'm not entirely sure what is happening, but this optimisation is causing an issue in Sonic Riders: Zero Gravity. Apparently the issue would also be fixed by PR#3747, but this PR should also fix similar issues.
Games that use partial updates might get slower with this, so some performance regression testing would be nice. Games like New Super Mario Bros, RS2, Zelda TP and Silent Hill. Testing with high graphics settings makes sense, since this would mostly end up in more work for the GPU.
Previously the default queryed the controller 4500 times a second,
Wasn't really a problem for most games as they set it to a sane
value. But fifoplayer didn't, and so in my profile dolphin spends
12% of the cpu time reading the controllers.
This new default value (I just took what the gamecube bios set)
drops that to 1.2% of cpu time and increase the framerate of the
silent hill fifo by 10-12%
The D3D backend was always forcing Anisotropic filtering when that is enabled regardless of how the game chose to configure the texture filtering registers; this causes the same issues as "Force Filtering" without Anisotropy, such as causing game UI elements to no longer line up adjacent correctly. Historically, OpenGL's Anisotropy support has always worked "better" than D3D's due to seeming to not have this problem; unfortunately, OpenGL's Anisotropy specification only gives GL_LINEAR based filtering modes defined behavior, with only the mipmap setting being required to be considered. Some OpenGL implementations were implicitly disabling Anisotropy when the min/mag filters were set to GL_NEAREST, but this behavior is not required by the spec so cannot be relied on.
Events scheduled more than 4.12 seconds in the future (2.96 seconds for
Wii games) would overflow the sign bit and get scheduled in the past
instead, causing them to fire instantly.
Previously GlobalTimer was only updated at the end of each slice
when CoreTiming::Advance() was called, so it could be upto 20,000
cycles off.
This was causing huge problems with games which made heavy use of
the time base register, such as OoT (virtual console) and Pokemon
puzzle.
I've also made it so event scheduling will be accurate to the jit
block level, instead of accurate to the slice.
instead, leave all the management with the NANDContentLoader.
for file data (directly on the NAND), this opens the file on-demand and
returns the requested chunk when asked for it.
for on-the-fly decrypted WAD data, we just keep the decoded buffer in
memory, like we've done before - except that we don't give away any objects
we don't want to.
this fixes the crashes, but leaves the "else" part of ES_READCONTENT
temporarily broken until the next commit.
WAD access that are performed on the encrypted WAD will most likely fail
with this commit.
only fixes half the issues, since we still cache a pointer from
SContentAccess.m_pContent to SNANDContent.m_data (which is free'd along
with the rest of the NAND data cached inside the CNANDContentManager when
ClearCache is called)
- remove an outdated comment about the efb to ram and scaled efb restriction
- when upscaling efb copies, mark the new texture as efb copy
- dx12 fixes for the src box, especially the number of layers for 3D
This isn't necessary, as the member functions are deleted.
If someone tries to perform a copy, the compiler will now
indicate that the member functions/constructors are deleted,
rather than inaccessible.
OS X's shader compiler has a bug with interface blocks where interface block members don't properly inherit the layout qualifier from the interface
block.
Work around this limitation by explicitly stating the layout qualifier on both the interface block and every single member inside of that block.
miniupnp commit c4991916e5c12a7754e935e71a5313e75af6aeb9 introduced a
4th statusCode parameter to miniwget function. This parameter is set
to a value returned by the UPnP device. We have to check if it's set
to 200 to make sure the result is a success. Also, we now have to check
if descXML is set in the error case and free it.
Seems like NVidia just ignores the forward compatible flag.
Additionally, they neither enable any extension which was designed later...
So either compatible profile, or a huge list of core profiles....
As confirmed by a hardware test if we are using the texgen type of COLOR_STRGBC0/STRGBC1 then it sets the texture coordinates to those values
regardless of what the input form or source row is.
Thanks to Ornox for testing again
Removes a couple asserts in the vertex shader gen when dealing with the input form.
Typically input form ABC1 is used, so it'll pull in the first three elements and always set the fourth to 1.0
The other input form available is AB11, which sets the last two components to 1.0 (Theoretically).
No titles actually use this input form that we know of except for Project M, but it can have some fairly drastic visual differences.
Confirmed correct by hardware test
This applies to callers that do not have full knowledge of the command
list state, and thus, cannot restore it should allocations cause command
list execution. Instead we reallocate a new buffer. Should not happen
often enough for this to be a concern, as it's mainly for the utility
classes.
Using CreateThread can create issues if any CRT calls are made, as
thread-specific data may not be initialized. Additionally, TerminateThread
is not a good idea for similar reasons, and may not free CRT resources.
Pierre Bourdon