This reverts commit 72cf2bdb87.
SYSCONF settings are getting cleared when they shouldn't be. Let's
revert the change until I get proper time to figure out why it's broken.
Whenever a request to update the Rich Presence comes in, typically every ten seconds, the Achievement Progress Widget will update the sort order of the achievements and all of their measured values.
bugfix: SetQWidgetWindowDecorations(this); not called before show() for Windows darkmode titlebars.
The actual call to (QWidget) show() needed to come sooner. Show() was originally left alone, but with other checks needing to move with (QWidget) show(), this function became less useful. Show() was originally created to fix the render widget appearing behind the main window, but that appears to work fine in this iteration.
The measured_progress C string for achievements to display potentially contains junk data after the null terminator, which was rendering in the QString in the dialog. This trims those junk characters.
This causes Dual Core to lock up during the boot sequence, because it tries to wait for a not-yet-running GPU thread.
Fixes https://bugs.dolphin-emu.org/issues/13559
rc_client calls the provided memory peeker asynchronously in the callback for starting a session, to validate/invalidate the memory used for achievements. Dolphin cannot access memory from any thread but host or CPU so this access has a small chance of being invalid. This commit adds a MemoryVerifier that the AchievementManager will use to perform this, before changing the peek method back to the original MemoryPeeker for normal operation.
Some pieces of code are calling IsRunning because there's some
particular action that only makes sense when emulation is running, for
instance showing the state of the emulated CPU. IsRunning is appropriate
to use for this. Then there are pieces of code that are calling
IsRunning because there's some particular thing they must avoid doing
e.g. when the CPU thread is running or IOS is running. IsRunning isn't
quite appropriate for this. Such code should also be checking for the
states Starting and Stopping. Keep in mind that:
* When the state is Starting, the state can asynchronously change to
Running at any time.
* When we try to stop the core, the state gets set to Stopping before we
take any action to actually stop things.
This commit adds a new method Core::IsUninitialized, and changes all
callers of IsRunning and GetState that look to me like they should be
changed.
Core::GetState reads from four different pieces of state: s_is_stopping,
s_hardware_initialized, s_is_booting, and CPUManager::IsStepping.
I'm keeping that last one as is for now because there's code in Dolphin
that sets it directly, but we can unify the other three to make things
easier to reason about.
This commit also gets rid of s_is_started. This was previously used in
Core::IsRunningAndStarted to ensure true wouldn't be returned until the
CPU thread was started, but it wasn't used in Core::GetState, so
Core::GetState would happily return State::Running after we had
initialized the hardware but before we had initialized the CPU thread.
As far as I know, there are no callers that have any real need to know
whether the boot process is currently initializing the hardware or the
CPU thread. Perhaps once upon a time there was a desire to make the
apploader debuggable, but a long time has passed without anyone stepping
up to implement it, and the way CBoot::RunApploader is implemented makes
it rather difficult. So this commit makes all the functions in Core.cpp
consider the core to still be starting until the CPU thread is started.
When AchievementProgress::UpdateData(false) is called, it will now empty itself and reinsert all existing boxes, re-sorted into their current buckets, and call UpdateProgress on them all.
Rerendering the entire Achievements dialog every EmulationStateChanged signal is far too often when it turns out that signal fires multiple times to confirm game close, for example. This change results in only the settings changing on EmulationStateChanged, and having the Hardcore mode toggle (which DOES require redrawing the entire dialog) emit its own signal alongside EmulationStateChanged.
AchievementBox now has UpdateData and UpdateProgress, which is called from UpdateData, but may be called elsewhere to update just the progress measurement of the achievement.
CPU Clock Override slider now increments 1% in the UI, with the new lower limit
being 1% instead of 6%.
Prior implementation made it impossible to set exactly 150% in the GUI.
147% -> 152%. Now users can set exact clock % without needing to edit INIs.
rc_client provides basic sorting buckets as a possible option when retrieving the list of achievements or leaderboards; this enables them and labels them in the dialog.
Since rcheevos headers are included in AchievementManager.h, and everyone that depends on Core can include that, we must also pass on the include directory and defines to those dependencies
If an icon is displayed on screen before it downloads, it was displaying a default icon but it would fail to load the actual icon even after it was downloaded. This fixes that.
Add a two second timer to Achievement Progress Indicators to wait until two seconds after the previous message (when it should have decayed out automatically) before posting any new ones.
Prior to this change, attempting to decrease the speed limit below 100% in hardmode would display the new attempted speed and then warn that the speed can not be decreased below 100%; this disables that first message under those conditions.
AchievementManager maintains a unique pointer to a copy of the current volume so it can asynchronously hash that volume. It is not needed otherwise, so I can release that pointer when hashing is complete. This change fixes a bug whereby changing discs in a game and then changing to a different game would result in the loaded volume pointer still being loaded with and hashing to the previous game.
We currently have 32 different binaries containing unit tests. At least
when I build for Android, each one takes up over 200 MiB, and linking
them all increases my incremental build times by over a minute. I'd
like to change this for the sake of my productivity and disk space.
For reference, MSBuild is already putting all tests in a single binary.
This lets us reduce the number of USE_RETRO_ACHIEVEMENTS ifdefs in the
code base, reducing visual clutter. In particular, needing an ifdef for
each call to IsHardcodeModeActive was annoying to me. This also reduces
the risk that someone writes code that accidentally fails to compile
with USE_RETRO_ACHIEVEMENTS disabled.
We could cut down on ifdefs even further by making HardcodeWarningWidget
always exist, but that would result in non-trivial code ending up in the
binary even with USE_RETRO_ACHIEVEMENTS disabled, so I'm leaving it out
of this PR. It's not a lot of code though, so I might end up revisiting
it at some point.
Right now, we assign a versionCode to each Android build of Dolphin by
counting the total number of git commits made. This has worked fine so
far, but it won't work as-is for the new release process.
Let's say we're currently on commit 20000. If we want to create a
release under the new release process, we would create a release branch,
add a new commit on it that updates the release name in CMake files and
so on, and create a tag for that commit. The Android build of this
release commit would get the version code 20001. However, the master
branch is also going to get a commit with the version code 20001 sooner
or later, and this commit would be an entirely different commit than
commit 20001 on the release branch. This isn't much of a problem for
people downloading Dolphin from dolphin-emu.org, but it's a big problem
for Google Play, as Google Play doesn't allow us to upload two builds
with the same version code.
This commit makes us calculate the Android version code in a new way:
The number of commits times two, and if the current build isn't a
release build, plus 1. (We check whether the current build is a release
build by checking whether there's a tag for the current commit.)
With this new version code scheme, the release commit described in my
example would get the version code 40002, and the master commit would
get the version code 40003. This lets us upload both corresponding
builds to Google Play, and also lets the user switch from the release
build to the development build if they would like to. (Under normal
circumstances, Android forbids installing a build with an older version
code than the currently installed build. Therefore, whether the 1 is
added for release builds or for development builds is a decision with
consequences.)
Enable emulator hotkeys and controller input (when that option is
enabled) when a TAS Input window has focus, as if it was the render
window instead. This allows TASers to use frame advance and the like
without having to switch the focused window or disabling Hotkeys Require
Window Focus which also picks up keypresses while other apps are active.
Cursor updates are disabled when the TAS Input window has focus, as
otherwise the Wii IR widget (and anything else controlled by the mouse)
becomes unusable. The cursor continues to work normally when the render
window has focus.
Using shifts and bit tests makes the code unnecessarily annoying to
reason about. I'm replacing it with subtracting from 3 to translate the
bit order from the PowerPC format to the usual format.
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.
iwubcode