BI contains both the field and the flag (5 bits total), so we need to
shift away the 2 flag bits to get the 3 field bits. (Same as the
CRBA/CRBB handling in the code just below the BI code.)
The names attached to the BadgeStatus object are obsolete and unneeded and are removed from everything that uses them. All BadgeStatus references are updated to just Badge.
The defaults get loaded in by Dolphin at emulator start, and are used if the badge that would normally be displayed has not for whatever reason been downloaded yet. Badges attached to this PR are placeholders (MayIMilae is designing permanent badges) and reside in Sys\Load\RetroAchievements.
Achievement badges/icons are refactored into the type CustomTextureData::ArraySlice::Level as that is the data type images loaded from the filesystem will be. This includes everything that uses the badges in the Qt UI and OnScreenDisplay, and similarly removes the OSD::Icon type because Level already contains that information.
Was informed by the RetroAchievements team that this isn't an option in most emulators, and as the next commits will be to enable default icons, there will always be something to display.
On Windows:
wsi.render_window being set will set/save the initial geometry, which will cause sizing bugs until it's set again by the user resizing/repositioning.
If Rich Presence and Discord Presence are enabled in Achievement Settings, the string generated by rcheevos as the player's current Rich Presence will be sent to the Status field in the Discord Presence object. This will be updated whenever Rich Presence updates.
The "welcome message" that shows up to players when a game starts up and Achievements are active will now either tell the player upon load that there's no support for achievements, or will wait until the first attempt to load the game's badge either succeeds or fails and then display a full message with title and progress and status. This is in part facilitated by a boolean field for when to display a welcome message, set to true upon loading and to false upon a message being displayed.
If achievements were disabled but a player token is in settings, prior to this change the Achievement Manager dialog would show a box with no player name and score zero, which is unnecessary.
Due to an oversight in our CMakeLists, pkg-config would attempt to find *minizip* 3.0.0 (which doesn't exist) instead of *minizip-ng* 3.0.0, or at least it was on my Manjaro Linux machine. This has been fixed. The new submodule is using minizip-ng 3.0.4, the same version that was being used before.
NetBSD doesn't put packages in /usr/local like /CMakeLists.txt thought.
The `#ifdef __NetBSD__` around iconv was actually breaking compilation
on NetBSD when using the system libiconv (there's also a GNU iconv
package)
A C program included from C++ source broke on NetBSD specifically, work
around it.
This doesn't fix compilation on NetBSD, which is currently broken, but
is closer to correct.
967280f140 broke linking against
libLLVM.so because it used the outdated way to link against LLVM from
CMake. This causes a compilation failure on systems that don't have the
LLVM static libraries, such as Arch Linux. On systems that have the
static libraries, it'll use them and increase binary sizes massively.
Switch to the newer llvm_config CMake macro from LLVM.
Previously the Achievements option would only show up if achievements were already enabled, requiring users to manually create a config file in the file system; this now makes it visible no matter what.
Bugfix for hardcore-disabled items being disabled when hardcore was true but achievement integration was false, which should mean hardcore is effectively disabled. Now everything checks the IsHardcoreModeActive method in AchievementManager which processes the setting AND the game state to determine if hardcore mode is actually active.
Spectator Mode is a new mode added by rc_client that allows for achievement and leaderboard functionality, but does not submit this data to the site, partially allowing for offline achievements. It effectively replaces the former settings for disabling achievements, leaderboards, and RP, which are now always active internally as long as the client is active.
The client can take care of itself and handle its own hardcore status when it toggles, so I can tell the settings widget to contact the manager directly to set it.
Also, gradually reorganizing the settings dialog over the next handful of commits.
The client can handle media changes natively so disabling can take place internally. This code uses the same external calls to load data, but will call either BeginLoad or BeginChangeMedia based on whether any media is already loaded.
Due to the client's handling of media changes (it simply disables hardcore if an unknown media is detected) the existing functionality for "disabling" the achievements is no longer necessary and can be deleted.
Two portions of this need updating.
Anything related to points and unlock counts and scoring uses game_summary now instead of the TallyScore method. Unfortunately this comes with the drawback that I cannot easily at this time access the number of points/unlocks from the other hardcore mode, so things like the second progress bar have been deleted.
Rich presence, which no longer needs to be stored, but can be calculated at request. As the AchievementHeader can now update just the Rich Presence, DoFrame can now simply call a header update with .rp=true and the current Rich Presence will be calculated immediately.
As the two items above are the last remaining things to use a number of the components in AchievementManager, this also deletes: Request V1 (V2 is renamed accordingly), ResponseType, PointSpread, TallyScore, UnlockStatus, and the RP generation and ping methods.
UpdateData in AchievementsWindow now only updates the components being requested, massively improving the window's performance. The parameter is UpdatedItems in AchievementManager, which tracks which portions of the system have been updated for every update callback.
Similarly to the Progress widget (though without the separate object for each box, because each Leaderboard unit is just three text fields stacked vertically), AchievementLeaderboardWidget.UpdateData will now accept three options: destroy all and rebuild, update all, or update a set of rows.
As part of this, AchievementManager::GetLeaderboardsInfo has been refactored to GetLeaderboardInfo to return a single leaderboard for the ID passed in.
AchievementProgressWidget maintains in memory a map of AchievementBox pointers so that UpdateData can operate on them individually. UpdateData is overhauled for three options: UpdateData(true) will destroy the entire list and re-create it from scratch as before, to be used if the game or player changes/closes/logs out. UpdateData(false) will loop through the map and call UpdateData on every achievement box, to be used for certain settings changes such as enabling badges or disabling hardcore mode. UpdateData(set<IDs>) will call UpdateData on only the IDs in the set, to be used when achievements are unlocked.
AchievementBox is an extension of QGroupBox that contains the data for a single achievement, initialized with the achievement data and able to reference AchievementManager to update itself.
While state loading is not allowed in the hardcore mode that most players will use, it is allowed in softcore mode; more importantly, if something fails to unlock or unlocks when it shouldn't in either mode the player can create a save that retains the current achievement state.
This is not a 1 to 1 relationship with how the events look primarily because currently achievement
progress messages are in OnScreenDisplay, which currently vanishes messages automatically.
As this covers the last remaining runtime-based event from the old event handler, that handler has been deleted and the new event handler has been renamed to take its place.
Up to four leaderboards are displayed in a window in the bottom right of the screen (vertically above challenge icons, if there are any). As per RetroAchievements standards, the markers only display the current leaderboard values with no further context necessary.
The active leaderboard data (leaderboards currently being attempted, which get displayed on screen) is now tracked. When a leaderboard is started its value is added to a vector (sorted by start frame). There are a separate set of client events specifically to handle leaderboard trackers, that are used to populate and manage this vector. The top portion of this vector (by RetroAchievement standards, the first four items) is exposed to be displayed on screen.
Also deletes the old runtime-based Achievement Triggered event from the old handler, and the methods used by it to publish to the server and reactivate/deactivate achievements in the runtime.
This change was primarily made to refactor the badge fetching to use the client instead of the runtime, but in the process I also refactored the code to cut down on complexity and duplication. Now the FetchBadge method is passed a function that generates the badge name; this is used to ensure that once the badge is loaded that it is still the desired badge to avoid race conditions.
HashGame has become LoadGame, similar structure with the file loaders but using the client instead. LoadGameCallback has been created to handle the results. The old LoadGameSync has been deleted as have
several hash and load methods that it called.
Deletes AchievementManager::Login, renames LoginAsync to Login, and replaces the one synchronous call in the AchievementSettingsWidget with the async call. There is a minor usability regression in that the UI currently does not notify the user when a login has failed; this will be addressed in a later change (possibly in a different PR).
On Windows 11, when playing windowed in a separate window/widget from the main emulator window, we don't want the window to have rounded corners, as it prevents the corner pixels from being visible
Also make the `Decrypt` method private.
As far as I can tell, the only motivation for exposing the `SetBytes`
and `Reset` methods is to allow `CBoot::SetupWiiMemory` to use the same
`SettingsHandler` instance to read settings data and then write it back.
It seems cleaner to just use two separate instances, and require a given
`SettingsHandler` instance to be used for either writing data to a
buffer or reading data from a buffer, but not both.
A natural next step is to split the `SettingsHandler` class into two
classes, one for writing data and one for reading data. I've deferred
that change for a future PR.
This is a JitArm64 version of 219610d8a0.
Due to limitations on how far you can jump with a single AArch64 branch
instruction, going above the former limit of 128 MiB of code (counting
nearcode and farcode combined) requires a bit of restructuring. With the
restructuring in place, the limit now is 256 MiB. See the new large
comment in Jit.h for a description of the new memory layout.
To ensure memory safety, callers of GetPointer have to perform a bounds
check. But how is this bounds check supposed to be performed?
GetPointerForRange contained one implementation of a bounds check, but
it was cumbersome, and it also isn't obvious why it's correct.
To make doing the right thing easier, this commit changes GetPointer to
return a span that tells the caller how many bytes it's allowed to
access.
This fourth part of my series of patches to get rid of unsafe uses of
GetPointer takes care of the "easy" cases in VideoCommon. Three uses of
GetPointer now remain in Dolphin: VertexLoaderManager, TextureInfo, and
the software renderer's TextureSampler.
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.
For some reason Linux is surprisingly slow at closing file descriptors
of event devices. This commit improves GUI startup times on my computer
by about 1.5 seconds.
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.
It was possible for sAlertMessageLock.notify() to be called before
sAlertMessageLock.wait(), causing Dolphin to deadlock. In particular,
this was guaranteed to happen if displayAlertMsg was called from the UI
thread while the emulation activity is being destroyed, because
runOnUiThread runs the passed-in anonymous function immediately when
called from the UI thread.
By replacing Object.wait/Object.notify with Semaphore.acquire/
Semaphore.release, it no longer matters what order the methods are
called in.
Because SettingViewHolder is used in RecyclerViews, we have to
explicitly unset STRIKE_THRU_TEXT_FLAG when we don't want it, otherwise
it might be left over from when the SettingViewHolder was representing
a different setting.
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.
Move CheatManager's child widgets into scroll areas to allow making the
window smaller than the default.
In CheatSearchWidget, enable word wrapping for the label describing the
address space and search type to help it fit better inside a narrower
window.
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.
This PR simply exposes the tapserver options in Serial Port 1 on Android. They already exist and work, but are not selectable. I've tested the tapserver options myself with Phantasy Star Online Episode I & II and they work fine.
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.
With this, I intend to make it clearer that Auto, Force 4:3, Force 16:9
and Custom are really the same thing, just with the aspect ratio of the
simulated TV being selected in a different way. I also extended the
introduction in a way I feel will clarify things but which you are
welcome to bikeshed :)
I was thinking of this during the review of 41b19e262f, but wanted to
put it in a separate PR as to avoid blocking it on bikeshedding.
I'm a bit unsure what to do about the word "analog" in "analog TV". I
felt that repeating it for each of these options would be too
repetitive. I suppose there's a reason why we used the word originally,
but digital TVs do give you basically the same aspect ratio for GC/Wii
games as analog TVs. (Of course, whether it's 4:3-like or 16:9-like
depends on what aspect ratio you set in the TV's settings, but that's
the case for widescreen CRTs too.)
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.
Cubeb logs a message at CUBEB_LOG_NORMAL verbosity every time you start
or stop a stream which can get a bit annoying when using frame advance
at Dolphin's default verbosity.
Window icon was missing from QDialog lacking a parent.
Giving the QDialog a parent revealed I had failed to make it properly non-modal, necessitating further changes.
Settings save less often, now only upon destruction.
Construction of BranchWatchDialog is now deferred.
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.
This takes care of making the image clearer in some edge cases where the game was already running at near perfect
4:3 with no stretching, and the VI aspect ratio didn't match the XFB by one pixel, making the image stretched and blurry.
-Video: Fix `FindClosestIntegerResolution() using the window aspect ratio and not the draw aspect ratio, causing it to prefer
stretching over black bars in cases when it wasn't desirable.
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.
* Fix irregularly shaped corners
* Remove extra space for BalloonTips with no message or no title
* When the target tip location is not on a screen, put the tooltip on
the mouse's screen instead of the primary screen
* Fix description getting cut off when the title was too long
* Expose border width as a parameter
* Fix spacing and sizing issues with larger border widths
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.
Use "bzip2" instead of "bzip" in optparse's compression choices for the
convert command. This is both more accurate and matches what the
ParseCompressionTypeString function expects.
The mismatch between the two parsing functions prevented compression
using bzip2 because either ParseCompressionTypeString or optparse would
generate an error when using "bzip" or "bzip2" respectively.
Fixes https://bugs.dolphin-emu.org/issues/13427
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.
When performing a default compilation with recent GCC & glibc,
the use of -Werror=nonnull causes a build error.
The error is given as IOFile::ClearError() can call std::clearerr()
with a null file, which can trigger a null-pointer dereference in libc.
Change the std::clearerr() call to be conditional on a file being open.
Google Play's policies require us to tell the user the size of any large
download.
The size seems to vary by just a megabyte or two across regions in my
testing, so I'm listing a rough size for all the regions.
I'm also taking the opportunity to shorten the message to make it easier
to read.
Because the wording of the Load Wii System Menu string can change
depending on the contents of the NAND, we should update that menu item in
a method that's guaranteed to get called every time the user opens the
menu rather than one that's only guaranteed to be called once.
Unlike ADD (immediate), MOV (register) treats SP as ZR. Therefore the
ADDI2R optimization that was added in 67791d227c can't optimize ADD to
MOV when exactly one of the registers is SP.
There currently isn't any code in Dolphin that calls ADDI2R with
parameters that would trigger this case.
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.
After reading the previous commit, you might think "hold on, what's the
difference between GetProfileName and GetProfileDirectoryName"? These
two are being used for the exact same thing - figuring out where
profiles are stored - yet they return different values for certain
controllers like GC keyboards! As far as I can tell, the existing code
has been broken for GC keyboards since they were introduced a decade
ago. The GUI (and more recently, also InputCycler) would write and read
profiles in one location, and our code for loading profiles specified in
a game INI file would read profiles in another location.
This commit gets rid of the set of values used by the game INI code in
favor of the other set. This does breaking existing setups where a
GCKey profile has been configured in a game INI, but I think the number
of working such setups is vanishingly small. The alternative would make
existing GCKey profiles go missing from the profile dropdown in the GUI,
which I think would be more disruptive. The alternative would also force
new GCKey profiles into the same directory as GCPad profiles.
This commit also fixes a regression from d6c0f8e749. The Android GUI was
using GetProfileName to figure out what key to use in the game INI,
which made it use incorrect game INI entries for GameCube controller
profiles but not Wii Remote profiles. Now the Android GUI uses
GetProfileKey for this, fixing the problem.
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.
Makes the hash specialization a little less noisy. Also we mark it
noexcept, since hashes shouldn't be throwing exceptions (and this can be
optimized on).
Allows using keys that aren't directly std::string as the key. This lets
us use std::string_view for the incoming path name, making it more
flexible with other string types.
JosJuice