GenerateRichPresence calls rc_runtime_get_richpresence in rhceevos on the achievement runtime to get the current Rich Presence string, a description of the player's current in-game state based on its memory as fed into a custom-developed script downloaded via FetchGameData. This gets passed into PingRichPresence, but is separated into its own method so it can be used elsewhere locally.
MemoryPeeker is a function passed by pointer into rcheevos DoFrame functionality that forms the lynchpin of the rcheevos runtime - it provides the interface by which rcheevos accesses memory and determines if the fields provided by achievement, leaderboard, and rich presence definitions are meeting the criteria needed.
AchievementEventHandler simply checks which kind of event is triggered and calls the appropriate function. Its primary purpose is as a function to be pointed to.
HandleAchievementTriggeredEvent is an asynchronous method that processes an event and places a synchronous AwardAchievement call on the work queue. In the process, it also updates the unlock map and makes the ActivateDeactivateAchievement call to determine and adjust the achievement's current active state.
PingRichPresence makes a "ping" API request to the RetroAchievements website with the provided RichPresence string parameter. While there has been talk about tying ping in with session, in its current state the primary purpose of ping is to send the player's Rich Presence to the website.
AwardAchievement performs the API call to notify the site that an achievement has been unlocked. As one of the parameters is the game hash (something I overlooked previously; I thought it was the game ID) this change also moves the game hash into a member field.
This reads Steam Deck controls bypassing Steam Input. This allows for access to
motion controls as well as independent access to thumb sticks, trackpads, and
back grip buttons.
These games seem to constantly have unused vertices, and this is worst shown in the Shadow Pokemon purification cutscene. The Shadow Pokemon purification cutscene is even worse on XD with forced single core mode, as instead of having FPS dropping with VPS staying 60ish, it will drop both, resulting in audio stuttering. Turning on CPUCall seems to have a 7/8 reduction of draw calls for that cutscene (~800 -> ~100), doubling performance. Many other areas of the game seem to benefit from this setting too, having some kind of performance boost.
See https://bugs.dolphin-emu.org/issues/13248. This is needed for the menus to work properly (not run at 1FPS and render incorrectly). Additionally, immediate XFB causes flickering.
This reverts commit cfe3683668.
On Windows systems with 125% DPI scaling, this was causing both icons
and the OSD to be upscaled by 25% using nearest neighbor scaling, which
looks really bad. shuffle2 has said that this will be improved later,
but we should revert it for now for the sake of the upcoming beta build.
The old tooltip description box used GraphicsWidget to provide shared
code to the Graphics config panes for adding descriptions to their
settings.
The description box has been replaced by BalloonTips and serves no
further purpose, so remove it and have the Graphics panes derive from
QWidget instead.
GraphicsInteger is used by the panes in the Graphics config window to
create spin boxes that change their associated config setting, and
update their own state when something else changes the config setting.
Despite its current name nothing about this class is particular to the
Graphics window, so renaming it to ConfigInteger better reflects its
purpose. This should also make it less confusing when ConfigIntegers
are added to other config windows.
