Should fix https://bugs.dolphin-emu.org/issues/13178.
Jit64 doesn't need to do this because it stores PC directly into
ppcState instead of first storing it in a register.
Now block link nearcode is back to a length of three instructions.
Unfortunately, the code I'm adding to Jit.cpp ends up being a bit messy
because we need to handle the case of already being in farcode...
Jumping between linked blocks currently works as follows: First, at the
end of the first block, we check if the downcount is greater than zero.
If it is, we jump to the `normalEntry` of the block. So far so good. But
if the downcount wasn't greater than zero, we jump to the `checkedEntry`
of the block, which checks the downcount *again* and then jumps to
`do_timing` if it's less than zero (which seems like an off by one error
- Jit64 doesn't do anything like this). This second check is rather
redundant. Let's jump to `do_timing` where we previously jumped to
`checkedEntry`.
Jit64 doesn't check the downcount on block entry. See 5236dc3.
I initially thought the 0x01 side was both sides (equavalent to just C. However, this turned out to be something I forgot I implemented in my personal interface. 0x01 does not seem to change any colors.
Recently discovered how exactly the last 2 bytes of the J command for timing data
using portmapping with hosting while using traversal server (which is possible by checking the option while under "direct connect" and flipping back to traversal server) causes dolphin to request a mapping to external port 0.
In UPnP a mapping to external port 0 is actually the wildcard, which means that connection requests on all
external ports (that are not otherwise mapped) will be forwarded to the client.
Additionally it seems like using port mapping with traversal server is probably not expected behavior, as the option checkbox disappears when traversal server is used.
Dolphin no longer supports Windows 7, so the fact that there are (were?)
more people who use Windows 7 than who use a GPU that doesn't support
the required feature is no longer relevant.
By misusing Config, this netplay-related code opened up a race condition between Config::OnConfigChanged() and SerialInterface::SerialInterfaceManager::UpdateDevices() that could cause iterator invalidation.
GCAdapter::UseAdapter() reads s_is_adapter_wanted, which gets
initialized by config_guard.~ConfigChangeCallbackGuard(). So we must
wait until after destroying the config guard to know whether we have any
controllers set to GC Adapter.
Expanded the use of the lock mutex already used for loading the player's existing unlock status to guard against races involving the Achievements dialog window reading from data AchievementManager might be in the process of updating. The lock has been exposed publicly and the AchievementsWindow uses it in its UpdateData method, and anywhere else that might modify data used to render that window has also been wrapped with it.
AchievementManager now has a SetUpdateCallback method for providing a single universal callback for anytime something important changes in the achievement state, such as logging in/out, game load/close, or events such as achievement unlocks. AchievementsWindow sets this callback in its own init to its UpdateData method so that the AchievementsWindow gets updated when one of these changes takes place.
This widget is a tab in the AchievementsWindow that displays the player's current achievement progress: which achievements are locked or unlocked, and the progress of achievements that have progress metrics.
This widget displays a header on the AchievementsWindow dialog above the tabs that shows the currently logged in user (if there is one) and the game they are playing (if there is one).
Added some small methods to AchievementManager to expose useful data for displaying in an achievement UI. Also moved a couple things from private to public for the same purpose.
1 ) When first opened, the (user selected) post process shader config widget would print the wrong values on the text label next to int range sliders. For example if the range was from 1 to 6, and the value loaded from the config was 1, the label would print 0 when first opened, to then start showing the correct value once the slider was first moved.
This mirrors the behaviour of the float slider code below:
```auto* const value_box = new QLineEdit(QString::asprintf("%f", m_config_option->m_float_values[i]));```
2 ) The defautl int slider value would also be set wrong on first load, as it was being divided by the slider max instead of the slider step amount (again, just like for the float implementation). This is a mistake I had made with my previous submission.
The ExpansionInterfaceManager::PauseAndLock function does nothing but
call other functions that have no effect.
ExpansionInterfaceManager::PauseAndLock calls CEXIChannel::PauseAndLock,
which in turn calls IEXIDevice::PauseAndLock. None of the classes
deriving from IEXIDevice override PauseAndLock, and the implementation
in IEXIDevice does nothing.
Fixing all the places it's used turned out to be a more complicated task than anticipated. So let's remove this for now so we don't confuse users with cryptic error messages...
To further increase the accuracy of the post process phase, I've added (scRGB) HDR support, which is necessary
to fully display the PAL and NTSC-J color spaces, and also to improve the quality of post process texture samplings and
do them in linear space instead of gamma space (which is very important when playing at low resolutions).
For SDR, the quality is also slightly increased, at least if any post process runs, as the buffer is now
R10G10B10A2 (on Vulkan, DX11 and DX12) if supported; previously it was R8G8B8A8 but the alpha bits were wasted.
Gamma correction is arguably the most important thing as Dolphin on Windows outputted in "sRGB" (implicitly)
as that's what Windows expects by default, though sRGB gamma is very different from the gamma commonly used
by video standards dating to the pre HDR era (roughly gamma 2.35).
Additionally, the addition of HDR support (which is pretty straight forward and minimal), added support for
our own custom AutoHDR shaders, which would allow us to achieve decent looking HDR in Dolphin games without
having to use SpecialK or Windows 11 AutoHDR. Both of which don't necessarily play nice with older games
with strongly different and simpler lighting. HDR should also be supported in Linux.
Development of my own AutoHDR shader is almost complete and will come next.
This has been carefully tested and there should be no regression in any of the different features that Dolphin
offers, like multisampling, stereo rendering, other post processes, etc etc.
Fixes: https://bugs.dolphin-emu.org/issues/8941
Co-authored-by: EndlesslyFlowering <EndlesslyFlowering@protonmail.com>
Co-authored-by: Dogway <lin_ares@hotmail.com>
There's nothing going on with behavior here that would prevent these
from being const qualified.
Also better communicates that this function isn't intended to modify the
given resource pack.
We want to have a low number of instructions between the LDP and the
MADD so that the MADD can start immediately after the LDP finishes
even if we're on a lower-end in-order CPU.
Replace the bool parameter force5bytes in J, JMP, and J_CC with an enum
class Jump::Short/Near. Many callers set that parameter to the literal
'true', which was unclear if you didn't already know what it did.
The base DebugInterface now depends on the Core's CPUThreadGuard, and
utilities in Common shouldn't be depending on Core facilities. So, we
can move this into the core library instead.
This doesn't need to be handled by translators, since they're not
user-displayed text or just don't need to be translated.
While we're at it, we don't need to copy each entry of the resulting
list.
We can utilize the fact that if swapping two instructions causes another
swap to become possible, that swap involves one of the two instructions
we just swapped. There's need to search for new swap opportunities as
far back as the beginning of the block; we can just go one step back.
Mesa (llvmpipe) only reports 4x MSAA, and doesn't report 2x (or 1x, but we implicitly add that). The old logic did not handle this correctly, causing selecting 4x to fail and fall back to None.
This also removes VideoUtils::GetAvailableAntialiasingModes, and thus VideoUtils entirely, as its only other function was removed in 1f74653501.
We can move the construction of the Diff instance into the body of the
if statement, so that we only construct this if the condition is true.
While we're at it, we can move the symbol description string into the
instance, getting rid of a copy. The function itself can also be const
qualified.
-An assert would be erroneously thrown when shaders declared an array of 4 int or float options, despite 4 being the max supported (a simple <= / < mistake)
-When changing the type of a shader option (e.g. from bool to float), the serialization would be stuck appending the value from the previous option type, making the shader fail to build permanently until the cache were cleaned
DX12 would often crash when starting and stopping the emulation many times, due to the device enumerator failing for some reason. Checking for success fixes it.
I've received a report from an Android user with a gamepad (a "BSP-D3")
where one physical trigger is controlling two analog axes at the same
time. This was causing RemoveSpuriousTriggerCombinations to delete both
axes, which is clearly not a desireable outcome.
With this change, now the axis with the greatest smoothness is kept,
or both in case they have the same smoothness.
Adds features to improve navigation of Skylanders portal menu, includes:
-List of Skylanders and filters for searching
-Improved buttons for faster loading options
-Added default user folder for storing .sky files
To maintain compatibility with some video encoders, the whole output buffer was scaled to be a multiple of 4.
This change makes it so that that rule only applies while actively recording (or taking screenshots, even if it might not be necessary for that case).
Somewhere in the process of getting the memory peeking right for achievements, the AchievementManager call to DoFrame went missing. This restores it properly.
AchievementSettingsWidget is a dialog widget in AchievementsWindow for handling RetroAchievements settings in the user interface. This class contains the physical layout, widget connections, load/save functions and button responses. AchievementsWindow now has a tabbed list that this is inserted into; other tabs will be in a later pull request.
AchievementsWindow is the dialog box that will eventually contain the settings and progress data for RetroAchievements on Dolphin. This adds the barebones dialog, and connects it to MainWindow's MenuBar.
Enable through command line options:
-C Graphics.Settings.TexturePNGCompressionLevel=[0-9]
Or from GFX.ini:
[Settings]
TexturePNGCompressionLevel=[0-9]
@see #10792
Fixing a bug with the RetroAchievements integration where certain combinations of configurations would result in a malformed API request and an attempt to dereference the null response.
AMD Metal drivers have a goofy bug where the bbox buffer stops being coherent with the cpu if you copy to it from a private (gpu) buffer and don't do anything else with it in that command buffer.
Adds two new hotkeys to open the menus for emulated USB devices- Skylanders Portal of Power and the Infinity Base. (Hotkeys only active when game is running).
Portal menu: Default is <Ctrl+P>.
Infinity base: Default is <Ctrl+I>
-The float sliders initial value wasn't calculated correctly
-Fix the checkbox dependencies not being applied until a setting was changed for the first time
Added OnScreenDisplay messages to HandleAchievementTriggeredEvent to display an extra congratulations message if the player has completed (unlocked all achievements in casual) or mastered (unlocked all achievements in challenge) the game. This also uses the display name retrieved when verifying credentials, which has now been added as a member field on AchievementManager.
Added an OnScreenDisplay message to LoadGameByFilenameAsync to display a message when a player starts a game with achievements, notifying them of their current score. The score displayed is challenge points if the player is in challenge mode or challenge + casual if the player is in casual mode. A second message tells the player which mode they are in. To match RetroAchievements' website interface, the messages are blue for casual and gold for challenge.
Added a TallyScore method to AchievementManager to calculate the player's current scores (soft and hard) against the total number of points across all achievements. Includes a PointSpread structure to hold all points and counts. The Unlock Map now includes point values for each achievement to aid in this calculation; this is populated at insert time, and Unofficial achievements are tallied as zero.
Added HandleLeaderboardStartedEvent with an OnScreenDisplay message when a player has triggered a leaderboard's failure conditions. The message includes the title of the achievement.
Added HandleLeaderboardStartedEvent with an OnScreenDisplay message when a player has triggered a leaderboard's start conditions. The message includes the title of the achievement.
Added an OnScreenDisplay message to HandleLeaderboardTriggeredEvent to display a message when a player has completed a leaderboard. The message includes the title of the achievement and the player's score/time.
Added an OnScreenDisplay message to HandleAchievementTriggeredEvent to display a message when a player has unlocked an achievement. The message includes the title of the achievement and its point value based on the game data. To match RetroAchievements' website interface, the message is blue if the unlock is casual and gold for challenge.
This warning came about after 46ad8b9d68
In file included from /home/ports/pobj/dolphin-5.0.0.20230429/dolphin-5.0.0.20230429/Source/Core/Core/IOS/WFS/WFSI.cpp:4:
/home/ports/pobj/dolphin-5.0.0.20230429/dolphin-5.0.0.20230429/Source/Core/Core/IOS/WFS/WFSI.h:54:6: warning: private field 'm_aes_key' is not used [-Wunused-private-field]
u8 m_aes_key[0x10] = {};
^
By using a shm memory segment for the fast_block_map that is sparsely
allocated (i.e. on write by the OS) instead of a statically allocated
array we can make the block lookup faster by:
* Having a bigger space available for lookup that doesn't take up
too much memory, because the OS will only allocate the needed
pages when written to.
* Decrease the time spent to lookup a block in the assembly dispatcher
due to less comparisions and shorter code (for example the pc check
has been entirely dropped since only the msrBits need to be validated).
When the JIT block cache is full the shm segment will also be released
and reallocated to avoid allocating too much memory. It will also be
reset when the instruction cache is flushed by the PPC code to avoid
having stale entries.
Also fallback to the original method in case the memory segment couldn't
be allocated.
A comment removed by this commit gives two reasons for listening to
slave devices, both of which no longer apply:
- "Only slaves emit raw motion events": perhaps this was true when the
comment was written, but now master devices provide raw motion events
along with the other raw events.
- "Selecting slave keyboards avoids dealing with key focus": we get raw
key events regardless of the focus.
Listening to both master and slave devices results in duplicate raw
events. For button and key events, that's a tiny waste of time setting
the update flag a second time, but for raw mouse events the raw motion
will be processed twice. That makes this commit a user-facing change.
In X, the ButtonPress events generated when a mouse button is pressed
have a special property: if they don't activate an existing passive
grab, the X server automatically activates the "implicit passive grab"
on behalf of the client the event is delivered to. This ensures the
ButtonRelease event is delivered to the same client even if the pointer
moves between windows, but it also causes all events from that pointer
to be delivered exclusively to that client. As a consequence of the
implicit passive grab, for each window, only one client can listen for
ButtonPress events; any further listeners would never receive the event.
XInput 1 made the implicit grab optional and explicit by allowing
clients to listen for DeviceButtonPress events without
DeviceButtonPressGrab events. XInput 2 does not have a separate grab
event class, but multiple clients can listen for XI_ButtonPress on the
same window. When a button is pressed, the X server first tries to
deliver an XI_ButtonPress event; if no clients want it, then the server
tries to deliver a DeviceButtonPress event; if no clients want it, then
the server tries to deliver a ButtonPress event. Once an event has been
delivered, event processing stops and earlier protocol levels are not
considered. The reason for this rule is not obviously documented, but
it is probably because of the implicit passive grab; a client receiving
a ButtonPress event assumes it is the only client receiving that event,
and later protocols maintain that property for backward compatibility.
Before this commit, Dolphin listened for XI_ButtonPress events on the
root window. This interferes with window managers that expect to
receive ButtonPress events on the root window, such as awesome and
Openbox. In Openbox, applications are often launched from a menu
activated by clicking on the root window, and desktops are switched by
scroll wheel input on the root window. This makes normal use of other
applications difficult when Dolphin is open (though Openbox keyboard
shortcuts still work). Conversely, Dolphin only receives XI_ButtonPress
events for clicks on the root window or window decorations (title bars),
not on Dolphin's windows' content or the render window. In window
managers that use a "virtual root window" covering the actual root
window, such as Mutter running in X, Dolphin and the window manager do
not conflict, but clicks delivered to other applications using XInput2
(for testing, try xinput --test-xi2) are not seen by Dolphin, which is
relevant when background input is enabled.
This commit changes Dolphin to listen for XI_RawButtonPress (and the raw
versions of other events); Dolphin was already listening to XI_RawMotion
for raw mouse movement. Raw events are always and exclusively delivered
to the root window and are delivered to every client listening for them,
so Dolphin will not interfere with (or be interfered with by) other
applications listening for events.
As part of being raw, button numbers and keycodes in raw events have not
had mapping applied. If a left-handed user swapped the left and right
buttons on their mouse, raw events do not reflect that. It is possible
to query the mappings for each device and apply them manually, but that
would require a fair amount of code, including listening for mapping
changes.
Instead, Dolphin now uses the events only to set a "changed" flag, then
queries the current button and key state after processing all events.
Dolphin was already querying the pointer to get its absolute position
and querying the keyboard to filter the key bitmap it created from
events; now Dolphin also uses the button state from the pointer query
and uses the keyboard query directly.
Queries have a performance cost because they are synchronous requests to
the X server (Dolphin waits for the result). Commit 2b640a4f made the
pointer query conditional on receiving a motion event to "cut down on
round trips", but commit bbb12a75 added an unconditional keyboard query,
and there have apparently been no performance complaints. This commit
queries the pointer slightly more often (on button events in addition to
motion), but only queries the keyboard after key events, so the total
rate of queries should be substantially reduced.
Fixes: https://bugs.dolphin-emu.org/issues/10668
We need XInput 2.1 to get raw events on the root window even while
another client has a grab. We currently use raw events for relative
mouse input, and upcoming commits will use raw events for buttons and
keys.
FSCore implements the core functionality that can also be used outside of emulation. FSDevice implements the IOS device and is only available during emulation.
ESCore implements the core functionality that can also be used outside of emulation. ESDevice implements the IOS device and is only available during emulation.
DoFrame is a function called every frame by the emulator so that rcheevos can be properly updated and processed. It requires a memory peeker and an event handler to be passed in; the memory peeker is called repeatedly each frame to measure what's in memory and compare to achievement definitions, and any events thrown by that comparison are sent to the event handler.
Also, DoFrame checks for the current system time to determine when to ping rich presence. Rich Presence on the RetroAchievements website updates every two minutes, so if two minutes have elapsed since the previous ping, another ping is sent.
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.
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.
This fixes a crash I found in the Request function of AchievementManager where under certain conditions init_request would return an api_request with null post data, and Post would crash if it attempted to access it. Now the function aborts before the Post and returns an INVALID_REQUEST response type.
GraphicsSlider is used by the panes in the Graphics config window to
create sliders 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 ConfigSlider better reflects its
purpose. This should also make it less confusing when ConfigSliders are
added to other config panes.
GraphicsRadioInt is used by the panes in the Graphics config window to
create radio buttons 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 ConfigRadioInt better reflects its
purpose. This should also make it less confusing when ConfigRadioInts
are added to other config panes.
m_xrr_config was used by the GeneralWidget::GetAvailableResolutions
function to get the list of supported fullscreen resolutions when
HAVE_XRANDR was set. aa4088a removed the ability to set that resolution
in the UI, leaving the GetAvailableResolutions function unused.
m_xrr_config is initialized in MainWindow which still uses it to toggle
fullscreen, but the references in GeneralWidget and GraphicsWidget
(which just ferried m_xrr_config from MainWindow to GeneralWidget) are
now unnecessary and removed in this commit.
Fixes dynamically changing dpi scaling.
Load resources from svg if possible.
Currently svg support is not in Qt build in Externals,
and image files need to be added later.
GraphicsChoice is used by the panes in the Graphics config window to
create combo 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 ConfigChoice better reflects its
purpose. This should also make it less confusing when ConfigChoices are
eventually added to the other config windows.
QApplication should parse and remove and args it recognizes
before dolphin starts inspecting the args.
This allows using e.g. -style <style> on the commandline.
PR #11183 regressed the lookup table reconstruction and, for some reason, added an else clause that clobbered the dCache whenever dCache emulation is turned on.
GraphicsBool is used by the panes in the Graphics config window to
create checkboxes 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 ConfigBool better reflects its
purpose. This should also make it less confusing when ConfigBools are
eventually added to the other config windows.
In older versions of Dolphin GraphicsBoolEx was used to create a pair of
radio buttons selecting one of Virtual XFB and Real XFB, but this was
removed with the introduction of Hybrid XFB in 65cd085f.
In the meantime GraphicsRadioInt was introduced to allow for Graphics
radio buttons with multiple options, so GraphicsBoolEx is now redundant.
Previously this was using the default deleter (which just calls delete
on the pointer), which is incorrect, since the ENetHost instance is
allocated through ENet's C API, so we need to use its functions to
deallocate the host instead.
Before, any call of Settings::SetDebugModeEnabled(true) would show it. This means that if the debugging UI is enabled, but the user manually closed the code widget, then toggling any option on the interface pane (such as "Pause on Focus Loss") would cause the code widget to reappear. Additionally, closing and reopening dolphin did not call SetDebugModeEnabled, so the code widget did not reappear in that case (it only appeared after touching the interface pane). This is a bit silly, so now only enabling the debugger does it.
This also somewhat resolves an inconsistency introduced by the previous commit: prior to it, --debugger would call SetDebugModeEnabled(true) and thus show the code pane; after these commits, it does not, as it acts like a config change. This is a behavior difference, but not a particularly important one.
Before, Settings::SetDebugModeEnabled was used; this calls SetBaseOrCurrent() which will usually permanently change the base configuration setting for the debugger to true. Thus, the debugger would remain active even if the --debugger command line option was removed. Now, it remains active only for the current run, like other command-line options.
Note that SetBaseOrCurrent is also used by the "Show Debugging UI" option under Options -> Interface; this means that if the debugger is turned off (or off and then back on) by the user while --debugger is specified, this will be reset to whatever the base configuration had when Dolphin is closed and reopened. This behavior is consistent with the rest of the UI.
To my understanding, the --debugger option is something from 5.0 stable/DolphinWx where there was no way to toggle the debug UI in the settings (and the command-line option was the only way of enabling it). It's less useful nowadays.
This isn't used anywhere and not really a generic utility, so we can get
rid of it.
This also lets us remove MathUtil.cpp, since this was the only thing
within that file.
RetroAchievements Rich Presence is a script that is run periodically on a game's memory to provide a detailed text description of what the player is doing. Existing Discord presence on Dolphin would update a player's Discord status to say not just that they are using Dolphin but that they are playing, for example, Sonic Adventure 2 Battle; Rich Presence would detail that the player is in City Escape with 5 lives and 142 rings.
Activating this in the runtime simply entails loading that text script, as returned by the FetchGameData API call, into the runtime, here only determined by whether rich presence is enabled in the achievement settings. Deactivating this is done via the same rcheevos method by setting the rich presence to an empty string.
This activates or deactivates leaderboards in the rcheevos runtime similarly to achievements. The logic is much more straightforward - all leaderboards are active together; there is nothing requiring some leaderboards to be active while others are unactive, and even a leaderboard that has been submitted to in this session is still active to be submitted to again. The only criteria are that leaderboards must be enabled in the settings, and hardcore mode must be on, the latter of which is false until a future PR.
LoadUnlockData and ActivateDeactivateAchievements are the public API components responding to the FetchUnlocks and A/DAchievement (singular) private methods.
LoadUnlockData is asynchronous and performs both a hardcore and a softcore unlock call, updating the unlock map and the active status of any achievements returned from these calls.
ActivateDeactivateAchievements calls ActivateDeactivateAchievement on every achievement ID found in m_game_data, initializing the unlock map for each ID if not already found.
Both of these are currently called in LoadGameByFilenameAsync once the game has been loaded properly. There's a lock around this, to ensure that the unlock map is initialized properly by ActivateDeactivate Achievements before FetchUnlockData makes modifications to it without stalling the async portions of FetchUnlockData.
FetchUnlockData is an API call to RetroAchievements that downloads a list of achievement IDs for a game that the user has already unlocked and published to the site. It accepts a parameter for whether or not hardcore or softcore achievements are being requested, so that must be provided as well. Once it has the requested list on hand, it updates each achievement's status in the unlock map and will activate or deactivate achievements as necessary.
ActivateDeactivateAchievement is passed an Achievement ID as returned from the FetchGameData API call and determines whether to activate it, deactivate it, or leave it where it is based on its current known state and what settings are enabled.
Activating or deactivating an achievement entails calling a method provided by rcheevos that performs this on the rcheevos runtime. Activating an achievement loads its memory signature into the runtime; now the runtime will process the achievement each time the rc_runtime_do_frame function is called (this will be in a future PR) to determine when the achievement's requirements are met. Deactivating an achievement unloads it from the runtime.
The specific logic to determine whether an achievement is active operates over many fields but is documented in detail inside the function. There are multiple settings flags for which achievements are enabled (one flag for all achievements, an "unofficial" flag for enabling achievements marked as unofficial i.e. those that have logic on the site but have not yet been officially approved, and an "encore" flag that enables achievements the player has already unlocked) and this function also evaluates whether the achievement has been unlocked in hardcore mode or softcore mode (though currently every reference to the current hardcore mode state is hardcoded as false).
XInput2 was created to support multiple pointer/keyboard pairs (often
called MPX for multi-pointer X). Dolphin's XInput2 implementation has
always supported MPX by creating a KeyboardMouse object per master
pointer. Since commit bbb12a7, Dolphin's keyboard state is filtered by
the output of XQueryKeymap. As a core X function, XQueryKeymap queries
"the" keyboard, which by default is the first master keyboard. As a
result, Dolphin will ignore keys pressed on other master keyboards
unless the first master is simultaneously pressing the same keys.
XInput2 doesn't provide a function to query the keyboard state. There
is no XIQueryKeymap and the current state is not a member of the
XIKeyClassInfo returned by XIQueryDevice. Instead, XInput2 allows a
master pointer to be nominated as "the" pointer on a per-client basis,
with "the" keyboard automatically becoming the associated master
keyboard. The "documentation" [1] says passing None for the window is
only for debugging purposes, but it is documented in the
XISetClientPointer man page and seems to be the only way to query
keyboards beyond the first.
With this commit, Dolphin correctly reads keys from keyboards other than
the first master keyboard. To test, use the xinput command-line utility
to create a master pointer and reattach a keyboard to the associated
master keyboard.
[1]: https://who-t.blogspot.com/2009/07/xi2-recipes-part-6.html
(the XInput2 developer's blog)
LoadGameByFilenameAsync sets up a volume reader and hashes the volume, then uses that hash to make the three consecutive API requests to resolve hash, start session and load game data.
CloseGame resets the m_is_game_loaded flag, wipes the queue, and destroys all the game data responses.
FetchGameData is the big one - this retrieves the logic for all the achievements, leaderboards, and rich presence, and all the relevant metadata for the game.
Added a call to the RetroAchievements Start Session API to AchievementManager. This is primarily for client-side activation, so it doesn't return much of value, aside from its success/error information, but I'm storing the return structure in case this changes in the future.
Added the ResolveHash method to AchievementManager. This is a blocking function to send a hash string to the RetroAchievements server to verify it and get a game ID back.
This was previously copying each pair out of the vector returned by
GetInterfaceListInternal() when we just need to emplace the first entry
of each pair.
Fixes us forgetting to add its include directories, which could result in linking to a dylib from MacPorts while using the system's header, and failing to link because they use different function names
bSupports2DTextureStorageMultisample is completely unused, while bSupports3DTextureStorageMultisample is practically unused. In the past, these were checked and fell back to sampler2DMS instead of sampler2DMSArray on GLES 3.1, but this path was removed in f039149198 and Dolphin always uses array textures now.
See https://bugs.dolphin-emu.org/issues/13232; this was introduced in 7dde0c3c31. Apparently, providing a parent for a widget that is not visible makes your new widget visible when the parent is later made visible, in addition to managing the deletion of the widget; the documentation does not specify this (only that if the parent is visible you need to explicitly show it).
The inst.SIMM_16 change is for readability (though it also fixes a warning about potentially unintended uses of `||`).
The fallback change is because `b` is only meaningful for indexed instructions; this could theoretically lead to unintended fallbacks (but it seems unlikely).
The m_checkbox_lock_mouse QCheckBox was only conditionally being added
to the layout, leaving it unmanaged and leaking
Setting the parent will allow it to be managed.
The m_verbosity_debug button was only conditionally being added as
widget, this was done in order to hide the object, but this left it
unmanaged.
Unconditionally adding it to the layout and controlling it's visibility
will resolve these issues
Added AchievementManager class. Upon startup (currently only in DolphinQt), logs into RetroAchievements with the login credentials stored in achievements.ini.
Co-authored-by: AdmiralCurtiss <AdmiralCurtiss@users.noreply.github.com>
Added AchievementSettings in Config with RA_INTEGRATION_ENABLED, RA_USERNAME, and RA_API_TOKEN. Includes code to load and store from Achievements.ini file in config folder.
The QByteArray returned by QString::toUtf8() was being freed so the char
pointer was pointing to freed memory.
Found via ASan, didn't notice any issues during normal runtime.
This was triggered after hitting a key combo with alt (ex. toggle
fullscreen) probably happens with others
This fixes a crash when recording fifologs, as the mutex is acquired when BPWritten calls AfterFrameEvent::Trigger, but then acquired again when FifoRecorder::EndFrame calls m_end_of_frame_event.reset(). std::mutex does not allow calling lock() if the thread already owns the mutex, while std::recursive_mutex does allow this.
This is a regression from #11522 (which introduced the HookableEvent system).
Adds the rcheevos library from RetroAchievements to the Dolphin Externals as a submodule. Change was verified to import correctly and build both via Visual Studio and via cmake ninja.
We have these for a reason. I think this also fixes a theoretical
problem when `ABI_PARAM1 == loop_counter` where the first MOV destroys
the second's value; I'm not sure if this can actually happen in practice
though.
Also works around a bug where CMake's ninja generator doesn't properly handle ||'s on POST_BUILD commands, making the || apply to the whole build like `<link> && custom0 || custom1`
Will manually controlling both an accelerometer and a gyroscope at the
same time be reasonable to do? No idea. Was this easy to implement
thanks to the input override system? Yes.
Fixes https://bugs.dolphin-emu.org/issues/12443.
In UpdateInput, lock m_devices_population_mutex before m_devices_mutex
to be consistent with other ControllerInterface functions. Normally the
former lock isn't needed in UpdateInput, but when a Wii Remote
disconnects it calls RemoveDevice which results in the mutexes being
locked in the wrong order.
This gets rid of a blocking operation, improving performance and fixing
https://bugs.dolphin-emu.org/issues/12893.
This also makes us no longer directly access the state of certain UI
elements from the CPU thread, which probably wasn't thread-safe but
doesn't seem to have caused any observable issues so far.
Up until now, there have been two settings on Android that stored the
selected Wii Remote extension: the normal one that's also used on PC,
and a SharedPreferences one that's used by the overlay controls to
determine what controls to show. It is possible for these two to end up
out of sync, and my input changes have made that more likely to happen.
To fix this, let's rework how the overlay controller setting works.
We don't want it to encode the currently selected Wii Remote extension.
However, we can't simply get rid of the setting, because for some Wii
games we need the ability to switch between a GameCube controller and a
Wii Remote. What this commit does is give the user the option to select
any of the 4 GameCube controllers and any of the 4 Wii Remotes. (Before,
controllers 2-4 weren't available in the overlay.) Could be useful for
things like the Psycho Mantis fight in Metal Gear Solid. I'm also
switching from SharedPreferences to Dolphin.ini while I'm at it.
It's missing a lot of features from the PC version for now, like
buttons for inserting functions and the ability to see what the
expression evaluates to. I mostly just wanted to get something in
place so you can set up rumble.
Co-authored-by: Charles Lombardo <clombardo169@gmail.com>
This is a small regression from KillRenderer, which caused duplicated
frames to be counted on the FPS counter when the "Skip Presenting
Duplicated Frames" option was disabled.
This way, Android (which will show groups in the order they're defined)
will show groups in a more logical order similar to DolphinQt.
The main thing that was annoying me was how early Rumble was for
Wii Remotes. Some of the other changes I'm making in this commit,
like the order of Shake/Tilt/Swing, are more arbitrary and were
made for consistency with DolphinQt. But there are also places
where I didn't go all the way with matching DolphinQt. Most notably,
DolphinQt puts sticks before buttons, but I don't see any reason
to do that for Android.
Unlike PCs, Android doesn't really have any input method (not counting
touch) that can reasonably be expected to exist on most devices.
Because of this, I don't think shipping with a default mapping for the
buttons and sticks of GameCube controllers and Wii Remotes makes sense.
I would however like to ship default mappings for a few things:
1. Mapping the Wii Remote's accelerometer and gyroscope to the device's
accelerometer and gyroscope. This functionality is useful mainly
for people who use the touchscreen, but can also be useful when
using a clip-on controller. The disadvantage of having this mapped
by default is that games disable pointer input if the accelerometer
reports that the Wii Remote is pointed at the ceiling.
2. Mapping GC keyboards for use with a physical keyboard, like on PC.
After all, there's no other way of mapping them that makes sense.
3. Mapping rumble to the device's vibrator.
Aside from the GC keyboards, this approach is effectively the same as
what we were doing before the input overhaul.
This is a battery-saving measure. Whether a sensor should be suspended
is determined in the same way as whether key events and motion events
should be handled by the OS rather than consumed by Dolphin.
When Android presents an input event to an app, it wants the app to
return true or false depending on whether the app handled the event or
not. If the event wasn't handled by the app, it will be passed on to
the system, which may decide to take an action depending on what kind
of input event it is. For instance, if a B button press is passed on to
the system, it will be turned into a Back press. But if an R1 press is
passed on to the system, nothing in particular happens.
It's important that we get this return value right in Dolphin. For
instance, the user generally wouldn't want a B button press to open
the EmulationActivity menu, so B button presses usually shouldn't be
passed on to the system - but volume button presses usually should be
passed on to the system, since it would be hard to adjust the volume
otherwise. What ButtonManager did was to pass on input events that are
for a button which the user has not mapped, which I think makes sense.
But exactly how to implement that is more complicated in the new input
backend than in ButtonManager, because now we have a separation between
the input backend and the code that keeps track of the user's mappings.
What I'm going with in this commit is to treat an input as mapped if
it has been polled recently. In part I chose this because it seemed
like a simple way of implementing it that wouldn't cause too many
layering violations, but it also has two useful side effects:
1. If a controller is not being polled (e.g. GameCube controllers in
Wii games that don't use them), its mappings will not be considered.
2. Once sensor input is implemented in the Android input backend,
we will be able to use this "polled recently" tracking to power down
the sensors at times when the game is using a Wii Remote reporting
mode that doesn't include motion data. (Assuming that the sensor
inputs only are mapped to Wii Remote motion controls, that is.)
Android doesn't let us poll inputs whenever we want. Instead, we
listen to input events (activities will have to forward them to the
input backend), and store the received values in atomic variables
in the Input classes. This is similar in concept to how ButtonManager
worked, but without its homegrown second input mapping system.
ButtonManager is very different from how a normal input backend works,
and is making it hard for us to improve controller support on Android.
The following commits will add a new input backend in its place.
When that setting is enabled, m_xfb_entry is initially not present (during the phase where a shader compilation progress bar would be shown). The main path checks for m_xfb_entry, but the software renderer fallback path didn't.
Fixes another aspect of https://bugs.dolphin-emu.org/issues/13172.
Before, it used a fallback where it returned a default object, where the width and height were set to 0. Presenter::Initialize() used GetSurfaceInfo to set the backbuffer size, then used that size when initializing the on-screen UI (even for the software renderer, where the on-screen UI isn't currently present), which meant that ImGui got a window size of 0 and thus resulted in a failed assertion.
Although BindBackbuffer checks for size changes, it doesn't help because ImGui has already been initialized, and the size hasn't actually changed since initialization occured.
Fixes one aspect of https://bugs.dolphin-emu.org/issues/13172.
This second stack leads to JNI problems on Android, because ART fetches
the address and size of the original stack using pthread functions
(see GetThreadStack in art/runtime/thread.cc), and (presumably) treats
stack addresses outside of the original stack as invalid. (What I don't
understand is why some JNI operations on the CPU thread work fine
despite this but others don't.)
Instead of creating a second stack, let's borrow the approach ART uses:
Use pthread functions to find out the stack's address and size, then
install guard pages at an appropriate location. This lets us get rid
of a workaround we had in the MsgAlert function.
Because we're no longer choosing the stack size ourselves, I've made some
tweaks to where the put the guard pages. Previously we had a stack of
2 MiB and a safe zone of 512 KiB. We now accept stacks as small as 512 KiB
(used on macOS) and use a safe zone of 256 KiB. I feel like this should
be fine, but haven't done much testing beyond "it seems to work".
By the way, on Windows it was already the case that we didn't create
a second stack... But there was a bug in the implementation!
The code for protecting the stack has to run on the CPU thread, since
it's the CPU thread's stack we want to protect, but it was actually
running on EmuThread. This commit fixes that, since now this bug
matters on other operating systems too.
I also changed LoadConfig, but that change doesn't affect correctness,
it's only so it looks neat by matching SaveConfig.
This bug was added in 18a4afb053, the
commit that introduced DefaultValue::Disabled. The bug can't actually be
triggered in master, but it can be triggered in the Android input
overhaul PR.
The HLSL compiler incorrectly decides isnan can't be true, so this
workaround was originally added in 52c82733 but lost during the
conversion to SPIR-V.
This broke formatting the system memory; see https://bugs.dolphin-emu.org/issues/13176. After calling ticket.DeleteTicket(), ticket.m_bytes was 0-length, but calling ticket.IsV1Ticket() still attempted to read from m_bytes.
This was introduced in 2fd9852ca8, although it didn't actually cause a crash until 929fba08e7.
When faced with this error, users often don't try disabling dual core,
even though the error message suggests it. Perhaps the message is just
too long and lists too many things?
To try to improve the situation, I'm rewording the message and making it
say different things depending on what settings you are using.
The LEA that the signal handler is trying to undo the effects of is a
32-bit instruction, and the value in the register prior to the LEA is
also 32-bit, so the signal handler should use a 32-bit write.
(Actually, in the end this doesn't really matter, because the first
instruction that reads this value after backpatching is also a 32-bit
instruction...)
This resulted in the labels being solid black even when audio stretching is disabled the first time the settings are opened, but then properly being greyed out after changing a setting (even the audio backend or DSP emulation engine, not just whether audio stretching is enabled).
This very much isn't a build configuration that we're going to ship,
but I want to be able to tell people that they can build it on their
own if they really want to see how terribly it performs :)
Just like before, you'll need to edit two lines in app/build.gradle to
define ENABLE_GENERIC=ON and actually enable armeabi-v7a if you want an
armeabi-v7a build. This commit just fixes some compilations errors that
crop up if you do so.
Before these changes you could tell Dolphin to convert a game file into the same format it is already in, leading to the FileDialog using the input path as the default destination path
An unsuspecting user could then click Save and Dolphin would try to convert the input file by writing the destination file on top of it... leading to an I/O error and the input file being entirely removed
This fixes a regression from 592ba31. When `a` was a constant 0 and `b`
was a non-constant 0x80000000, the 32-bit negation operation would
overflow, causing an incorrect result. The sign extension needs to happen
before the negation to avoid overflow.
Note that I can't merge the SXTW and NEG into one instruction.
NEG is an alias for SUB with the first operand being set to ZR,
but "SUB (extended register)" treats register 31 as SP instead of ZR.
I've also changed the order for the case where `a` is a constant
0xFFFFFFFF. I don't think the order actually affects correctness here,
but let's use the same order for all the cases since it makes the code
easier to reason about.
This works around an Intel driver bug where, on D3D12 only, dual-source blending behaves incorrectly if the second source is unused on. This bug is visible in skyboxes in Super Mario Sunshine, which first draw clouds and sun flare in greyscale and then draw the sky afterwards with a source factor of 1 and a dest factor of 1-src_color (this results in the clouds being tinted blue). This process is done on an RGB888 framebuffer, so alpha update is disabled. (Color update is enabled; note that if you look at this in Dolphin's fifo analyzer, it won't be enabled because they use the BP mask functionality to only change the blending functions and not alpha/color update, for whatever reason.)
The previous code only updated the PLRU on cache misses, which made it so that the least recently inserted cache block was evicted, instead of the least recently used/hit one.
This regressed in 9d39647f9e (part of #11183, but it was fine in e97d380437), although beforehand it was only implemented for the instruction cache, and the instruction cache hit extremely infrequently when the JIT or cached interpreter is in use, which generally keeps it from behaving correctly (the pure interpreter behaves correctly with it).
I'm not aware of any games that are affected by this, though I did not do extensive testing.
Previously we would only backpatch overflowed address calculations
if the overflow was 0x1000 or less. Now we can handle the full 2 GiB
of overflow in both directions.
I'm also making equivalent changes to JitArm64's code. This isn't because
it needs it – JitArm64 address calculations should never overflow – but
because I wanted to get rid of the 0x100001000 inherited from Jit64 that
makes even less sense for JitArm64 than for Jit64.
This avoids a pseudo infinite loop where CodeWidget::UpdateCallstack
would lock the CPU in order to read the call stack, causing the CPU to
call Host_UpdateDisasmDialog because it's transitioning from running to
pausing, causing Host::UpdateDisasmDialog to be emitted, causing
CodeWidget::Update to be called, once again causing
CodeWidget::UpdateCallstack to be called, repeating the cycle.
Dolphin didn't go completely unresponsive during this, because
Host_UpdateDisasmDialog schedules the emitting of Host::UpdateDisasmDialog
to happen on another thread without blocking, but it was stopping certain
operations like exiting emulation from working.
This fixes a problem I was having where using frame advance with the
debugger open would frequently cause panic alerts about invalid addresses
due to the CPU thread changing MSR.DR while the host thread was trying
to access memory.
To aid in tracking down all the places where we weren't properly locking
the CPU, I've created a new type (in Core.h) that you have to pass as a
reference or pointer to functions that require running as the CPU thread.
This code doesn't need to be portable (since the goal is to have a smaller offset for x64 codegen), so if it's not supported there are other problems. Similar code exists in e.g. DSP.cpp.
While the NV extension is totally fine, the KHR extension should be able to support more hardware.
For NVIDIA, the hardware either supports both or neither, it just needs a driver from the last two years.
For AMD, the drivers from late 2022-12 seems to bring support for the KHR extension.
For Intel, the KHR is also supported for some years.
Frame duplicate detection was inverted. Huge problem for 60fps games
where it would see all frames as "duplicates" and nothing would ever be
presented.
The logging was broken in 958cbf38a4 (DSPTool doesn't use dolphin's logging system, so it just produced nothing; the same thing affected comparing before 693a29f8ce).
AssemblerError::LabelAlreadyExists (previously ERR_LABEL_EXISTS) simply was never used.
- Cancel doesn't shut down anymore.
Allowing it to be used multiple times thoughout the life of
the WorkQueue
- Remove Clear, so we only have Cancel semantics
- Add IsCancelling so work items can abort early if cancelling
- Replace m_cancelled and m_thread.joinable() guars with m_shutdown.
- Rename Flush to WaitForCompletion (As it's ambiguous if a function
called flush should be blocking or not)
- Add documentation
CMakeSettings.json is a Visual Studio only extention to cmake that isn't
supported anywhere else. Not even Visual Studio Code.
So we set CMAKE_PREFIX_PATH inside DolphinQt's CMakeLists.txt instead.
A lot of the remaining complexity in Renderer is the massive Swap function
which tries to handle a bunch of FrameBegin/FrameEnd events.
Rather than create a new place for it. This event system will try
to distribute it all over the place
Almost all the virtual functions in Renderer are part of dolphin's
"graphics api abstraction layer", which has slowly formed over the
last decade or two.
Most of the work was done previously with the introduction of the
various "AbstractX" classes, associated with texture cache cleanups
and implementation of newer graphics APIs (Direct3D 12, Vulkan, Metal).
We are simply taking the last step and yeeting these functions out
of Renderer.
This "AbstractGfx" class is now completely agnostic of any details
from the flipper/hollywood GPU we are emulating, though somewhat
specialized.
(Will not build, this commit only contains changes outside VideoBackends)
Texture cache occasionally mutates textures for efficiency.
Which is awkward if we want to borrow those textures from texture cache
to do something else, such as a graphics debugger, or async presentation
on another thread.
Content locking provides a way to signal that the contents of a texture
cache entry should not change. Texture cache will be forced to use
alternative strategies.
The whole ownership model was getting a bit of a mess, with a some
of special cases to deal with. And I'm planning to make it even more
complex in the future.
So here is some upfront work to convert it over to reference counted
pointers.
Macros that expand to include the standard define macro are undefined.
This is pretty trivial to fix. We can just do the test and then define
the name itself if it's true, rather than making the set of definition
checks the macro itself.
This reverts commit e140516130. This assert triggers for AX and AXWii uCode games (including the Wii System Menu) for various addresses that seem to be 4-byte aligned. Worse still, if the DSP thread is in use (i.e. for DSP LLE recompiler, but not for DSP LLE interpreter), Dolphin completely hangs after the panic alert. Perhaps the data DMA has fewer restrictions compared to the instruction DMA?
The change to DSPTool (e391a28102) has not been reverted, as it still fixes broken behavior for DSPSpy at -O0 on real hardware.
Gives two members without explicit initialization default values to be
consistent with the rest of the class and also ensuring deterministic
values on construction.
Though less important compared to #11470, save states also show the full path in the OSD message and could potentially dox a streamer who is playing in Dolphin. This is a simple fix - it removes the path from the message and only displays the file name.
Capitalize Skylander in tr strings
Lint and validation method fixes
Proper Attach and Change Interface method
Re-jig code to exit early and read easier
I haven't tested this extensively on real hardware, but I do know that bad things happen if the address isn't properly aligned, and libogc says it should be 32-byte aligned.
Turns out all OSD messages, every single one, are written to the titlebar. We've just never seen them because the FPS is in the title bar and it replaces it in a fraction of a second. This was only visible when saving savestates because it halts emulation for a moment while writing.
This is dumb, let's not do that anymore.
A few weeks ago, a vtuber tweeted that they had to remove a vod of their stream because Dolphin Emulator showed some personal information during the steam, and left a warning to everyone else that Dolphin shows the account name of the computer. And yea, we do, we show the full directory of the memory card every time a memory card is written, and due to mandatory Microsoft account nonsense, that is very likely to contain someone’s real name.
Fortunately this is very easy for us to solve. This change simply removes the filename from wrote memory card contents string. That’s it. All functionality of the wrote memory card OSD message remains the same, it just doesn’t say where the memory card is anymore.
There are lots of other potential solutions to this but after talking on IRC it seems the simplest one is the best.
Skylander code tidy ups
Convert c array to std::array and fix comments
Formatting fixes/review changes
Variable comment
Migrate portal to System Impl and code tidy ups
Use struct
Restore review changes
Minor fix to schedule transfer method
Change descriptors to hex and fix comments
Ported the code from RPCS3, with improvements made to the handling of control messages and audio transfers, Co-Authored with @mandar1jn
Missing new line chars
Co-Authored-By: mandar1jn <49076509+mandar1jn@users.noreply.github.com>
We've decided this track will never be used in the future. Releases will
continue using the "beta" branch internally, though we'll have the
user-visible strings use a different name instead.
(Note: Dolphin provided builds have always defaulted to 'beta' as the
auto-update track, so anyone who set 'stable' did so manually.)
This should be a fairly easy merge, assuming I didn’t mess anything up. TL:DR no one uses it and it’s not great.
Boot from DVD Backup is an ancient feature with origins in the Megacommit. Back then, GameCube and Wii games were quite large relative to drives of the time. For example, in 2008, the most common hard drive sizes were 320GB and 512GB. On the 320GB drive I personally had at the time, as little as 42 Wii ISOs could have filled it entirely! And that’s ignoring any other files one might want to put onto a drive. Backup DVDs allowed users to burn relatively cheap DVD media and store their GameCube and Wii dumps in a Dolphin accessible way that didn’t eat into their precious HDD space. It had compromises, even then, but in 2008… I mean honestly users probably wouldn’t even notice those compromises with how Dolphin barely even worked at all back then.
Obviously, today the storage space concerns are not as big of an issue. According to seagate the average hard drive it sells today is 8TB. For typical laptops purchased now, the -minimum- selection for storage is usually 1TB. You can even buy a name brand 4TB external hard drive for $100. GC and Wii ISOs are not as big as they once were, relatively anyway. Plus flash drives and SD cards are super cheap and way faster than disc drives ever were. For anyone that has limited drive space, removable flash media can fulfill this offloading role far better than backup DVD media ever could.
Also no one has DVD drives anymore. That’s kind of an important detail.
But to see if Booting from DVD Backup even still worked, I decided to give it a try. I have an ASUS BW-16D1HT, a badass Bluray XL reading and burning drive, connected to my Windows 11 Threadripper 5975WX machine. A super fast drive on a super fast machine is as good as it possibly can get for this feature. So I bought a spindle of DVD-Rs, burned a couple of discs and gave it a try. Surprisingly, it does still work. However, as expected, it introduces a lot of stuttering. Testing Prime 1 and Prime 3, in both games stuttering was introduced whenever the DVD Drive had to suddenly seek. Spikes of 50ms occurred constantly, but I observed 150ms and even over 1000ms stutters! The worst was a three second stutter, when loading Elysia in Prime 3. I could even hear the stutters - any time the drive suddenly made a harsh seeking noise, the game would have a hard stutter. It worked but, it has some serious compromises.
Boot from DVD Backup isn’t great, using removable flash media or external hard drives is a FAR better option for anyone with limited storage space today, and no one can even use this feature anymore because their computers don’t even have disc drives. It’s time for Boot from DVD Backup to go!
So I did my best on the cleanup but I’m bound to have left some bits. Especially in translation - I didn’t get any warnings or anything there that could help point me to where to clean that up. Please review!
See the comment added by this commit. We were previously guarding against
overshooting in address calculations, but not against undershooting.
Perhaps someone assumed that the displacement of an x86 loadstore was
treated as unsigned?
Note: While the comment says we can undershoot by up to 2 GiB, in
practice Jit64 as it currently behaves won't actually undershoot by more
than 0x8000 if my analysis is correct. But address space is cheap, so
let's guard the full 2 GiB.
This is the behavior in the x64 and ARM64 vertex loaders. I don't know if it makes sense (the whole skipped vertex system seems jank, but several games behave incorrectly without it).
This generated a warning on GCC about the operation being potentially undefined (-Wsequence-point). I'm not sure if that was actually the case, but either way it is a mistake.
Before, it was also compiled on ARM builds, but since it was unused it wasn't linked (and thus its dependency on the nonexistent x64Emitter didn't cause any link issues).
Fixes incorrect logspam when the buffer needed to be reset on flushes (which we already were doing, but 52feed04db moved it to after the check was made). This is https://bugs.dolphin-emu.org/issues/10312.
I also converted it to an assert, as if this does happen, things are going to render incorrectly, so we want to make it obvious.
This was added in #10394 for both the hardware and software backends to work around an issue with Mario Kart Wii, Fortune Street, and Baten Kaitos. However, it seems like the software renderer handles blending well enough that we don't need this (and in any case, it's easy to change blending in the software renderer).
Some experimentation with #11387 (not pushed) showed that the software renderer's logic would also produce correct results on the hardware backends with this hack removed, but would require fbfetch (currently); if a better solution is found the hack can also be removed from the hardware backends.
Otherwise, texelFetch() will use an out-of-bounds layer for game textures (that have 1 layer; EFB copies have 2 layers in stereoscopic 3D mode), which is undefined behavior (often resulting in a black image). The fast texture sampling path uses texture(), which always clamps (see https://www.khronos.org/opengl/wiki/Array_Texture#Access_in_shaders), so it was unaffected by this difference.
The former is deprecated and pretty much all modern drivers
support VK_EXT_debug_utils.
Android drivers dont support it. On those drivers,
we use the implementation provided by the validation layers.
Plus two miscellaneous debugger features that I found along the way when
reading Jit64's code for comparison: bJITNoBlockLinking and tracing.
Fixes https://bugs.dolphin-emu.org/issues/13127.
Small optimization. By not calling WriteExit, the block linking system
never finds out about the exit we're doing, saving us from having to
disable block linking.
We should expose Enable Controller Input and the turbo settings for
GBA just like we do for GameCube controllers and Wii Remotes.
I just forgot about it when implementing the GBA TAS input window.
Previously, if a user on Windows launched Dolphin from the command line
and specified a path to an M3U file and included backslashes in this path,
Dolphin would fail to resolve relative paths in the M3U file.
The calculation of each address in lmw/stmw currently has a dependency
on the calculation of the previous address. By removing this dependency,
the host CPU should be able to pipeline the loads/stores better. The cost
we pay for this is up to one extra register and one extra MOV instruction
per guest instruction, but often nothing.
Making EmitBackpatchRoutine support using any register as the address
register would let us get rid of the MOV, but I consider that to be too
big of a task to do in one go at the same time as this.
Now that we've flipped the C++20 switch, let's start making use of
the nice new <bit> header.
I'm planning on handling this move away from BitUtils.h incrementally
in a series of PRs. There may be a few functions remaining in
BitUtils.h by the end that C++20 doesn't have any equivalents for.
This reverts commit 351d095fff.
In hindsight, my attempted optimization messes with the return
predictor, unlike real tail calls. So I think it does more bad than
good.
The "vector shift by immediate" category encodes the shift amount for
right shifts as `size - amount`, whereas left shifts use `amount`.
We're not actually using SHRN/SHRN2 anywhere, which is why this has gone
undetected.
Use: callstack(0x80000000).
!callstack(value) works as a 'does not contain'.
Add strings to expr.h conditionals.
Use quotations: callstack("anim") to check symbols/name.
For quite some time now, we've had a setting on x86-64 that makes Dolphin
handle NaNs in a more accurate but slower way. There's only one game that
cares about this, Dragon Ball: Revenge of King Piccolo, and what that game
cares about more specifically is that the default NaN (or "generated NaN"
as I believe it's called in PowerPC documentation) is the same as on
PowerPC. On ARM, the default NaN is the same as on PowerPC, so for the
longest time we didn't need to do anything special to get Dragon Ball:
Revenge of King Piccolo working. However, in 93e636a I changed how we
handle FMA instructions in a way that resulted in the sign of NaNs
becoming inverted for nmadd/nmsub instructions, breaking the game.
To fix this, let's implement the AccurateNaNs setting, like on x86-64.
This affected the memory and registers widgets (and possibly others). I'm pretty sure it regressed in 5f629abd8b.
The SetCodeVisible line is a new fix, but the equivalent already existed in the memory widget.
The call to analyzer.Analyze breaks when it attempts to read an instruction, as it eventually tries to read memory when Memory::m_pRAM is nullptr. Trying to read when execution is not paused in general seems like a bad idea (especially as analyzer.Analyze uses PowerPC::TryReadInstruction which can update icache - this is probably still a problem).
Operations that have two operands and can't generate a default NaN,
i.e. addition and subtraction, already have the desired NaN handling
on x86. We just need to make sure to not reverse the operands.
This fixes ps_sum0/ps_sum1 outputting NaNs in cases where they shouldn't.
(HandleNaNs assumes that a NaN in a ps0 input always results in a NaN in
the ps0 output, and correspondingly for ps1.)
1. In some cases, ps_merge01 can be implemented using one instruction.
2. When we need two instructions for ps_merge01, it's best to start with
a MOV to avoid false dependencies on the destination register.
3. ps_merge10 can be implemented using a single EXT instruction.
This regressed in 0a906f553f, I think (though I haven't confirmed it). Mario Tennis and Luigi's Mansion both use these for some reason (as far as I can tell, the data isn't actually used; it's just extra data included for no reason)
DataReader is generally jank - it has a start and end pointer, but the end pointer is generally not used, and all of the vertex loaders mostly bypassed it anyways.
Wrapper code (the vertex loaer test, as well as Fifo.cpp and OpcodeDecoding.cpp) still uses it, as does the software vertex loader (which is not a subclass of VertexLoader). These can probably be eliminated later.
This new function is like MOVP2R, except it masks out the lower 12 bits,
returning them instead of writing them to the register. These lower
12 bits can then be used as an offset for LDR/STR. This lets us turn
ADRP+ADD+LDR sequences with a zero offset into ADRP+LDR sequences with
a non-zero offset, saving one instruction.
When emulated GBAs were added to Dolphin, it was possible to control them
using the GC TAS input window. (Z was mapped to Select.) Unaware of this,
I broke the functionality in b296248.
To make it possible to control emulated GBAs using TAS input again,
I'm adding a proper TAS input window for GBAs, with a real Select button
and no analog controls.
0e02ddcf52 removed separate logic for tiled versus non-tiled EFB peek caches, and as part of that made it so that color peeks updated the frame access mask even when a non-tiled cache is in use. However, the same change was not made for depth peeks. I'm not sure if this affected anything in practice.
`ImGui::GetIO` performs an assertion that a context exists, and if one doesn't then things will likely crash. Unfortunately this crash is hard to consistently reproduce.
I recently talked to a homebrew developer who was trying to add exception
handlers at link time but found out that Dolphin was overwriting their
exception handlers. I figure that's not the usual way to do exception
handlers, but... making us load the executable after setting up memory
rather than before is easy, and matches what we do when booting discs,
so I suppose there's no reason not to do it. It also matches the intent
of why Dolphin is writing default exception handlers – we're writing
them because some homebrew relies on exception handlers being left
around from whatever program was running before it (see 3dd777be70).
Let's take advantage of ARM64's input register shifting one last time,
shall we?
Before:
0x1280005b mov w27, #-0x3
0x1b1b7f18 mul w24, w24, w27
After:
0x4b180b18 sub w24, w24, w24, lsl #2
ARM64's flexible shifting of input registers also allows us to calculate
a negative power of two in one instruction; shift the input of a NEG
instruction.
Before:
0x128001f7 mov w23, #-0x10
0x1b1a7efa mul w26, w23, w26
0x93407f58 sxtw x24, w26
After:
0x4b1a13fa neg w26, w26, lsl #4
0x93407f58 sxtw x24, w26
If the destination register doesn't equal the input register, using it
to temporarily hold the immediate value is fair game as it'll be
overwritten with the result of the multiplication anyway. This can
slightly reduce register pressure.
Before:
0x52800659 mov w25, #0x32
0x1b197f5b mul w27, w26, w25
After:
0x5280065b mov w27, #0x32
0x1b1b7f5b mul w27, w26, w27
By taking advantage of ARM64's ability to shift an input register by any
amount, we can calculate multiplication by a number that is one more
than a power of two with a single instruction.
Before:
0x52800838 mov w24, #0x41
0x1b187f7b mul w27, w27, w24
After:
0x0b1b1b7b add w27, w27, w27, lsl #6
Turn multiplications by a power of two into bitshifts.
Before:
0x52800817 mov w23, #0x40
0x1b167ef6 mul w22, w23, w22
After:
0x531a66d6 lsl w22, w22, #6
Multiplication by one is also trivial. Depending on the registers
involved, either a single MOV or no instructions will be generated.
Before:
0x52800038 mov w24, #0x1
0x1b1a7f1b mul w27, w24, w26
After:
0x2a1a03fb mov w27, w26
Before:
0x52800039 mov w25, #0x1
0x1b1a7f3a mul w26, w25, w26
After:
Nothing!
Add a new function that will handle all the special cases regarding
multiplication. It does nothing for now, but will be expanded in
follow-up commits.
We can merge an SXTW with the SUB, eliminating one instruction. In
addition, it is no longer necessary to allocate a temporary register,
reducing register pressure.
Before:
0x93407f59 sxtw x25, w26
0x93407ebb sxtw x27, w21
0xcb1b033b sub x27, x25, x27
After:
0x93407f5b sxtw x27, w26
0xcb35c37b sub x27, x27, w21, sxtw
ARM64 can do perform various types of sign and zero extension on a
register value before using it. The Arm64Emitter already had support for
this, but it was kinda hidden away.
This commit exposes the functionality by making the ExtendSpecifier enum
available everywhere and adding a new ArithOption constructor.
[ VUID-VkDescriptorPoolCreateInfo-maxSets-00301 ] Object 0:
handle = 0x7f1,b8d,3cd,e70, type = VK_OBJECT_TYPE_DEVICE; |
MessageID = 0xa1,70e,236 | vkCreateDescriptorPool():
pCreateInfo->maxSets is not greater than 0.
The Vulkan spec states: maxSets must be greater than 0
BindFramebuffer depends on the pipeline which might not be set yet.
That's why the framebuffer dirty flag exists in the first place.
I assume BindFramebuffer was called directly here, in order to handle
the texture state transitions necessary for DiscardResource.
The state is tracked anyway, so we can just issue those transitions there
too and defer binding the actual framebuffer.
Fixes an issue in Zelda Twilight Princess with EFB depth peeks.
Dolphin would bind a frame buffer which doesn't have an integer format
descriptor for the color target before binding the new pipeline.
So it would accidentally use the 0 descriptor.
Debug layer error:
D3D12 ERROR: ID3D12CommandList::OMSetRenderTargets:
Specified CPU descriptor handle ptr=0x0000000000000000 does not refer to
a location in a descriptor heap. pRenderTargetDescriptors[0] is the issue.
[ EXECUTION ERROR #646: INVALID_DESCRIPTOR_HANDLE]
Fixes the following error in the D3D12 debug layer:
D3D12 WARNING: ID3D12Device::CreateCommittedResource:
Ignoring InitialState D3D12_RESOURCE_STATE_UNORDERED_ACCESS.
Buffers are effectively created in state D3D12_RESOURCE_STATE_COMMON.
[ STATE_CREATION WARNING #1328: CREATERESOURCE_STATE_IGNORED]
Fixes the following error in the D3D12 debug layer:
D3D12 ERROR: ID3D12DescriptorHeap::GetGPUDescriptorHandleForHeapStart:
GetGPUDescriptorHandleForHeapStart is invalid to call on a descriptor
heap that does not have DESCRIPTOR_HEAP_FLAG_SHADER_VISIBLE set.
If the heap is not supposed to be shader visible, then
GetCPUDescriptorHandleForHeapStart would be the appropriate method
to call. That call is valid both for shader visible and non shader
visible descriptor heaps.
[ STATE_GETTING ERROR #1315: DESCRIPTOR_HEAP_NOT_SHADER_VISIBLE]
When searching for a disc where the revision doesn't match any disc in
the datfile, the loop would never get to the part where serials_exist is
set to true, leading to a bogus error message.
Because of the previous commit, `regs_in_use` must not include `dest_reg`
when calling MMIOLoadToReg. There are also some other registers we can
skip including in regs_in_use just for efficiency's sake.
The `addr_reg_set = false` statements that I've added in this commit are
technically redundant – if `mmio_address` is non-zero then `addr_reg_set`
is already false – but it's just a coincidence that that's the case.
I originally added these in 2b1d1038a6, for both the TPipelineFunction and the size. The size was moved into the header in fdcd2b7d00 (making the size functions obsolete), but it seems that the functions themselves are no longer needed now.
I think I didn't use this approach before because it would have required ComponentFormatTable and ComponentCountRow to be templated, which would end up resulting in lines that were too long and thus wrapped in awkward places. (I *think* they didn't get inferred properly.) Now that we only need TPipelineFunction, the templating is not needed, and this ends up being a more readable version of the version with the wrapper functions.
The old calculation was stride * (max_index + 1), which fails if stride is less than the size of a component (for instance, if float XYZ positions are used, and the stride was set to 4 (i.e. sizeof(float)) instead of 12 (i.e. 3 * sizeof(float)), it would be missing the last 8 bytes of the final element in the array. Or, if stride was set to 0, then no bytes would be recorded at all (though that's not a useful configuration so it's unlikely to actually exist).
I'm not aware of any games affected by this issue.
This should fix recording the wall in the staircase leading to the basement in Luigi's Mansion (though I haven't tested it, as I don't own a copy of Luigi's Mansion). This uses NormalIndex3, and the index for the normal vector (generally 0x02XX or 0x01XX) there is always lower than the tangent or binormal (generally 0x07XX). Other games seem to usually have a similar range of indices for the normal, tangent, and binormal, so this issue wouldn't affect them.
In most cases, games will use the same type for all vertex components (either Index8 or Index16 or Direct). However, RS2's deflection towers use Index16 for the texture coordinate and Index8 for everything else, meaning the texture coordinates were recorded incorrectly (the first byte was used, so only indices 0 and 1 were recorded instead of 0 through 0x0192). Worse still, some background elements in RS2 use direct positions but indexed normals or texture coordinates, and those would not be recorded at all.
This is a regression from b5fd35f951.
`count` is the number of stereo samples to write (where each stereo sample is two shorts), while `BUFFER_SIZE` is the size of the buffer in shorts. So `count` needs to be multiplied by `2`, not `BUFFER_SIZE`. Also, when this check was failed, the previous code just clobbered whatever was past the end of the buffer after logging the warning, which corrupted `basename`, eventually resulting in Dolphin crashing.
This affected Datel's Wii-compatible Action Replay, which uses a block size of 2298, or 18384 stereo samples, which is 36768 shorts, which is bigger than the buffer size of 32768. (However, the previous commit means that only one block is transfered at a time, eliminating this issue; fixing the bounds check is just a general safety thing instead of an actual bugfix now.)
The previous implementation of Force25BitPrecision was essentially a
translation of the x86-64 implementation. It worked, but we can make a
more efficient implementation by using an AArch64 instruction I don't
believe x86-64 has an equivalent of: URSHR. The latency is the same as
before, but the instruction count and register count are both reduced.
The new `dispatcher_no_timing_check` is the same as `dispatcher_no_check`
except it includes the "stepping check" in debug mode. This lets us avoid
the `m_enable_debugging ? dispatcher : dispatcher_no_check` dance.
Maybe "tail call" isn't quite the right term for what this code
is doing, since it's jumping to the dispatcher rather than
returning, but it's the same optimization as for a tail call.
fregsIn will include FD for double-precision instructions, since for
dependency tracking purposes the instruction does read the upper
half of FD. This is not what we want in HandleNaNs.
The consequence of this bug is that if an instruction was supposed to
output a NaN and FD happens to contain a NaN and FD happens to be the
same register as an unused register in the instruction encoding, the
NaN in FD could get used as the output instead of the correct NaN.
This isn't known to affect any games, which isn't especially surprising
considering that there's only one game that needs AccurateNaNs anyway.
Jumping to `dispatcher` requires first subtracting the downcount,
otherwise `dispatcher` may unpredictably jump to CoreTiming::Advance,
which could break determinism compatibility with JitArm64. We should
jump to `dispatcher_no_check` instead.
The breakpoint check in Jit.cpp makes it redundant.
Normally this redundant check doesn't cause any issues, but if you
create a breakpoint and enable logging without breaking, you get two
log messages if the breakpoint is at the beginning of a block. See
https://bugs.dolphin-emu.org/issues/13044.
This is also a tiny performance improvement for when debugging is
active, since we no longer check for breakpoints for blocks that never
had any breakpoints to begin with.
Nothing currently uses it. It could theoretically be replaced with fmt support, but I don't think the LOG_VULKAN_ERROR macro is that useful and it'd be better to replace it with regular logging instead.
base is an unsigned variable, so we can make things little more
consistent by making the loop index unsigned so we aren't doing bit
arithmetic with signed types.
MemoryInterface already does this, so we can leave it alone.
No behavioral changes, just a consistency thing.
Rather than makring some parts of VertexLoaderManager dirty in some places and some in others, do it all in VideoState. Also, since CPState no longer contains pointers/non-CP data after d039b1bc0d, we can just use p.Do on it instead of manually saving each field.
Micro-optimization. Some CPUs can fuse CMP+B, TST+B, arith+CBZ, etc.
I also moved things around for CMP+CSET and TST+CSET - which I'm not sure
if any CPUs support - but it doesn't hurt anything, so I might as well.
Improves accuracy but isn't known to affect any games.
This turned out to be fairly convenient to implement; ORing with the
PPC default NaN will quieten SNaNs and do nothing to QNaNs.
This existed in the initial megacommit (though I don't know why) as IO_SIZE. It was used in Memmap's Init() to compute totalMemSize, but I don't know if it actually did anything then. That use was removed in 2d0f714546, but the constant persisted until cc858c63b8, when it became a static variable.
This was added in 385d8e2b15, but became somewhat redundant with Do in 4c7bbd96e4, and completely redundant now that std::is_trivially_copyable_v is well-supported.
This is the first step of getting rid of the controller indirection
on Android. (Needing a way for touch controls to provide input
to the emulator core is the reason why the controller indirection
exists to begin with as far as I understand it.)
This lets the TAS input code use a higher-level interface for
overriding inputs instead of having to fiddle with raw bits.
WiiTASInputWindow in particular was messy with how much
controller code it had to re-implement.
Fixes a Rogue Squadron II regression from 9d73583.
This set_dirty stuff is pretty tricky to reason about. I thought I
was clever when coming up with set_dirty, but maybe I was too clever
for my own good...
In case the register we're binding is the same as the immediate register,
we should fetch the immediate before calling BindToRegister. The way
the register cache currently works, calling GetImm after BindToRegister
actually does work, but it's better to not rely on it.
Avoid waiting for earlier submissions when we flush more often.
The vertex manager will flush more often if the game accesses the EFB
on the CPU, to give the GPU a head start.
Before, only the symbols box would update. However, if you edit the symbol of a function in the call stack (which seems like something that would happen reasonably often while debugging), the call stack would be out of date until it was updated by clicking on it. Callers and calls were more of an edge case; for them to be out of date, you would need to right-click on an instruction in a function other than the one containing the currently-selected instruction (though it would also affect recursive functions).
JosJuice