All relevant games other than Pikmin 1 Wii seem to always set the two
dwords to zero, so previously they were ignored during command dispatch
and now we still ignore them but in the right place.
When writing the software FMA code, I didn't realize that we can't
overwrite d if d is the same register as one of the inputs and
HandleNaNs is going to be called. This fixes that.
On all platforms, this would result in out of bounds accesses when getting the component sizes (which uses stuff from VertexLoader_Position.h/VertexLoader_TextCoord.h/VertexLoader_Normal.h). On platforms other than x64 and ARM64, this would also be out of bounds accesses when getting function pointers for the non-JIT vertex loader (in VertexLoader_Position.cpp etc.). Usually both of these would get data from other entries in the same multi-dimensional array, but the last few entries would be truly out of bounds. This does mean that an out of bounds function pointer can be called on platforms that don't have a JIT vertex loader, but it is limited to invalid component formats with values 5/6/7 due to the size of the bitfield the formats come from, so it seems unlikely that this could be exploited in practice.
This issue affects a few games; Def Jam: Fight for New York (https://bugs.dolphin-emu.org/issues/12719) and Fifa Street are known to be affected.
I have not done any hardware testing for this PR specifically, though I *think* I previously determined that at least a value of 5 behaves the same as float (4). That's what I implemented in any case. I did previously determine that both Def Jam: Fight for New York and Fifa Street use an invalid normal format, but don't actually have lighting enabled when that normal vector is used, so it doesn't change rendering in practice.
The color component format also has two invalid values, but VertexLoader_Color.h/.cpp do check for those invalid ones and return a default value instead of doing an out of bounds access.
IOS::HLE::IOCtlVRequest::Dump sometimes tries to call GetPointerForRange
with an address of 0 and a size of 0. Address 0 is valid, but we were
mistakenly also trying to check that address 3FFFFFFF is valid, which it
isn't.
Fixes https://bugs.dolphin-emu.org/issues/13514.
Typically when someone uses GetPointer, it's because they want to read
from a range of memory. GetPointer is unsafe to use for this. While it
does check that the passed-in address is valid, it doesn't know the size
of the range that will be accessed, so it can't check that the end
address is valid. The safer alternative GetPointerForRange should be
used instead.
Note that there is still the problem of many callers not checking for
nullptr.
This is part 2 of a series of changes removing the use of GetPointer
throughout the code base. After this, VideoCommon is the one major part
of Dolphin that remains.
Typically when someone uses GetPointer, it's because they want to read
from a range of memory. GetPointer is unsafe to use for this. While it
does check that the passed-in address is valid, it doesn't know the size
of the range that will be accessed, so it can't check that the end
address is valid. The safer alternative GetPointerForRange should be
used instead.
Note that there is still the problem of many callers not checking for
nullptr.
This is the first part of a series of changes that will remove the usage
of GetPointer in different parts of the code base. This commit gets rid
of every GetPointer call from our IOS code except for a particularly
tricky one in BluetoothEmuDevice.
RCOpArg::ExtractWithByteOffset is only used in one place: a special case
of rlwinmx. ExtractWithByteOffset first stores the value of the
specified register into m_ppc_state (unless it's already there), and
then returns an offset into m_ppc_state. Our use of this function has
two undesirable properties (except in the trivial case `offset == 0`):
1. ExtractWithByteOffset calls StoreFromRegister without going through
any of the usual functions. This violated an assumption I made when
working on my constant propagation PR and led to a hard-to-find bug.
2. If the specified register is in a host register and is dirty,
ExtractWithByteOffset will store its value to m_ppc_state even when
it's unnecessary. In particular, this always happens when rlwinmx
uses the same register as input and output, since rlwinmx always
allocates a host register for the output and marks it as dirty.
Since ExtractWithByteOffset is only used in one place, I figure we might
as well inline it there. This commit does that, and also alters
rlwinmx's logic so the special case code is only triggered when the
input is already in m_ppc_state.
Input in `m_ppc_state`, before (11 bytes):
mov esi, dword ptr [rbp-104]
mov dword ptr [rbp-104], esi
movzx esi, byte ptr [rbp-101]
Input in `m_ppc_state`, after (5 bytes):
movzx esi, byte ptr [rbp-101]
Input in host register, before (8 bytes):
mov dword ptr [rbp-104], esi
movzx esi, byte ptr [rbp-101]
Input in host register, after (3 bytes):
shr edi, 0x18
There were three distinct mechanisms for signaling symbol changes in DolphinQt: `Host::NotifyMapLoaded`, `MenuBar::NotifySymbolsUpdated`, and `CodeViewWidget::SymbolsChanged`. The behavior of these signals has been consolidated into the new `Host::PPCSymbolsUpdated` signal, which can be emitted from anywhere in DolphinQt to properly update symbols everywhere in DolphinQt.
Not sure if the behavior I'm implementing here is what real hardware
does, but since this is a buffer overflow, I'd like to get it fixed
quickly. Hardware verification can happen later.
https://bugs.dolphin-emu.org/issues/13506
Having to look up macros that are defined elsewhere makes the code
harder to reason about. The macros don't remove enough repetition to
justify their existence in my opinion.
When the divisor is a constant value, we can emit more efficient code.
For powers of two, we can use bit shifts. For other values, we can
instead use a multiplication by magic constant method.
- Example 1 - Division by 16 (power of two)
Before:
mov w24, #0x10 ; =16
udiv w27, w25, w24
After:
lsr w27, w25, #4
- Example 2 - Division by 10 (fast)
Before:
mov w25, #0xa ; =10
udiv w27, w26, w25
After:
mov w27, #0xcccd ; =52429
movk w27, #0xcccc, lsl #16
umull x27, w26, w27
lsr x27, x27, #35
- Example 3 - Division by 127 (slow)
Before:
mov w26, #0x7f ; =127
udiv w27, w27, w26
After:
mov w26, #0x408 ; =1032
movk w26, #0x8102, lsl #16
umaddl x27, w27, w26, x26
lsr x27, x27, #38
This implements the GameCube modem adapter. This implementation is stable but not perfect; it drops frames if the receive FIFO length is exceeded. This is probably due to the unimplemented interrupt mentioned in the comments. If the tapserver end of the connection is aware of this limitation, it's easily circumvented by lowering the MTU of the link, but ideally this wouldn't be necessary.
This has been tested with a couple of different versions of Phantasy Star Online, including Episodes 1 & 2 Trial Edition. The Trial Edition is the only version of the game that supports the Modem Adapter and not the Broadband Adapter, which is what made this commit necessary in the first place.
This expands the tapserver BBA interface to be available on all platforms. tapserver itself is still macOS-only, but newserv (the PSO server) is not, and it can directly accept local and remote tapserver connections as well. This makes the tapserver interface potentially useful on all platforms.
Testing found that spamming toggles for Enable Leaderboards etc risked leaderboards being deleted while the runtime was in the process of recalculating them; this should clear up those conflicts.
Not only was the extra call to the update callback in the AchievementEventHandler method unnecessary, it was getting called on events that don't even need to be tracked here, causing a lot of lag when it turned out one achievement was repeatedly spamming Achievement Reset Events as a shortcut.
Failing to do this was causing challenge icons to carry over into the next game if a game was closed while the icons were active, even if the next game to run was a completely different game entirely with completely different badges.
RetroAchievements plans to use the user_agent in unlock requests to determine which software version was used to play the game, and can filter older software versions out. As such, I have been given the go-ahead to remove the hardcoded line that forces hardcore to always be false.
Two minor updates to improve the Achievement Manager's handling of a player's completion rate.
One, UnlockStatus and the unlock map now track achievement category, such that TallyScore does not count unofficial achievements in counts/points.
Two, the determinations for mastery/completion are now improved to check (1) that the achievement triggering this is CORE (not UNOFFICIAL) and (2) that it has not already been unlocked at this level on the site, which should be sufficient to determine that the unlocking of this particular achievement completes/masters the game.
Most obviously, there is no longer a warning message to the player in the achievement window that achievements are disabled if a game is not currently running.
This fixes an issue introduced by 3b0444be6b
where the m_accelerator would not be initialized when loading a savestate if
the current UCode mismatched the UCode in the savestate, leading to a crash.
Adds a setting field under the hood to retain which folder the player last saved/loaded a state to/from, so that the dialog box to select a state to save/load reopens at that folder.
Because the last commit made us use separate folders for GCPad and
GCKey profiles, we should also use separate game INI keys for them.
Otherwise setting e.g. PadProfile1 in a game INI will make both GCPad
and GCKey try to load it, typically with one of them succeeding and the
other one showing a panic alert due to the profile not existing in its
folder.
Better do this breaking change for GCKeys in the same PR as the other
breaking change rather than later.
By having getters for this information, other code that needs access to
the same information can call the getters instead of duplicating the
information.
Core::RunAsCPUThread is obsoleted by CPUThreadGuard reference already passed into the function. The nonsense lambda in CheatSearchWidget is from changes in fdb7328c73.
Instead, we make the event take a reference to the system and then pass
it in when the event is triggered.
This does introduce two other accessors, but these are much easier to
refactor out over time, and without modification to the existing event
interface.
The Host URL setting in the RetroAchievements config will, if set, be used as the host URL for all server requests for achievements. This allows for an easy switch to the RetroAchievements staging server for testing.
std::set's lower_bound() is optimized better than the generic
implementation of std::lower_bound()
std::lower_bound() works best on random access iterators, where the
number of comparisons can be logarithmic. However, since std::set's
iterators are bidirectional iterators, the comparisons will actually be
linear in practice when using std::lower_bound().
So, we can use std::set's version which is guaranteed to be logarithmic.
Makes these implementations more thread-safe by design. These likely
won't be run on any other thread, but we may as well just use the
re-entrant variant if it's available.
Given we have fixed allocation orders, we can just directly return a
span instead of a pointer and a size via an out parameter.
Makes it a little more convenient, since we get both pieces of info at
once, and also have the ability to iterate directly off the span out of
the box.
Keep a shared_ptr to NetKDTimeDevice inside NetKDRequestDevice.
This allows the KDDownload task to finish its work without potentially
trying to dereference nullptr, which can potentially come from either
GetIOS() or GetDeviceByName() if EmulationKernel's destructor has
started running.
Explicitly shut down work queues in NetKDRequestDevice's destructor to
prevent their threads from accessing members after they've been freed.
This crash would occur sporadically if NetKDRequestDevice's periodic
download or mail checks happened to overlap with emulation shutdown in
the wrong way.
An example sequence of events that could cause the crash:
* m_scheduler_timer_thread queues a periodic Download event in
m_scheduler_work_queue, then waits for m_shutdown_event.
* A request to stop emulation results in s_ios being reset by the CPU
thread. This triggers NetKDRequestDevice's destructor which sets
m_shutdown_event and joins m_scheduler_timer_thread.
* m_scheduler_timer_thread wakes from m_shutdown_event and returns from
its thread function, ending the thread.
* The CPU thread resumes execution at the end of NetKDRequestDevice's
destructor and begins destroying NetKDRequestDevice's members in
reverse declaration order.
* m_http is declared after m_scheduler_work_queue and is therefore
destroyed earlier.
* m_scheduler_work_queue's destructor calls its Shutdown function, which
by default finishes the work items in the queue.
* The queued Download event calls KDDownload which calls m_http.Get()
which calls Fetch() which passes garbage data from the freed m_curl
into curl_easy_setopt().
* Curl promptly crashes.
Shutting down the work queues manually in the destructor prevents the
above because m_http and the other members don't get freed until after
the queue threads finish.
Given how many member functions make use of the system instance,
it's likely just better to pass the system instance in on construction.
Makes the interface a little less noisy to use.
We can get rid of the global system accessors by requiring passing in
relevant state that the function needs and making callsites do the work.
This *does* add a global accessor to the PPCAnalyzer, however, this already
has global accessors present elsewhere within its code, so they can be removed
all at once in a follow up change.
Admiral H. Curtiss