This eliminates the clutter of checkboxes at the bottom of the window.
A QAction within a QMenu cannot have a tooltip however, so they have
been removed and the options will be documented on the wiki.
Instead of selecting languages based on the user config at the time
of TitleDatabase creation and merging the different languages into one
map for GC and one map for Wii, have one map for each language, and
have the caller supply the language they want. This makes us not need
the IsGCTitle function, which is inaccurate for IDs that start with D.
The difference between Dolphin's game IDs and GameTDB's game IDs
is that GameTDB uses four characters for non-disc titles, whereas
Dolphin uses six characters for all titles.
This fixes:
- TitleDatabase considering Datel discs to be NHL Hitz 2002
- Gecko code downloading not working for discs with IDs starting with P
- Cover downloading mixing up discs with channels (e.g. Mario Kart Wii
and Mario Kart Channel) and making extra HTTP requests. (Android was
actually doing a better job at this than DolphinQt!)
Unnecessary since b93b7ec. It was needed before that commit becase
RenderBase.cpp only was checking the value of aspect_mode, not
suggested_aspect_mode.
This way we don't end up with artifacts of the EFB's alpha values in
frame dumps. XFB copies loaded from RAM also set the alpha to 1, so this
will match.
Also removed minimum number of frames needed when decoding DPL2, and use
std::numeric_limits to clamp the samples when needed.
Clamping is still needed, but those samples are much rarer now and depend
on the game.
Due to the current design, any of the GL state can be mutated after
calling this function, so we can't assume that the tracked state will
match if we call SetPipeline() after ResetAPIState().
The WiiRD codes respository at https://geckocodes.org has started using HTTPS, and 301 Redirecting traffic from HTTP to HTTPS. The HTTP client does not appear to be able to handle a 301 Redirect and instead fails when attempting to download codes. This pull request is purely a string replacement to set the URL as HTTPS.
Calling deleteLater in MainWindow's destructor doesn't work, as the
event loop will stop before it gets around to deleting these dialogs.
Seeing as this is a QObject destructor, we should already be on the
event loop anyways, so simply using delete should be safe.
Android doesn't report values for the inputs generated by FullAnalogInput so
there isn't a reason to add them as such. This also avoids a bug(for android)
where if there are three inputs(say 12, 11, and 121), and you generate a FullAnalogInput
with 12/11 then it will create another input with the name 121 which can cause conficts
with the real 121 input. This is probably not an issue on PC since most Axis inputs
are named and not numbered.
Some games don't behave as expected if we eject the disc as soon as
we receive the DVDLowStopMotor command. For instance, Baten Kaitos
never shows the prompt to switch discs or the "Reading disc..." text
(but works correctly other than that).
If the user tries to permanently install a title that has already been
imported, and if that title is currently marked as a temporary title
in IPL.TID, that flag should be cleared.
Add in shaking acceleration rather than overwritting it so it doesn't look like the device is in free-fall. This fixes shaking in "Batman: TBATB". It appears the game only detects shaking along the z-axis and expects gravity to exist.
Previously, PowerPC.h had four macros in it like so:
\#define rPS0(i) (*(double*)(&PowerPC::ppcState.ps[i][0]))
\#define rPS1(i) (*(double*)(&PowerPC::ppcState.ps[i][1]))
\#define riPS0(i) (*(u64*)(&PowerPC::ppcState.ps[i][0]))
\#define riPS1(i) (*(u64*)(&PowerPC::ppcState.ps[i][1]))
Casting between object representations like this is undefined behavior.
Given this is used heavily with the interpreter (that is, the most
accurate, but slowest CPU backend), we don't exactly want to allow
undefined behavior to creep into it.
Instead, this adds a helper struct for operating with the paired singles,
and replaces the four macros with a single macro for accessing the
paired-singles/floating-point registers.
This way, it's left up to the caller to explicitly decide how it wants to interpret
the data (and makes it more obvious where different interpretations of
the same data are occurring at, as there'll be a call to one of the
[x]AsDouble() functions).
These bits enable or disable paired-single execution based on how
they're set. If PSE isn't set, then all paired-single instructions are
illegal. If PSE is set, but LSQE isn't set, then psq_l, psq_lu, psq_st
and psq_stu are illegal to execute.
Also thanks go out to my roommate @Veegie for letting me use his Wii as
a blasting ground for tests, since mine isn't on hand right now. It only
caught on fire twice and only burned down half of the house through the
process; what a team player.
Small addition of NetPlay code in Core.cpp was needed to set the
extensions at the right time, as init would override them otherwise.
This solution is more elegant than modifying the user's INI files on
game start.
Since we use the common pipelines here and draw vertices if a batch is
currently being built by the vertex loader, we end up trampling over its
pointer, as we share the buffer with the loader, and it has not been
unmapped yet. Force a pipeline flush to avoid this.
This could happen with savestate loads, permission issues, or use by other processes.
Prior to this Dolphin assumed any existing file could be opened and crashes from invalid variant access.
Failing to open a file during savestate load will likely still crash but at least the user will know why.
This makes it possible to gracefully force stop emulation rather than
having to kill Dolphin completely when NetPlay deadlocks in the input
loop. Without a graceful stop, Wii saves do not get flushed to the main
NAND, and are left in limbo in the temporary NAND.
Doing pretty much anything in the controller config breaks NetPlay
(desync and/or deadlock), as saving the settings reconfigures
controller interfaces, which NetPlay doesn't expect.
The implementation of peer initialization would hang if the initial
packet was never received. This fixes that issue by deferring the
initialization to the packet receive loop.
This sends arbitrary packets in chunks to be reassembled at the other
end, allowing large data transfers to be speed-limited and interleaved
with other packets being sent. It also enables tracking the progress of
large data transfers.
Its usage was inconsistent, confusing, and buggy, so I opted to just
remove it entirely. It has been replaced with PadIndex for the
appropriate instances (mainly networking), and inappropriate usages
(where it was really just a player ID) have been replaced with the
PlayerId type. The definition of "no mapping" has been changed from -1
to 0 to match the defintion of "no player", as -1 (255 unsigned) is
actually a valid player ID.
The bugs never manifested because it only occurs with a full lobby of
255 players, at which point the last player's ID collides with the "no
mapping" definition and some undefined behavior occurs. Nevertheless, I
thought it best to fix it anyways as the usage of PadMapping was
confusing.
The interface address isn't particularly useful in most circumstances
(playing over internet), and we have a way to get the external IP now,
so displaying it in the dialog is useful.
And use it for reporting games that rely on ICache emulation to some
degree. We know of a few but it would be interesting to get a more
exhaustive list from crowdsourcing.
This was an erronous change in 534db3b, Ra was previously loaded but was changed to not being loaded.
Why is loading necessary? Loading is necessary because when a memory exception occurs, the current
register values are flushed. This occurs before a new value is loaded into Ra, so the previous value
is required in Ra.
It doesn't feel great to let the value from a previous emulation session
linger around considering that the GC aspect ratio heuristic can use
the previous value of m_aspect_wide when calculating m_aspect_wide.
The Metal shader compiler fails to compile the atomic instructions
when operating on individual components of a vector. Spltting it
into four variables shouldn't make any difference for other
platforms, as they are accessed independently.
The path to the MoltenVK library can be specified by the
LIBMOLTENVK_PATH environment variable, otherwise it assumes it is
located in the application bundle's Contents/MacOS directory.
Adds a tickbox to the server's window to syncronize codes. Codes
are temporarily sent to each client and are used for the duration of the
session.
Saves the "sync codes" tickbox as per PR Netplay: Properly save hosting
settings #7483
Previously, the Qt frontend would initialize the controller
interface on starting, resulting in the cursor position being
relative to the main window, instead of the render window.
Starting with PR 7411, the rest of Dolphin reads the game ID from
PARTITION_NONE, but SetRunningGameMetadata was still reading from
the game partition. https://bugs.dolphin-emu.org/issues/11422
Problem is that USBDeviceAddToWhitelistDialog starts a timer once created to poll for devices every second. In Qt, closing a heap-allocated dialog doesn't delete it, so it keeps on polling. This fix is to allocate dialog on the stack, then use "exec" to run it modally without returning. Once closed, the stack instance will get destroyed, thus killing the timer.
Gecko codes are a core foundation of most netplay sessions and most general modding cases. It has gone so far as to now have an ini for almost every game.
After the massive UI overhaul, the gecko code sorting defaults to Alphabetical with no option to change it. This removes the possibility for netplay builds to have important and necessary codes at the top for easy selecting, and removes the ability to sort massive code lists in categories.
This will also make the sorting consistent with AR codes, which are sorted manually.
glBlitFramebuffer() does not bypass the scissor test, which meant that
part of texture copies (e.g. XFB) could have been clipped when running
under OpenGL ES, as glCopyImageSubData() is not supported.
floatindex is clamped to the range [0, 9]. For non-negative numbers
floor() is equivalent to trunc(). Truncation happens implicitly when
converting to uint, so the floor() is unnecessary.
These country codes have the unfortunate property that they are used
by Wii disc games in two different regions. We already correct for this
in VolumeGC::GetCountry and VolumeWii::GetCountry, so this commit
shouldn't really have any effect on how the game list behaves,
but it will be useful if we in the future would want to call
CountrySwitch directly without having extra code in the caller for
handling region weirdness.
This avoids out-of-bounds warnings when replaying FIFO captures.
The value of XF_REGS_SIZE is written into the DFF header and we only
read the min of XF_REGS_SIZE and the header value, so this change is
backward compatible and doesn't break forward compatibility for old
Dolphin versions either.
* Removed the Cancel button since the code doesn't react to it anyway.
* Only show a window title, not the help icon (?), and disable the close button
* Set the title to "Dolphin" instead of repeating the label text
Switch to using additional overloads of sf::Packet, so we can eliminate
some of the messy code and just use the normal syntax for
BigEndianValue.
We can't avoid helper functions with u64 due to SFML's non-standard way
of defining 64-bit integer types.
The current approach results in the UI thread creating a graphics device
whilst the core is running, leading to races on function pointers, and
potentially crashing.
Prior to this commit, the emitter would unconditionally emit a 10-byte
instruction known as MOVABS when loading a 64-bit immediate to a
register.
0: 48 b8 ef be ad de 00 movabs rax,0xdeadbeef
7: 00 00 00
With this change, it will instead rely on the fact that on x64 writes to
32-bit registers are automatically zero extended to 64-bits, allowing
us to emit a 5 or 6-bytes instruction with the same effect for certain
immediates.
0: b8 ef be ad de mov eax,0xdeadbeef
Fixes a critical regression from 8bb08d1ca6.
In that commit, I replaced a 1024 byte buffer with a SHCIEventCommand.
However, it looks like some Bluetooth adapters actually require such
a large buffer, so this change needs to be reverted.
This fixes severe image flickering in some cutscenes of Twin Snakes. The game appears to sometimes load a previously made XFB copy as a texture before it is actually rendered to the screen, which we took as an invitation to invalidate the XFB copy.
Prior to this commit, the emitter would unconditionally emit a 10-byte
instruction known as MOVABS when loading a 64-bit immediate to a
register.
0: 48 b8 ef be ad de ff movabs rax,0xffffffffdeadbeef
7: ff ff ff
With this change, it will instead emit a 7-byte instruction when it is
possible to express the 64-bit immediate using a signed 32-bit value.
0: 48 c7 c0 ef be ad de mov rax,0xffffffffdeadbeef
If, for whatever reason, the XFB has to be loaded from console memory, it's possible that the texture is returned at native resolution instead of EFB-scaled resolution. In this case, our xfb_rect.right adjustment must also happen at native resolution instead of scaled resolution.
The header of a Wii disc can be read from two places: The
unencrypted area at the beginning of the disc, or the beginning of
the game partition. The two copies are usually identical (except
for 0x60 and 0x61), but there are exceptions. For most of Dolphin's
history, we have been reading from the header inside the game
partition when getting metadata. This was however not the case
starting with 4.0-4901 and ending with 5.0-3762. This commit once
again makes Dolphin read metadata from the unencrypted header,
because of the following reasons that I recently was informed about:
- The "pink fish" disc has the game ID 410E01 in the unencrypted
header but the placeholder game ID RELSAB in the partition header.
- The revisions of some games differ between the two headers,
with the unencrypted one making more sense.
(See https://bugs.dolphin-emu.org/issues/11387)
For better or worse, this also means that sloppily hacked games where
only the game ID in the unencrypted header has been changed now will
use that modified game ID. And unlike with the partition header,
there is no signing or hashing that can tell us whether the
unencrypted header has been modified by someone other than Nintendo.
Dolphin has traditionally treated the SI IO buffer (128 bytes) as a set of
32 little endian u32s. This works out fine if you only ever read/write
using aligned 32bit accesses. Different sized accesses or misaligned reads
will mess it up. Byte swapping reads/writes will fix this up, but all the
SI devices that use the SI IO buffer need to be adjusted.
The LogManager code had trouble detecting the "/Source/Core/" substring
for two reasons, neither of which seemed to happen a few years ago:
1. __FILE__ is in lowercase on MSVC
2. __FILE__ uses backslash as the directory separator on MSVC
Fixes https://bugs.dolphin-emu.org/issues/11366
Several functions (and one variable) were being given external linkage.
Instead, relocate them all to anonymous namespaces to make them
internally linked.
Puts the comment in the header where it's more likely to be seen
initially. We can also remove the TODO, given doing nothing or returning
an error is what is generally done for the JIT interface if the JIT
instance isn't valid.
With 7aa305ea35 merged, all that remains
within Profiler.cpp is an unused function that just forwards to the
equivalent function within JitInterface. Given that, we can just remove
the source file.
This global belongs in the JitOptions structure, as it's a conditional
setting (A.K.A. option) that changes the behavior of what the JIT does.
Plus it keeps the scope of the variable constrained to the general area
it's intended to be used and nothing further.
swap32() has a const u8* overload that swaps the data being pointed to as
if it were a 32-bit word. We can just use that instead. It gets rid of
undefined behavior, as we're not type punning a pointer and dereferencing it,
and gets rid of the need to cast entirely.
In both cases of the x64 and AArch64 JITs, these would have const casted
away from them, followed by them being placed within an emitter and
having breakpoint instructions written in them.
In this case, we shouldn't be using const period if we're writing to the
emitted data.
Similar in nature to e28d063539 in which
this same change was applied to the x64 emitter.
There's no real requirement to make this const, and this should also
be decided by the calling code, considering we had places that would
simply cast away the const and carry on
Xlib supports many mouse buttons, though there are 9 standard buttons, and they aren't arranged like other mouse APIs. Using only 5 buttons was preventing the use of buttons besides left/right/middle click and the scroll wheel. Here's what all the standard buttons are:
1. left button
2. middle button (pressing the scroll wheel)
3. right button
4. turn scroll wheel up
5. turn scroll wheel down
6. push scroll wheel left
7. push scroll wheel right
8. 4th button (aka browser backward button)
9. 5th button (aka browser forward button)
The remaining button indices are non-standard and device-specific, and technically far more than 32 are supported, but this seems like a reasonable limit to avoid cluttering the list with tons of useless mouse buttons. What mouse has more than 32 buttons anyways?
Currently, each player buffers their own inputs and sends them to the
host. The host then relays those inputs to everyone else. Every player
waits on inputs from all players to be buffered before continuing. What
this means is all clients run in lockstep, and the total latency of
inputs cannot be lower than the sum of the 2 highest client ping times
in the game (in 3+ player sessions with people across the world, the
latency can be very high).
Host input authority mode changes it so players no longer buffer their
own inputs, and only send them to the host. The host stores only the
most recent input received from a player. The host then sends inputs
for all pads at the SI poll interval, similar to the existing code. If
a player sends inputs to slowly, their last received input is simply
sent again. If they send too quickly, inputs are dropped. This means
that the host has full control over what inputs are actually read by
the game, hence the name of the mode. Also, because the rate at which
inputs are received by SI is decoupled from the rate at which players
are sending inputs, clients are no longer dependent on each other. They
only care what the host is doing. This means that they can set their
buffer individually based on their latency to the host, rather than the
highest latency between any 2 players, allowing someone with lower ping
to the host to have less latency than someone else.
This is a catch to this: as a necessity of how the host's input sending
works, the host has 0 latency. There isn't a good way to fix this, as
input delay is now solely dependent on the real latency to the host's
server. Having differing latency between players would be considered
unfair for competitive play, but for casual play we don't really care.
For this reason though, combined with the potential for a few inputs to
be dropped on a bad connection, the old mode will remain and this new
mode is entirely optional.
This was causing a warning in the shader compiler, as the rgb components
were not initialized. Which shouldn't be an issue, as the rgb is not
used in the blend equation, only the alpha. However, the lack of
initialization causes crashes in Intel's D3D shader compiler, so we'll
play nice and initialize all the channels.
Added an option in General config to enable/disable usage statistics. Added a popup on first open if
the user would like to engage in reporting. Clicking cancel or out of the box opts out. Only
clicking 'Ok' will enable reporting. Also added a new android specific values to report.
Since we don't have a way (AFAIK) to dynamically collect the list of
available art assets, we hardcode a list of gameids with available
artwork inside Dolphin. It's not great, but I don't think it's a
terrible solution either.
Art has to be manually uploaded to our Discord app configuration, and we
have a limit of ~150 assets, so most likely we'll limit ourselves to a
small set of popular games.
Type punning like this is undefined behavior. Instead, we use std::memcpy to
copy the necessary data over, which is well defined (as it treats both
the source and destination as unsigned char).
At some point SetCRFieldBit was modified to operate on RSCRATCH, but the
function was only partially changed. As such, setting SO, GT or LT would
write the right bit to cr_field, but then cr_field would just get
overwritten with RSCRATCH, undoing the work.
also did these things
fixed crash from joining user that isn't hosting via a direct connection
current game stat can now pass to override the current game in config
uses ip endpoint from dolphin.org
Behaviorally, this belongs within the netplay client. The server will
always transmit a known RTC value, so it doesn't even need a global for
this. Given the client receives the packet containing said RTC value, we can
store it as a member variable and provide an accessor for reading that
value.
This removes another global variable within the netplay code.
The idea of this code was to not unroll loops, but it was completely broken.
So we've unrolled all loops, but only up to the second iteration.
Honestly, a better check would test if we branch to code which is already in the compiling block. But this is out of scope for now.
But testing shows that this unrolling actually improve the performance. So instead of fixing this bug, this check can be dropped.
Most settings which affect determinism will now be synced on NetPlay.
Additionally, there's a strict sync mode which will sync various
enhancements to prevent desync in games that use EFB reads.
This also adds a check for all players having the IPL.bin file, and
doesn't load it for anyone if someone is missing it. This prevents
desyncs caused by mismatched system fonts.
Additionally, the NetPlay window was getting too wide with checkboxes,
so FlowLayout has been introduced to make the checkboxes take up
multiple rows dynamically. However, there's some minor vertical
centering issues I haven't been able to solve, but it's better than a
ridiculously wide window.
This is accomplished by having SConfig::GetDirectoryForRegion no longer
return nullptr, as doing that was kind silly, considering we never
check for nullptr.
Basically everything here was race conditions in Qt callbacks, so I changed the client/server instances to std::shared_ptr and added null checks. It checks that the object exists in the callback, and the shared_ptr ensures it doesn't get destroyed until we're done with it.
MD5 check would also cause a segfault if you quit without cancelling it first, which was pretty silly.
This option completely disabled the DCBZ instruction. Users are toggling
this option in dolphin forks and using that same problematic config when
launching dolphin. Removing the option from dolphin will let the config be
ignored.
This adds the functionality of sending the host's save data (raw memory
cards, as well as GCI files and Wii saves with a matching GameID) to
all other clients. The data is compressed using LZO1X to greatly reduce
its size while keeping compression/decompression fast. Save
synchronization is enabled by default, and toggleable with a checkbox
in the NetPlay dialog.
On clicking start, if the option is enabled, game boot will be delayed
until all players have received the save data sent by the host. If any
player fails to receive it properly, boot will be cancelled to prevent
desyncs.
Our usage of glFinish() can cause driver crashes and/or lockups.
Please note that this disables the background shader compilation (i.e.
all shaders will be compiled on boot). There is no way around this.
Reduces the amount of dependencies dragged in by the main window's
header. This also removes MainWindow.h includes elsewhere where they
aren't necessary, reducing the amount of UI files that need to be
recompiled if the main window's header changes.
We don't want to write this setting to disk, as SConfig has problems
with leaking settings changed by GameINI into the base configs. The
result of this is that if someone plays an N64 VC game (or other game
where we disable this setting) the branch following option can get
unintentionally disabled globally, which will reduce performance in
many games and cause NetPlay to desync with users who still have it
enabled.
Lessens the amount of files that have to be recompiled if
ConfigManager.h is modified. This also removes an indirect inclusion
within DolphinQt/Main.cpp.
AVFormatContext::filename was deprecated in lavf 58.7.100 in favor
of AVFormatContext::url. Instead of adding version-checking logic,
just use the passed-in dump path instead.
Makes it less error-prone to get state data from analog sticks (no need
to pass any locals), and also allows direct assignment, letting the
retrieved data be const.
Makes it less error-prone to get state data from tilt controls (no need
to pass any pointers to locals), and also allows direct assignment,
letting the retrieved data be const.
Makes it less error-prone to get state data from sliders (no need
to pass any locals), and also allows direct assignment, letting the
retrieved data be const.
Makes it less error-prone to get state data from cursors (no need
to pass any pointers to locals), and also allows direct assignment,
letting the retrieved data be const.
Makes it less error-prone to get state data from analog sticks (no need
to pass any locals), and also allows direct assignment, letting the
retrieved data be const.
Ensures they match their naming within the definition of the function.
In EmulateSwing's case, one parameter was erroneously named tilt_group,
when it's actually supposed to be swing_group.
These aren't necessary in the prototype, however they do apply in the
definition of the function. This just cuts down on line noise within the
prototypes.
This is only ever read from externally, so we can expose a getter that ensures that
immutability, while making the actual instance internal. Given the
filling out of these settings depends on packets received by the client
instance, it makes more sense to make it a part of the client itself.
This trims off one lingering global.
This stops clients randomly deadlocking when a spectator leaves, as the mappings construct is not thread-safe and should not be written while the game is running.
Avoids dragging in a bunch of includes from the header files, and also
reduces the amount of files that need to be recompiled if one of those
included headers' source content is ever changed.
Previously we wouldn't indicate if saving or loading these files
happened to fail. In some cases we'd only print out to the logger, but
this is a pretty poor way to tell a user of the interface that something
went wrong in a direct way (the logging messages aren't able to be localized
either).
This packet is only used by the host to detect desyncs, and we don't really need to know the exact frame we desynced on (unless you're debugging, but you can just recompile for that), so it's perfectly fine to just send it less often. This makes it so the timebase packet is sent only every 60 frames, rather than every frame, which further cuts back on unnecessary bandwidth consumption.
PowerPCState's cr_val member is an array of u64s, so we can just use the
correct printf macro specifier within cinttypes. This also avoids
truncation on operating systems that use an LLP64 data model (like
Windows), where long is actually 32 bits in size, not 64-bit, which
could result in wonky values being printed, should Trace ever be used on
it.
define how many frames constitute a high or a low swing/shake when the
button is down. Also configurable is the number of frames to execute
the swing/shake after the button is released.
When disabled only inputs from TAS dialog are used.
When enabled inputs from TAS dialog are used, except when a change in
input is detected from a real controller, in this case the TAS value is
replaced with the real controller value.
Previously there was only one function under the NetPlay namespace,
which is kind of silly considering we have all of these other types
and functions existing outside of the namespace.
This moves the rest of them into the namespace.
This gets some general names, like Player, for example, out of the global namespace.
Works around a bug in QtCore that will cause crashes when
QFileSystemWatcher::addPath is called on a directory that is located on a
removable device (USB mass storage devices, etc.)
This should make the NetPlay dialog appear as a separate window in the taskbar on most systems, which makes more sense than a parented dialog as the user will leave it open for an extended period.
We want this setting to invalidate the cache because it may affect the appearance of textures in the rendered scene, therefore one would expect changing it while the game is running to have the expected effect immediately.
Initializing GraphicsWindow layout & children requires cooperation from
the graphics stack: on my system, for example, it causes a Vulkan
context to get created in order to get driver info. This is a slow
operation, and right now it is taking about 60-70% of the Dolphin
startup time on my system.
Move instead to a lazy-initialization model where the constructor
does nothing, instead offloading work to a separate Initialize() method
called before the window is shown.
I would expect this should be done for other larger parts of the UI,
especially the ones where creating widgets ends up triggering large IO
subsystems (I suspect controller configuration might be doing that).
(I'm not super happy with how this is implemented, but right now it's a
one-off, and it's a major complaint users have with the new UI. I
prioritized getting something working quickly...)
Now the detection heuristic has changed, the old value is no longer
valid.
Some example thresholds for known mipmap effects that should trigger:
SMG's lava has a mimimum difference of ~17.8, SMG2's clouds have a
minimum difference of ~14.8, and Wind Waker's foam has a minimum
difference of ~15
Non-triggering examples were tested and all had a calculated difference
lower than 3.
So a value of 14 should lean towards false-negatives instead of
positives, but this is clearly incomplete testing and may require
further tweaks later.
This no longer converts from sRGB to linear for the reference mip
downsample - even if the original mipmap creation tool used an sRGB
colorspace (which isn't really guaranteed, and may even change per
game), this is a "fast" heuristic that's only an estimate anyway.
The average diff is also now stored in a u64, avoiding floating point
calculations in the per-pixel hot loop.
This should speed up the detection significantly, hopefully fixing
jank when loading in new textures.
Normally, SI is polled at a rate defined by the game, and we have to send the pad state to other clients on every poll or else we'll desync. This can result in fairly high bandwidth usage, especially with multiple controllers, mostly due to UDP/IP overhead.
This change introduces an option to reduce the SI poll rate to once per frame, which may introduce up to one frame of additional latency, but will reduce bandwidth usage substantially, which is useful for users on very slow internet connections.
Polling SI less frequently than the game asked for did not seem to cause any problems in my testing, so this should be perfectly safe to do.
Given we now use a base class for the interface, we can make all member
functions, types and constants that aren't directly related to
instructions private.
HID2.LSQE is the Load/store quantize enable bit for non-indexed format
instructions (which are psq_l, psq_lu, psq_st, and psq_stu). If this bit
is not set and any of these instructions are attempted to be executed,
then a program exception is supposed to occur.
This register is defined as "optional reserved" within the aarch64 ABI.
Linux doesn't use it, but we must not modify it on ios or windows.
As we have plenty of registers on aarch64, let's just always skip this one.
This function was duplicated across all the opcode tables: the main info
tables, the interpreter tables, and the x86-64 JIT tables. However, we
can just make the type of the std::array parameter a template type and
get rid of this duplication.
const on a parameter being passed by value in a prototype doesn't actually signify
anything, these are only applicable in the definition, where they make
the opcode parameter immutable.
inline has external linkage, which doesn't really make sense here, given
the function is only used within this translation unit. So we can
replace inline with static.
While we're at it, the code within the function can also be compressed
to a single return statement.
Previously these were required to be built into the executable so that
the JIT portion of the DSP code would build properly, as the
x86-64-specifics were tightly coupled to the DSP common code. As this is
no longer the case, this is no longer necessary.
This adds a base class that is used to replace the concrete instance of
the x64 JIT pointer within DSPCore. This fully removes the direct use
(read: non-ifdefed) usage of x86-64-specifics within the main DSP code.
Said base can also be used for creating JITs for other architectures,
such as AArch64, etc.
This is one of the last things that needed to be done in order to
finally separate the x86-64-specific code from the rest of the common
DSP code. This splits the tables up similar to how it's currently done
for the PowerPC CPU tables.
Now, the tables are split up and within their own relevant source files,
so the main table within the common DSP code acts as the "info" table
that provides specifics about a particular instruction, while the other
tables contain the actual instruction.
With this out of the way, all that's left is to make a general base for
the emitters and we can then replace the x64 JIT pointer in DSPCore with
it, getting all x64 out of the common code once and for all.
While shuffling all the code around, the removal of the DSPEmitter
includes in some places uncovered indirect inclusions, so this also
fixes those as well.
Despite both being documented as read-only registers, only one of them
is truly read-only. An mtspr to HID1 will steamroll bits 0-4 with
bits 0-4 of whatever value is currently in the source register, the rest
of the bits are not modified as bits 5-31 are considered reserved, so
these ignore writes to them.
PVR on the other hand, is truly a read-only register. Attempts to write
to it don't modify the value within it, so we model this behavior.
This makes it much more straightforward to access WiimoteDevice
instances and also keeps the implementation details of accessing those
instances in one spot.
Given as all external accesses to the WiimoteDevice instances go through
this function, we can make the other two private.
Using reinterpret_cast (or a C-styled equivalent) to reinterpret
integers as floating-point values and vice-versa invokes undefined
behavior. Instead, use BitCast, which does this in a well-defined
manner.
According to PEM 3.3.6.1, if a division by zero occurs and FPSCR.ZE is
set, then the result of the instruction operation is unchanged (see
table 3-13). Similarly, if an invalid operation occurs and FPSCR.VE is
set, then the destination should also remain unchanged (see table 3-12).
Hardware also matches this behavior.
We were handling this for other relevant instructions, but we weren't
doing so for the arithmetic instructions. This corrects that.
This also alters our NI_* functions to return an FPResult type, which
allows us to see which kind of exception in particular is set in
exceptional cases. This is necessary for cases like the fdiv
instructions, which requires handling both ZE and VE being potentially
set.
These can be moved into the RegisterColumn constructor, which avoids
potential allocations in the case a std::function would otherwise need
to allocate to hold all of it's captured data.
Also tidy up the inclusion order while we're at it.
Previously the class was intermixing m_ prefixed variables and
non-prefixed ones, which can be misleading. Instead, we make the
prefixing consistent across the board.
Selecting Dummy or Memory Card would pass wrong values to EXI::ChangeDevice and not work as expected
Changing path had no effect until device was changed as it didn't call EXI::ChangeDevice at all
Makes the values strongly-typed and gets more identifiers out of the
global namespace.
We are forced to use anything that is not "None" to mean none, because
X11 is garbage in that it has:
\#define None 0L
Because clearly no one else will ever want to use that identifier for
anything in their own code (and is why you should prefix literally
any and all preprocessor macros you expose to library users in public
headers).
Makes the enum values strongly-typed and prevents the identifiers from
polluting the PowerPC namespace. This also cleans up the parameters of
some functions where we were accepting an ambiguous int type and
expecting the correct values to be passed in.
Now those parameters accept a PowerPC::CPUCore type only, making it
immediately obvious which values should be passed in. It also turns out
we were storing these core types into other structures as plain ints,
which have also been corrected.
As this type is used directly with the configuration code, we need to
provide our own overloaded insertion (<<) and extraction (>>) operators
in order to make it compatible with it. These are fairly trivial to
implement, so there's no issue here.
A minor adjustment to TryParse() was required, as our generic function
was doing the following:
N tmp = 0;
which is problematic, as custom types may not be able to have that
assignment performed (e.g. strongly-typed enums), so we change this to:
N tmp;
which is sufficient, as the value is attempted to be initialized
immediately under that statement.
This changes the identifier to represent the x86-64 DSP emitter. If any
other JITs for the DSP are added in the future, they all can't use the
same generic identifier.
In cases where we just want a random value for a primitive arithmetic
type, we can wrap this in a template to allow convenient direct
assignment instead of keeping declaration and initialization separate
(making it more difficult to use values uninitialized). This also allows
the use of Common::Random with functions such as std::generate, making
it more flexible in how random values can be generated.
This is only ever used internally. Also change the std::string name over
to a const char*, so that we don't need to potentially allocate anything
on the heap at immediate runtime.
Previously, a total of 114 std::string instances would need to construct
(allocating on the heap for larger strings that can't be stored with
small string optimizations). We can just use an array of const char*
strings instead, which allows us to avoid this.
Given JitBase shouldn't include platform specifics, we can generalize this
preprocessor define and allow any JIT to use it to indicate that generated code should be logged.
While we're at it, also move these defines beneath the includes with the
rest of the defines.
Rather than introduce this handling in every system instruction that modifies
the FPSCR directly, we can instead just handle it within the data structure
instead, which avoids duplicating mask handling across instructions.
This also allows handling proper masking from the debugger register
windows themselves without duplicating masking behavior there either.
ChunkFile doesn't use any of the file utilities, so we can drop these
headers to avoid pulling in unnecessary dependencies. This also
uncovered a few indirect inclusions.
This only queries internal state, it doesn't modify it. With minor
adjustments to BTEmu, this also allows us to make its usage instance a
constant reference.
The required version of MSVC already supports [[maybe_unused]], so we
can utilize this here. When GCC 7 and clang 3.9 become hard
requirements, we can eliminate this macro entirely and replace it with
[[maybe_unused]].
UNUSED is quite a generic macro name and has potential to clash with
other libraries, so rename it to DOLPHIN_UNUSED to prevent that, as well
as make its naming consistent with the force inline macro
This is much better as prefixed double underscores are reserved for the
implementation when it comes to identifiers. Another reason its better,
is that, on Windows, where __forceinline is a compiler built-in, with
the previous define, header inclusion software that detects unnecessary
includes will erroneously flag usages of Compiler.h as unnecessary
(despite being necessary on other platforms). So we define a macro
that's used by Windows and other platforms to ensure this doesn't
happen.
Instead of globbing things under an ambiguous Common.h header, move
compiler-specifics over to Compiler.h. This gives us a dedicated home
for anything related to compilers that we want to make functional across
all compilers that we support.
This moves us a little closer to eliminating Common.h entirely.
Rather than have a separate independent variable that we need to keep
track of in conjunction with the JIT code buffer size itself, amend the
analyst code to use the code buffer constant in JitBase.
Now if the size ever changes, then the analyst will automatically adjust
to handle it.
Given the code buffer is something truly common to all JIT
implementations, we can centralize it in the base class and avoid
duplicating it all over the place, while still allowing for differently
sized buffers.
Gets rid of an inclusion dependency with the DSP interpreter, as well as
a header-based dependency on the DSP opcode tables. This also uncovered
an indirect inclusion on the logger within DSPSymbols.cpp
As peculiar as this may be, decrementer exceptions by means of setting
the decrementer's zeroth bit from 0 to 1 is valid behavior by software
(and is defined in Programming Environments for 32-bit Microprocessors
in section 2.3.14.1 -- Decrementer operation). Given it's valid behavior,
it doesn't necessarily make sense to use a panic alert and halt, as this
isn't a condition where everything should be considered in a critical
state.
Instead, change it to an info log, so we still make note of it, but
without potentially tearing down state or halting emulation.
This fixes the The Last Story prototype that GerbilSoft was testing,
because the apploader is a bit more lenient with the max size of DOL
sections when it detects that you're using a devkit console.
Deduplicates code, and gets rid of some problems the old code had
(such as: bad performance when calling native functions, only one
disc showing up for multi-disc games, Wii banners being low-res,
unnecessarily much effort being needed for adding more metadata).
By making the jitted function a private static function of DSPEmitter,
we can allow access to data members within the context of the function
without making them public overall.
This finally makes all data members for the x64 DSP emitter private.
If we don't do this the prompt *may* appear behind the fullscreened window
and thus cause confusion. This happens both with exclusive fullscreen and
borderless fullscreen (e.g. for OpenGL).
This hardware behavior makes sense, as the FI bit is used to signify an
inexact result. An inexact result is a form of value that results during
the rounding phase of denormalization. If any bits of the significand
are lost during said rounding, then the result is considered to be
inexact.
However NaN and infinity are not classed as subnormals and therefore
don't undergo the denormalization step, making loss of precision not
possible (in NaN's case, numerically rounding something that is
literally Not a Number doesn't even make sense).
FR is set to indicate whether or not the last arithmetic or rounding and
conversion instruction that rounded the intermediate result incremented
the fractional portion of the result. Given neither input types would be
affected by this, this should also be unset.
This corrects more of the exceptional case handling for these values to
match hardware.
As suggested here: https://dolp.in/pr7059#pullrequestreview-125401778
More descriptive than having a std::tuple of FS::Mode, and lets us
give names to known triplets of modes (like in ES). Functions that
only forward mode arguments are slightly less verbose now too.
Prevents implicit conversions to types and requires explicitly
specifying them in order to construct instances of them. Given these are
used within emulation code directly, being explicit is always better
than implicit.
As explained within 179d73ac0d, the table
within the Programming Environments Manual for PowerPC lists the FI and
FR bits as cleared for invalid operation cases. So, we amend the
relevant cases here in order to be accurate to hardware.
As explained within commit a08ad82ace, if
an invalid exception occurs and VE is set, then the destination register
should remain unchanged. Ditto for when ZE is set and a zero divide
exception occurs.
This is only used internally, so we don't need to expose it in the
header. This also allows getting rid of inclusion of the byte swapping
utilities in the header as well.
Given they were only made public so that the callback could access class
state, we can simply make the callback a private static function of
CEXIMic, which allows access to members from the callback function
without making all of said members public.
In the PEM manual, within Table 3-12, which lists what should occur for
invalid operation exceptions, the FPSCR.FI and FPSCR.FR bits are listed
as "Cleared" for when FPSCR.VE is unset and set. So we clear these bits
as well to match hardware behavior.
In the PowerPC Microprocessor Family: The Programming Environments
Manual for 32 and 64-bit Microprocessors, in section 3.3.6.1, Table
3-12 lists what should occur if an invalid operation exception occurs in
situations where VE is set and when VE is not set. In the case where VE
is set, it lists the frD as "Unchanged". It also lists the FPRF flags as
"Unchanged".
Further down in Table 3-13, the listings for what should occur when zero
divide exceptions occur is listed, both for when ZE is set, and when it
isn't. When ZE is set, it lists frD as "Unchanged". It also lists the
FPRF flags as "Unchanged" as well.
This also alters the code so that we don't even calculate the result if
we don't need to compute it, making it a little bit less wasteful.
DataBinHeader is not used anywhere in the code other than via Header,
so let's merge them to reduce noise when accessing header fields
(currently we have to do header.hdr which looks silly).
It would make sense for 0x80 and 0xf0c0 to be respectively
sizeof(BkHeader) and sizeof(Header) as Nintendo is signing anything
that comes after the header, including the BkHeader.
The current WiiSave code is extremely messy, as it exposes all kinds of
implementation details in the header (including internal struct
definitions and magic numbers that don't have to be).
The read/write code is intermingled, so it's hard to tell which members
are used, or when/where they are set at all.
It also implicitly relies on some functions being called in a specific
order since it doesn't seek manually every time, which makes the code
even more fragile.
The logic is also hardcoded to only support bin->nand or nand->bin,
even though it would be useful to support nand->nand (for the
Movie save copying code, for example).
This commit attempts to solve these problems by getting rid of the
WiiSave class:
* Read/write code is moved to new Storage classes (NandStorage and
DataBinStorage) with small, clear functions that do one and only
one thing.
* The import/export logic was refactored into a generic Copy function
that takes two storages as parameters.
* The existing import and export functions are now just small wrappers
that call Copy with the appropriate storages.
This makes it easier to generate random numbers or fill a buffer with
random data in a cryptographically secure way.
This also replaces existing usages of RNG functions in the codebase:
* <random> is pretty hard to use correctly, and std::random_device does
not give enough guarantees about its results (it's
implementation-defined, non cryptographically secure and could be
deterministic on some platforms).
Doing things correctly is error prone and verbose.
* rand() is terrible and should not be used especially in crypto code.
Normalizes variable names to conform to our coding conventions.
Previously we were signifying some variables as externally linked
globals, which wasn't the case.
The definition of the function uses the ordering {mod, reg, rm}, which
is correct. Match the prototype to this, so that the parameter list
isn't misleading.
We can just use std::any_of here to collapse the checking code down to a
single assignment as opposed to a loop. This also slightly improves on
the existing code, as this won't continue to iterate through the cluster
metadata if an entry that's non-zero is encountered.
Pretty much all of the source files contain the following:
namespace IOS
{
namespace HLE
{
namespace <name>
{
// actual code here
} // namespace <name>
} // namespace HLE
} // namespace IOS
which is really verbose boilerplate, because most of the files inside
of Core/IOS are for IOS HLE.
This commit replaces that with a more concise `namespace IOS::HLE`
or `namespace IOS::HLE::(name)`.
This is just used as a means of carting around routines. It's not meant
to directly have functionality embedded within it--this is the job of
the inheriting data structure--so we can just make this a basic struct.
Particularly given all the data members were public to begin with.
Gets rid of the need to set up memcpy boilerplate to reinterpret between
floating-point and integers.
While we're at it, also do a minor bit of tidying.
Given this is what occurs in both constructors (as one just passes
through to another), we can just initialize the member directly.
While we're at it, amend the struct to follow the general ordering
convention of:
<new types>
<functions>
<variables>
Switching to blank NAND when emulation is running is an extremely bad
idea. It's akin to opening up a Wii and replacing the NAND chip while
you're playing a game on it.
Except we're not even replacing it with a NAND that has the same
contents. The blank NAND has nothing in it except the save file for
the current game, which is likely to result in the emulated software
getting inconsistent results and possibly even crashing depending on
how it caches title information.
An example of games that check the saves for other games is
Mario Kart Wii -- it checks the filesystem for Super Mario Galaxy saves
to decide whether to unlock characters. With this 'switch NAND
while emulation is active' misfeature, this will likely break.
And that's the main problem: it encourages sloppy emulation and no one
really knows how many things it can break.
Just don't let the user do horrible things like that during emulation.
If they want to use a blank NAND, they can do so by starting input
recording before launching a game. It's likely they will want to do
this if they plan to share their DTM anyway.
Another bit of behavior that we weren't performing correctly is the
unsetting of FPSCR.FI and FPSCR.FR when FPSCR.ZX is supposed to be set.
This is supported in PEM's section 3.3.6.1 where the following is
stated:
"
When a zero divide condition occurs, the following actions are taken:
- Zero divide exception condition bit is set FPSCR[ZX] = 1.
- FPSCR[FR, FI] are cleared.
"
And so, this fixes that behavior.
FPSCR[ZX] is the bit defined to represent the zero divide exception
condition bit, and is defined as (according to PowerPC Microprocessor
Family: The Programming Environments Manual for 32 and 64-bit
Microprocessors, which will be referred to as "PEM" for the rest of this
commit message) at section 3.3.6.1:
"
A zero divide exception condition occurs when a divide instructions is
executed with a zero divisor value and a finite, nonzero dividend value
or when a floating reciprocal estimate single (fres) or a floating
reciprocal square root estimate (frsqrte) instruction is executed with a
zero operand value.
"
Note that it states the divisor must be zero and the dividend must be
nonzero in order for ZX to be set. This means that the interpreter was
performing the wrong behavior for the case where 0/0 (with any sign on
the zeros) is performed. We would incorrectly set the ZX bit when only
the VXZDZ bit should be set.
It's also worth pointing out that N/0 (where N is any finite nonzero
value) and 0/0 are not within the same exception class. N/0 is a zero
divide exception case, while 0/0 is considered an invalid operation
exception case, which is also indicated in the PEM section 3.3.6.1 as
well where it lists the criteria for invalid operation exceptions.
Therefore we should only be setting the VXZDZ bit in the 0/0 case, not
VXZDZ and ZX. This was also verified via hardware tests to ensure that
this behavior indeed holds.
Fairly trivial to resolve, we just initialize the std::array with two
sets of braces (one set to create the array, the other to start and end the
aggregate data that we'll end up returning)
Given this is actually a part of the Host interface, this should be
placed with it.
While we're at it, turn it into an enum class so that we don't dump its
contained values into the surrounding scope. We can also make
Host_Message take the enum type itself directly instead of taking a
general int value.
After this, it'll be trivial to divide out the rest of Common.h and
remove the header from the repository entirely
If invalid operation exceptions are enabled and an invalid operation
occurs, then the destination value remains untouched. This fixes issues
that may arise when using these two instructions where the destination
gets steamrolled by an infinity or NaN value.
If a NaN of any type is passed as the operand to either of these
instructions, we shouldn't go down the regular code path, as we end up
potentially setting the wrong flags. For example, we wouldn't set the
FPSCR.VXCVI bit properly. We'd also set FPSCR.FI, when in actuality it
should be unset.
If an SNaN is passed as an operand, we also need to set the FPSCR.VXSNAN
bit as well.
The flag setting behavior for these can be found in Appendix C.4.2 in
PowerPC Microprocessor Family: The Programming Environments Manual for
32 and 64-bit Microprocessors.
fctiwz functions in the same manner as fctiw, with the difference being
that fctiwz always assumes the rounding mode being towards zero. Because
of this, we can implement fctiwz in terms of fctiw's code, but modify it
to accept a rounding mode, allowing us to preserve proper behavior for
both instructions.
We also move Helper_UpdateCR1 to a temporary home in
Interpreter_FPUtils.h for the time being. It would be more desirable to
move it to a new common header for all the helpers, so that even JITs
can use them if they so wish, however, this and the following changes
are intended to only touch the interpreter to keep changes minimal for
fixing instruction behavior.
JitCommon already duplicates the Helper_Mask function within
JitBase.cpp/.h, and the ARM JIT includes the Interpreter header in order
to call Helper_Carry. So a follow up is best suited here, as this
touches two other CPU backends.
We can just memcpy the data instead of pointer-casting data, which is
alignment-safe and doesn't run afoul of aliasing rules.
Previously it also made it seem as if data itself pointed to valid
usable data, but it doesn't, it simply functions as an out parameter
where we push data built up from the GetState() functions into it.
This was added in 4bdb4aa0d1 back in
2009-02-27. The only usage spot of this macro involves the same checks
that were used to define that preprocessor macro, so we can simply
remove the macro
If any operand is a signaling NaN, we need to signify this by setting
the VXSNAN bit.
Fixes NaN flag setting for fmsub, fmsubs, fnmsub, fnmsubs, ps_msub, and
ps_nmsub instructions.
If any operand is a signaling NaN, we need to signify this by setting
the VXSNAN bit.
Fixes NaN flag setting for fmadd, fmadds, fnmadd, fnmadds, ps_madd,
ps_nmadd, ps_madds0, and ps_madds1
If either operand is a signaling NaN, we need to signify this by setting
the VXSNAN bit.
This fixes NaN flag setting for fsub, fsubs, and ps_sub instructions.
If either operand is a signaling NaN, we need to signify that by setting
the VXSNAN bit.
This fixes NaN flag setting for fdiv, fdivs and ps_div instructions.
These aren't used to modify the data they point to, so make that
explicit. Also while we're at it, add const to any nearby variables that
can be made so.
This might happen if someone moves settings between e.g. a PC and
an Android device, or if someone was using JITIL and updates Dolphin.
I also made the panic alert a bit more explanatory.
It's not used anywhere other than in DolphinQt2, where the usage is
incorrect and stupid since we shouldn't be trying to stop the core
and 'restore config' that was changed by the core at app exit time,
but immediately when the core is being shut down.
Makes all of the naming consistent with our code style, and makes
parameters match their header equivalents.
Essentially just a clean-up of things that weren't migrated over
already.
If either of the operands are signaling NaNs, then an invalid operation
exception needs to be indicated within the FPSCR.
This corrects SNaN flag setting for fmul, fmuls, ps_mul, ps_muls0, and
ps_muls1.
In old GCC versions, capturing 'this' does not work for some lambdas.
The workaround is to not use auto for the parameter (even though the
type is obvious). This can be dropped once we require GCC 7.
If the input is a signaling NaN, then we need to signal that via setting
the FPSCR.VXSNAN bit. We also shouldn't update the FPRF flags if
FPSCR.VE is set.
If the FPSCR.VE bit is set and an invalid operand is passed in, then the FPRF
shouldn't be updated. Similarly this is also the case when the FPSCR.ZE bit
is set and negative or positive zero is passed in as the operand.
If FPSCR.ZE is set and a divide by zero exception is signaled, then the
FPRF shouldn't be updated with a result. Similarly, if the input is an
SNaN and FPSCR.VE is set, then the FPRF shouldn't be updated.
The VX bit is intended to be a summary bit indicating the occurrence of
any kind of invalid operation. Therefore, whenever an invalid operation
exception is set, also set VX.
This corrects our CR flag setting for multiple instructions in certain
scenarios. This corrects flag setting cases in fadd, fadds, fctiw, fctiwz, fdiv,
frsp, frsqrte, fsub, and fsubs (and technically every floating-point
instruction that we make more accurate in the future with regards to
flag setting).
Coherent mappings have a lower overhead and less GL codes.
So enables coherent mapping by default for all drivers.
Both Qualcomm and ARM performs very bad with explicit flushing, so this change helps them as well.
AFAIK there was one GPU generation which was slower on coherent mapping: nvidia tesla
So Geforce 200 and 300 series should be tested with this PR before merging.
As this was last tested many years ago, this issue might have been fixed as well.
Those GPUs are close to 10 years old and not supported any more by nvidia.
This ports the Wii filesystem root, Wii SD card path and dump path
settings to the new config system (OnionConfig).
My initial plan was to wait until DolphinWX was removed before porting
most of the Main (Core, DSP, General) settings to onion config, but
I've decided to submit a small part of those changes to fix
[issue 10566](https://bugs.dolphin-emu.org/issues/10566).
Removes the need to manually set the FileUtil path in the UI frontends
and gets rid of some more members that don't really belong in SConfig.
Also fixes a bug which would cause the dump path not to get created
after change.
Only invoke config changed callbacks from Config::Save, not
Layer::Save. The latter results in callbacks being called
once per layer, up to 7 times per save.
These disc images are only used on dev units and not retail units.
There are two important differences compared to normal Wii disc images:
- The data starts 0x8000 bytes into each partition instead of 0x20000
- The data of a partition is stored unencrypted and contains no hashes
Our old implementation was just guesswork and doesn't work at all.
According to testing by GerbilSoft, this commit's implementation
is able to read and extract files in the filesystem correctly,
but the tested game still isn't able to boot. (It's thanks to their
info about unencrypted disc images that I was able to make this commit.)
Initialising Wii filesystem contents should be done after Boot and
not in HW to ensure that we operate with the correct title context
and to make sure required title directories exist (so that Movie and
Netplay code can copy data from and to the temporary NAND).
Previously, given cases such as 0x80000000 / 0xFFFFFFFF we'd incorrectly
set the destination register value to zero. If the dividend is negative,
then the destination should be set to -1 (0xFFFFFFFF), however if the
dividend is positive, then the destination should be set to 0.
Note that the 750CL documents state that:
"If an attempt is made to perform either of the divisions --
0x80000000 / -1 or <anything> / 0, then the contents of rD are
undefined, as are the contents of the LT, GT, and EQ bits of the CR0
field (if Rc = 1). In this case, if OE = 1 then OV is set."
So this is a particular behavior of the hardware itself.
D3D11 cannot handle block compressed textures where the first mip level
is not a multiple of the block size. The simple fix for texture pack
authors: leave these textures uncompressed. You can still use a .dds
container.
Executing a supervisor-level instruction in user mode is supposed to
cause a program exception to occur.
The following supervisor instructions are present:
- dcbi
- mfmsr
- mfspr
- mfsr
- mfsrin
- mtmsr
- mtspr
- mtsr
- mtsrin
- rfi
- tlbie
- tlbsync
In 0337ca116a checks within mfspr and
mtspr were added. This change adds the trivial checks to the other
instructions.
Using 8-bit integer math here lead to precision loss for depth copies,
which broke various effects in games, e.g. lens flare in MK:DD.
It's unlikely the console implements this as a floating-point multiply
(fixed-point perhaps), but since we have the float round trip in our
EFB2RAM shaders anyway, it's not going to make things any worse. If we
do rewrite our shaders to use integer math completely, then it might be
worth switching this conversion back to integers.
However, the range of the values (format) should be known, or we should
expand all values out to 24-bits first.
Keeps signed values out of bit arithmetic (not that there's any issues
that could arise from it in these situations, but it does look more
consistent, and silences compiler warnings)
Also ensure that all members of the class are initialized on
construction as well. Previously the bool indicating if options are
dirty wouldn't be initialized, which could be read uninitialized if an
instance was constructed and then IsDirty() is called.
Keeps all of the interpreter-specific exception handling functions
together in a reusable way across translation units, similar to
FPUtils.h for reusable floating-point functions.
Given this is a base class, we should clearly state what the parameters
to the functions in its exposed interface actually mean or represent.
This avoids needing to hunt for the definition of the functions in cpp
files.
While we're at it, normalize said parameter names so they follow our
naming guidelines.
There's no reason to use int here as opposed to an unsigned value.
Video_AccessEFB() takes its arguments as u32 values, so we'd be doing
sign conversions for no reason here (along with causing avoidable
compiler warnings).
If a program executing in user mode tries to write to any SPRs other than
XER, LR, or CTR registers, then a program exception occurs. Similarly
this also applies for reading SPRs as well, however the upper and lower
timebase halves can also be read (but not written to).
If HID0.NOOPTI is set, then dcbt and dcbtst are no-oped globally. We
currently don't perform data cache emulation, but we put this in anyway
so this detail isn't forgotten about if data cache emulation is
introduced at some point in the future.
This implements ES_VerifySign which is notably used by the system menu
when importing saves.
Now *all* ES commands that are actually used by titles are implemented.
- Move all of the ec functions into the Common::ec namespace.
- Give the public functions better names and some usage information.
- Move all of the "elt" related functions into an "elt" class including
all of the arithmetic operations, so that the logic becomes clearer
and feels less like assembly.
This also makes it much more obvious what the parameters are, instead
of only using unsigned char* (which doesn't tell anything about what
the pointer is used for or the size).
- Similarly, add a new "Point" class and move point functions there.
Overload the arithmetic operators to make calculations easier to read
The loops relied on unsigned integer overflow, which is not immediately
obvious. Replace them with less clever variants that are clearer.
Also implement bn_compare using std::memcmp.
This function in both JITs is only ever called by passing the JIT's code
buffer into it. Given this is already accessible, since the functions
are part of the respective JIT class, we can just remove this parameter.
This also cleans up accesses with the new code buffer, as we don't need
to do janky looking dereference-then-index expressions.
This class effectively acted as a "discount vector", that would simply
allocate memory and then delete it in the destructor when it goes out of
scope.
We can just use a std::vector directly to reduce this boilerplate.
ImportTitleDone only checks if all required contents have been imported
for system titles.
This fixes the system menu not being able to recreate title directories
to copy a save back to the NAND by using title import functionality.
Given this is a bitmask, we should be using an unsigned type to store it
(especially given it's outside the range an int can represent properly
without being considered negative).
No behavior change is caused by this, it just silences a sign conversion
warning.
Because it wasn't parented properly, it would show briefly the widget in its own window when creating an ARCodeWidget or a GeckoCodeWidget which would occur when accessing the game properties page or when the state changes to pause/running.
PowerPC.h at this point is pretty much a general glob of stuff, and it's
unfortunate, since it means pulling in a lot of unrelated header
dependencies and a bunch of other things that don't need to be seen by
things that just want to read memory.
Breaking this out into its own header keeps all the MMU-related stuff
together and also limits the amount of header dependencies being
included (the primary motivation for this being the former reason).
This fixes 2 crashes with the pause function. One is when spamming the pause hotkey and the other is to press pause and step hotkeys at the same time. It does disable the screensaver getting disabled when the emulator is running, but paused, though, a better solution would have to be done without introducing these crashes.
Github didn't detect conflicts here, however, since the float handling
functions were moved into the Common namespace, this would cause a build
failure.
Ideally none of these macros would exist (long-term goal), however in
the meantime at least make sure expressions always evaluate correctly
(thankfully no current usages rely on this).
Given we're operating with flags and bit representations, lets avoid
signed values here. It lessens the amount of sign conversion warnings
and lessens the amount of things to think about screwing you over when
making changes to the interpreter among other things.
Hopefully this better matches the user's view of a texture - as large changes in
colour should be weighted higher than lots of very small changes
Note: This likely invalidates the current heuristic threshold default
These can be expressed in a slightly cleaner manner without so many
casts. While we're at it, also get rid of unnecessary indexing (we
already have the result nearby).
Extracts the self-contained code into its own function to clean up the
flow of Jit() a little more.
This also introduces a helper function to HLE.h that will be used to
reduce the boilerplate here and in the interpreter and Jit64 in the
following commits.
This function performs all of the preliminary checks required prior to
attempting to hook/replace a function at a given address. The function then
calls a provided object that satisfies the FunctionObject concept in the
C++ standard library. This can be a lambda, a regular function pointer,
an object with an overloaded function call operator, etc. The only
requirement is that the function return a bool, indicating whether or
not the function was replaced, and that it can take parameters in the
form: fn(u32 function, HLE::HookType type)
Gets rid of a second pair of ifdefs in the constructor. This also makes
sure the fd on Unix/BSD platforms is uniformly initialized. Previously
fd would be in an inconsistent state on FreeBSD or OpenBSD due to the
BSD OS checks not being present in the #elif within the constructor.
Previously, the entirety of CEXIETHERNET was exposed publically, which
wasn't necessary. We simply make the thread function part of the
internal interface, which gives it access to internal data members,
while keeping everything else outside of it.
Given these HLE classes inherit from a common base with a virtual
destructor, override is more appropriate here, as virtual propagates to
these destructors anyway.
This is also safer. If the base class' destructor is ever made
non-virtual, then these classes will cause a compilation error if they
aren't taken into account, as they'd be overriding a non-virtual
function (the destructor).
This is to avoid several issue with using 2 actions and switching between them. This commit will instead have one action get his property changed on pause and play.
Paired single (ps) instructions can call asm_routines that try to update
PowerPC::ppcState.pc. At the time the asm_routine is built, emulation has
not started and the PC is invalid (0). If the ps instruction causes an
exception (e.g. DSI), SRR0 gets clobbered with the invalid PC.
This change makes the relevant ps instructions store PC before calling out
to asm_routines, and prevents the asm_routine from trying to store PC
itself.
Moves the codebuffer access variables closer to their first use, and
gets rid of multiple indexing expressions. We already know which op
we're accessing in particular, so just make a reference to it and access
it instead of duplicating the expression all over the place.
A call like ReplaceAddress(address, 0) is pretty ambiguous; so is
ReplaceAddress(address, false), so use an enum class that tells people
straight-up what the replacer is.
This also gets rid of the really weird naming, where if 'blr' is true,
we'd be replacing the address with a NOP, rather than an actual BLR
instruction, so we invert that so it actually makes sense. There's no
actual bug fixed here though, considering the OnInsert functions
specified the correct values; it's literally just weird naming.
Without this macro, if any signals or slots were attempted to be used,
they wouldn't work; neither would various other features of the Qt
meta-object system. This can also lead to weird behavior in other
circumstances. Qt's documentation specifically states:
"Therefore, we strongly recommend that all subclasses of QObject use the
Q_OBJECT macro regardless of whether or not they actually use signals,
slots, and properties."
on its page for "The Meta-Object System", which can be seen here:
https://doc.qt.io/qt-5/metaobjects.html
Let's opt for "always do the right thing", and keep the code extensible
for the future and not have random things blow up on us.
Makes the enum strongly typed. A function for retrieving the string
representation of the enum is also added, which allows hiding the array
that contains all of the strings from view (i.e. we operate on the API,
not the exposed internals). This also allows us to bounds check any
querying for the strings.
Export and ExportAll now open a directory picker (that defaults to the
previous default directory, i.e. the Dolphin user dir).
Also removes the need to return the path in the export functions since
the user knows which path they chose.
This moves the result dialogs to DolphinQt2, since WiiSave should not
really be responsible for interacting with the user as a simple
Wii save importing/exporting class.
This also fixes Wii save import/export showing result dialogs twice,
once from WiiSave, and another time from DolphinQt2.
Move the import/export operation into separate functions, as it doesn't
really make sense for the constructor to do *everything*, including
printing success/failure message boxes.
The existing constructor was split into two: one that takes a path,
and another taking a title ID. This makes it more obvious what is
actually done when a path/TID is passed and also clarifies what
parameters should be passed. (No more magic 0 or "" value.)
It only needs to be updated when we changes the symbols, not every time the code widget updates and it does take a while to update them so this fixes some delay when updating the code window.
Putting the columns to resizeToContents causes way too much resizes per updates which can cause severe lags and even crashes. This only does one resize at the end of the columns.
One, which was also possible in Wx is to add an mbp after the core stopped which shouldn't be possible as it needs to add the memcheck on the core thread which wouldn't be running. The other fix is Qt specific where it doesn't clear the breakpoints on stop.
The items were editable while you cannot edit the breakpoints at the moment and the last breakpoint deleted would not cause the row count to change to 0.
This allows avoiding two copies of the executable data being created in
the following scenario (using pseudocode):
some_function()
{
std::vector<u8> data = ...;
DolReader reader{data};
...
}
In this scenario, if we only use the data for passing it to DolReader,
then we have to perform a copy, as the constructor takes the std::vector
as a constant reference -- you cannot move from a constant reference,
and so we copy data into the DolReader, and perform another copy in the
constructor itself when assigning the data to the m_bytes member
variable. However, we can do better.
Now, the following is allowable as well:
some_function()
{
std::vector<u8> data = ...;
DolReader reader{std::move(data)};
...
}
and now we perform no copy at any point in the reader's construction, as
we just std::move the data all the way through to m_bytes.
In the case where we *do* want to keep the executable data around after
constructing the reader, then we can just pass the vector without
std::move-ing it, and we only perform a copy once (as we'll std::move
said copy into m_bytes). Therefore, we get a more flexible interface
resource-wise out of it.
Not only it colors the entire row instead of just the address, but if the pc is the selected row, the pc color will overwrite the selection, this is done via a stylesheet.
This commit makes the colors hardcoded except when there is no symbols loaded, in which case, it uses the theme colors, except for the PC which is hardcoded to black on green. This makes a compromise between making use of the corespoinding theme color and the text being nicely readable on all themes.
This aligns the values to the right since It looks odd to be aligned to the left with any format other than hexadecimal. It also sets the font tot he debugger font and disallow selection as a previous commit made the selection pointless since it now relies on the current item.
It seemed impossible to SELECT an item, however, when right clicking, the CURRENT item is set to the appropriate cell, this commit makes the view use thta cell instead of the first selected one.
This makes it possible to use enums as the config type.
Default values are now clearer and there's no need for casts
when calling Config::Get/Set anymore.
In order to add support for enums, the common code was updated to
handle enums by using the underlying type when loading/saving settings.
A copy constructor is also provided for conversions from
`ConfigInfo<Enum>` to `ConfigInfo<underlying_type<Enum>>`
so that enum settings can still easily work with code that doesn't care
about the actual enum values (like Graphics{Choice,Radio} in DolphinQt2
which only treat the setting as an integer).
Dolphin doesn't use any of the WC24 files, so this can be done when
actually starting emulation in WiiRoot. The benefit of moving the
copy is that we don't need to handle temporary NANDs in a special way.
{Initialize,Shutdown}WiiRoot should only be responsible for setting the
SESSION_WII_ROOT or managing the temporary NAND directory.
Move all the content manipulation out of these functions to ensure
separation of concerns and call them after/before WiiRoot init/shutdown
to make sure they operate on the correct root.
If we don't flush the values, they persist in the register cache,
potentially resulting in the values being out of sync with PPCSTATE.
This was causing random crashes in games, mainly booting, when certain
JIT instructions were disabled, or forced to fall back to interpreter.
This excludes the second argument from template deduction.
Otherwise, it is required to manually cast the second argument to
the ConfigInfo type (because implicit conversions won't work).
e.g. to set the value for a ConfigInfo<std::string> from a string
literal, you'd need a ugly `std::string("yourstring")`.
This can be considered a hack, but it essentially neuter the bias applied on boot for both console on the RTC. This avoids having the time on boot be changes significantly while the user would want a specific RTC and it also avoids possible underflow of the RTC if it is near the epoch.
GetHandle() should really not even be part of IOFile's interface, but
since it is (for the time being), we can cull unnecessary usages of it.
In this case, the WriteBytes() function does what we need without using
the underlying handle directly.
This allows getting rid of casts. We can also leverage std::min to allow
making relevant variables const. Also make the "empty" table const to
allow it to be read-only.
Converts them from 0 == success, 1 == failure to using the built-in
standard bool. Also while we're at it, const qualify write_sector's
"sector" parameter, since nothing in the function modifies the data
being pointed to.
Avoids needing to iterate and append the characters in one case. This also
alters the function to not need to construct a temporary std::string
(QString's toUtf8() is sufficient, as QByteArray exposes iterators).
toStdString() is equivalent to retrieving the QString's underlying
QByteArray via calling QString's .toUtf8 member function and then
calling .toStdString() on the result of it (discarding the QByteArray
afterwords), so this just trims off an unnecessary step in the process.
This is also somewhat more indicative of the conversions going on:
toStdString() converts the underlying character sequence of a
QString to UTF-8, not strict ASCII, so we're really using a superset of
ASCII.
Also move it to MathUtils where it belongs with the rest of the
power-of-two functions. This gets rid of pollution of the current scope
of any translation unit with b<value> macros that aren't intended to be
used directly.
Change SettingsHandler to take a buffer instead of assuming that the
setting file to read is always on the host filesystem for more
flexibility and make it possible to use the new filesystem interface.
Given bit conversions between types are quite common in emulation
(particularly when it comes to floating-point among other things) it
makes sense to provide a utility function that keeps all the boilerplate
contained; especially considering it makes it harder to accidentally
misuse std::memcpy (such as accidentally transposing arguments, etc).
Another benefit of this function is that it doesn't require separating
declarations from assignments, allowing variables to be declared const.
This makes the scenario of of uninitialized variables being used less
likely to occur.
Keeps them all next to each other and deduplicates a few constants,
notably the PPC UIDs. Apparently I forgot that I already added them
for SetupStreamKey.
As of VS 15.7, these seem to have been removed. Given we shouldn't have
been using these for some time, just replace them with the standard
library equivalent.
This fixes building on Windows with VS 15.7
It was off by about 8 years because it was actually the same as the GC epoch, however, the reason it worked all this time was because the default RTC counter bias of the Wii was not 0, but a value that is about 8 years in seconds. This broke custom RTC as a custom RTC of the gc epoch was underflowing b ecause the wii epoch was thought to be much later.
The existing backend did not handle cases where the target exists
correctly.
This is a bug that has been around forever but was only recently
exposed when ES started to use our FS code.
Also adds some unit tests to make sure this won't get broken again.
Creating a file then opening it in read write mode is a pretty common
operation. This commit adds a helper function that makes it easier
to read and clearer.
Keeps all of the floating-point utility functions in their own file to
keep them all together. This also provides a place for other
general-purpose floating-point functions to be added in the future,
which will be necessary when improving the flag-setting within the
interpreter.
FPSCR.FEX is supposed to be a logical OR of all floating-point exception
bits masked by their respective enable bits.
Currently UpdateFPSCR() isn't called by anything in the interpreter
except for mcrfs and mffs, so this doesn't alter existing behavior that much.
However, this will be necessary in future PRs when making the interpreter more
accurate in how it sets flags.
Prevent implicit conversions to UReg_FPSCR. Given the semantics of a
random magic value and the FPSCR are different, make explicit
conversions a requirement to signify intent.
The MSR.LE bit is supposed to be set to the value of MSR.ILE upon
entering an exception vector to control whether the environment in said
vector operates as little endian or big endian. If this bit is ORed into
the LE bit, then the scenario of operating in little endian but wanting
to take exceptions in big endian will be incorrectly handled.
Analogous to File::CreateFullPath, but for the Wii filesystem so this
ensures that directories and files receive proper attributes.
(This function is technically not part of the FS sysmodule but it's in
an internal FS library that is reused in several IOS sysmodules.)
Prevents implicit construction of MSR instances from integral values.
This is beneficial, considering MSR values have an intended
representation while a regular magic value doesn't. So make these
conversions required to be explicit.
Gets rid of the need to construct UReg_MSR values around the the actual
member in order to query information from it (without using shifts and
masks). This makes it more concise in some areas, while helping with
readability in some other places (such as copying the ILE bit to the LE
bit in the exception checking functions).
The game Go Vacation (SGVEAF) currently stutters a lot because it keeps
overflowing the far code cache and all code needs to be re-jitted.
Logging this warning gives a useful hint as to what is causing the
stuttering.
Qt introduced a checkbox to toggle the debugger UI, this makes it work into a setting stored in the INI, it also makes the -d argument only in effect when enabled, in such case, it will override the INI by overriding it.
Since all FS access will go through the new FS interface (PR #6421)
in order to keep track of metadata properly, there is no need to return
absolute paths anymore.
In fact, returning host paths is a roadblock to using the FS interface.
This starts the migration work by adding a way to get paths that are
relative to the Wii NAND instead of always getting absolute paths
on the host FS.
To prepare for future changes, this commit also makes returned paths
canonical by removing the trailing slash when it's unneeded.
Eventually, once everything has been migrated to the new interface,
we can remove the "from" parameter.
Also makes y_scale a dynamic parameter for EFB copies, as it doesn't
make sense to keep it as part of the uid, otherwise we're generating
redundant shaders.
RE4's brightness screen is actually very good for spotting these.
Bug 1: Colors at the end of the scanlines are clamped, instead of a black
border
Bug 2: U and V color channels share coordinates, instead of being offset
by a pixel.
Use the newly added GetSystemDefaultInterfaceOrFallback() to return
actual information for the default interface, not just dummy
interface details.
This also fixes GetInterfaceOpt(0x4003) and gethostid() returning
inconsistent information. Prior to this change, GetInterfaceOpt(0x4003)
would return 10.0.1.30 and gethostid would give a totally unrelated IP.
These aren't dependent on calling order so we can just organize all of the statics together
instead of splitting them up over the file. This also allows us to organize a common spot for
file static variables as well.
Xlib has really terrible headers that declare non-namespaced
macros and typedefs for common words.
Just wasted 10 minutes trying to figure out why a unit test failed
to build before I remembered it was Xrandr.h conflicting with our
enum class members again.
To fix the issue, this removes the Display* parameter from the
EnableScreensaver function (which was unused) so we don't have
to include Xrandr.h anymore.
Allows us to bring includes and relevant libraries into scope by explicitly declaring linkage against the target
as opposed to using a variable. Also removes the dumping of OProfile includes into the top-level directory.
Just re-disassembled STM and found out I have made a mistake when
I changed STM stuff back in 2016.
I accidentally made STM reset the event hook on close when it should
have been done in the destructor (i.e. when IOS gets reset on console).
Verified in IDA that STM just `IOS_ResourceReply(request, IOS_OK)`
without ever resetting the hook.
Some button names should be translated, for instance Up, Left and such.
At the same time, some other button names shouldn't be translated,
for reasons that might be less obvious. In 0146456af, I removed the
_trans markers for button names that never need to be translated
(such as A and B), but that isn't actually enough to ensure that
DolphinWX won't try to translate them anyway. This commit adds a bool
that explicitly tells the GUI whether a button name should be translated.
Otherwise we'll have problems like the GUI treating the button name "B"
(which isn't supposed to be translated) as matching the translatable
string "B" (being an abbreviation of "bytes"), meaning that the button
"B" will be labeled "o" when running Dolphin in French (after
translations get pulled from Transifex the next time).
By the way, while it turned out that DolphinWX translated all button
names, it also turned out that DolphinQt2 translated *no* button names.
Go figure. This commit makes them consistent with each other.
If FPSCR[VE] is set, a result isn't supposed to be written to the destination,
just the FPSCR[VXSNAN] bit gets set, and FPSCR[FR] and FPSCR[FI] get set to zero.
If FPSCR[VE] isn't set, then we do write out a result, however, the FPSCR[FPRF]
field is updated to signify a QNaN (yes, a QNaN, the FPRF field doesn't have
a bit configuration for SNaNs).
There's no real requirement to make this const, and this should also
be decided by the calling code, considering we had places that would
simply cast away the const and carry on.
It's not common code that could be reused for, say, Citra;
it's absolutely specific to Wii emulation and only used by the Dolphin
core, so let's move it there.
Another reason for doing this is to avoid having Common depend on Core.
It was discovered that some titles rely on filesystem metadata to work
properly. Currently, in master they either simply won't find their
save files (for example Bolt) or will complain about the Wii system
memory being corrupted (on first use or every time depending on
the title).
In order to even be able to keep track of file metadata, we first need
to eliminate all direct accesses to the NAND and make all kinds of
operations go through the filesystem code added in PR 6421.
This commit starts the migration process by making SysConf use
the new FS interface.
This used to be necessary for properly cleaning up the FS state because
the old FS implementation used static state and only performed cleanup
in the close function, not in the destructor.
Now that the static state is gone, we do not need to close devices
manually anymore.
After 3a83ebc, the Show System Clock feature started using the
unfortunate combination of MM/DD/YY dates (rare outside of the US)
and 24-hour time (rare in the US) regardless of the user's locale
settings. This commit makes it use the configured locale again.
I've noticed one minor difference in behavior between now and
before 3a83ebc: The new way of setting the C/C++ locale seems to
treat "en" as "en-US", but the wx way of setting the C locale
treated it as "en-GB" (at least on Windows).
Migrates the state to be instance-based as opposed to being a flat
namespace. This keeps behavior localized to its own instantiable unit
(and forces uses of the class to also be localized, lest they cart around
an instance all over the place).
This was necessary to work around a FS timing issue which caused small
writes to take much longer than they should.
Now that we emulate timings for the FS module including its file cache,
we don't need to maintain this workaround anymore.
Everything that links in core doesn't need to see anything related to bochs, because it's only used internally.
Anything else that relies on bochs should be linking it in explicitly.
The general convention is to return a reference to the object that was
acted on, otherwise you can get into situations with errors because the
type wasn't being propagated properly
Using this in its current form would invoke undefined behavior, as it's
using a union to type pun between data types. It's also, well, unused,
so we don't need to keep it around.
We already read the necessary information with the
HostRead_Instruction() call. Internally, it calls HostRead_U32() as
well, so there's no difference in behavior.
If the locked cache isn't enabled, dcbz_l is illegal to execute
(locked cache is off, locked cache instructions don't work, makes sense)
This makes exception handling more accurate. It was previously possible to hit the DSI exception
handler when HID2[LCE] is set to zero, which isn't correct.
With this change we no longer hit the DSI handler, however we still have a lingering issue elsewhere
likely to do with exception precedence, we seem to hit the Floating Point exception handler instead
in some cases. This isn't due to the instruction itself directly however, so this is just another bug
to fix elsewhere.
CMake already has this functionality built-in. This lessens depending on the host system environment
and is more cross-platform friendly (which is always nice from a build-system point of view).
In the case we had X11 libs available, we'd allocate an XRRConfiguration instance and pass it
to the GraphicsWindow instance, but it would never actually be freed.
add_definitions and include_directories don't operate on a by-target basis, they act on a
by-directory basis (i.e. if we defined two targets, A and B, in this CMakeLists file, add_definitions
would add the definitions to the COMPILE_DEFINITIONS directory property which both A and B would
implicitly use).
The same idea applies to include_directories, only it appends to the INCLUDE_DIRECTORIES directory
property.
Instead, specify these on the target to keep scope as narrow as possible.
This is one of the conditions for an alignment exception documented in
the 750CL architecture reference manual in section 4.5.6, which also
applies to the Gekko microprocessor.
This is an exception condition documented within section 4.5.6 in the
architecture reference manual for the PPC 750CL, which also applies to
the Gekko microprocessor.
Also moves dcbz_l's implementation out of Interpreter_Paired and beside
dcbz where it belongs.
The effective address given to these instructions must be word (4 byte) aligned,
and if the address is not aligned like that, then an alignment exception
gets triggered.
We currently don't update the DSISR in this case properly, since we
didn't really handle alignment exceptions outside of ecowx and eciwx,
and even then the handling of it isn't really that great, considering
the DAR isn't updated with the address that caused the exception to
occur.
The DSISR will eventually be amended to be properly updated.
Prior to this change, it's possible for m_wake_me_up_again to be used
while it's in an uninitialized state from the exposed API.
e.g.
- Using SetEnable after construction would perform an uninitialized read.
- Using PushEvent would perform an uninitialized read by way of operator |=.
internally, an uninitialized read can happen if PullEventsInternal() is
executed before other functions.
Just to avoid the whole possibility of performing uninitialized reads,
we just give the class member a default value of false.
If the copy assignment operator is deleted, then the copy constructor
should be deleted as well, otherwise it's a hole in the API where copies
can be made (and if this were an intended case, it should be
documented).
So we delete the copy constructor and explicitly default the move
assignment and move constructor to signify this is intended to be a
move-only type.
Adjusts Common to use the ICONV_LIBRARIES variable directly and doesn't
append it to the LIBS variable.
After this, there's only one remaining usage where libraries are added
to the LIBS variable, after which it can be removed once the rest of
the targets are migrated off add_dolphin_library
This way, if we load a UID cache where the data was incomplete (e.g.
Dolphin crashed), we don't lose the existing UIDs which were previously
at the beginning.
These are bit manipulation functions, so they belong within BitUtils.
This also gets rid of duplicated code and avoids relying on compiler
reserved names existing or not existing to determine whether or not we
define a set of functions.
Optimizers are smart enough in GCC and clang to transform the code to a
ROR or ROL instruction in the respective functions.
The only place this library is needed (core) is already linked in the core target.
Also make the linkage private to create linkage failures if the dependency isn't
explicitly linked in elsewhere where it should be.
Reduces the dependency on the LIBS variable.
Return a FileHandle which will automatically close the FD when
the handle goes out of scope. For the rare cases where this behaviour
is undesirable, the FD can be released from the handle.
This is the large change in the branch.
This lets us use either the host filesystem or (in the future) a NAND
image exactly the same way, and make sure the IPC emulation code
behaves identically. Less duplicated code.
Note that "FileIO" and "FS" were merged, because it actually doesn't
make a lot of sense to split them: IOS handles requests for both
/dev/fs and files in the same resource manager, and as it turns out,
/dev/fs commands can *also* be sent to non /dev/fs file descriptors!
If we kept /dev/fs and files split, there would be no way to
emulate that correctly. I'm not aware of anything that does that (yet?)
but I think it's important to be correct.
Now that we have a proper filesystem interface, it makes more sense
to return it instead of the emulated IOS device (which isn't
really usable for any purpose other than emulated IPC).
Extract the existing FS code into a HostBackend implementing
the filesystem interface.
Compared to the original code, this uses less static state.
The open host files map is now a member variable
as it should have been. Filesystem handles are now also easier
to savestate. Some variable names and log messages were cleaned up.
Nothing else has been changed.
Add a new FileSystem class that can be used to perform operations
on the emulated Wii filesystem.
This will allow separating the IPC code (reading from and writing to
memory to handle IOS FS commands) and the actual filesystem code
in a much better way.
This also paves the way for implementing another filesystem backend
in the future -- NAND images for more complete emulation, including
filesystem metadata like permissions or file orders, which some games
and homebrew actually care about -- without needing to make any more
changes to the other parts of the codebase, in addition to making
filesystem behaviour tests easier to write.
This adds a lightweight, easy to use std::variant wrapper intended to
be used as a return type for functions that can return either a result
or an error code.
Makes our libraries explicitly link in which libraries they need.
This makes our dependencies explicit and removes the reliance on the
LIBS variable to contain the libraries that they need.
This will create a merge conflict if two PRs try to increment the
cache version at the same time, which makes it noticeable that the
PR that gets merged last needs to increment the cache version again.
We already use this for savestates and the game list cache.
Regression from 1f1dae3.
This problem doesn't happen in DolphinWX as far as I know, but if
you've ran into the problem in DolphinQt2, it will carry over to
DolphinWX because of the shared game list cache.
Minimizes repetition.
std::minmax_element can be used for the 256 * 2 case, as it's only performing byte comparisons
and thus, there will always be an element smaller than 0xffff, so it doesn't need to be included
in the set of compared values.
The SGI extension does not define calling SwapInterval with a parameter
of zero as valid. It was just lucky that drivers interpreted this as
vsync off. The EXT_swap_control extension defines zero as a valid value.
Mesa does not appear to support the EXT variant, so we fall back to
MESA_swap_control here, which also supports zero.
This is technically undefined behavior, but regardless of that, it's not
even necessary since we can just make a temporary around the MSR value
and just discard it when done with it, since all we do is query the FP
bit value with it.
Given how the hooking operates, we may not execute an instruction.
Instead of making the state a static local to the function, just make it
part of the lifecycle of the Interpreter class.
This was only ever used by the DSP assembler, and even then it was
sparsely used. Get rid of it to be consistent with types in other
sections of the DSP code.
These aren't necessary as the type being stored into a u32 are of the
same signedness and are smaller in data size, so there's no truncation
being performed.
Skip ubershader mode works the same as hybrid ubershaders in that the
shaders are compiled asynchronously. However, instead of using the
ubershader to draw the object, it skips it entirely until the
specialized shader is made available.
This mode will likely result in broken effects where a game creates an
EFB copy, and does not redraw it every frame. Therefore, it is not a
recommended option, however, it may result in better performance on
low-end systems.
The overflow check needs to occur before the condition register update
due to the fact that the summary overflow (SO) bit is used in the
updating of the condition register. If we set any overflow bits after
updating the CR, then we can potentially incorrectly report that an
overflow did not happen (in the case the SO bit wasn't set previously).
A search box is a common UI element. We don't need to explicitly tell
the user that they need to type a search term. Also,
Let's use the common "Search <items>..." placeholder text instead
and make the string shorter for localisation.
Also turns a std::string const reference into a value instance.
While this is well-defined, it does look out of place, given a new string
is being created.
ori can be used as a NOP if the two register operands are the same, and
the immediate is zero, not only if the two register operands are r0.
Also removes the check for !inst.Rc, as ori only has one encoding, and
said encoding doesn't even have a record bit in it.
This fix the awkwardness of having the symbols detection, parsing and loading related logs be in OS HLE while they don't have anything to do with that.
The OV bit is non-sticky. Therefore, after an overflow-enabled
instruction executes, if an overflow does *not* occur, then OV is
cleared. SO is sticky however, so it staying set in this case is
correct.
With this, JitAsm code doesn't have any reliance on the JIT global
variable. This means the core JIT64 code no longer relies on said
global at all. The Jit64 common code, however, still has some offenders.
Notably, EmuCodeBlock and Jit64AsmCommon are the remaining places in the
common code that make use of the global variable.
The AutoUpdate module is a generic update checker mechanism which can be
used by UI backends to trigger an auto-update check as well as the
actual update process.
Currently only configurable through .ini and the Qt implementation is
completely placeholder-y -- blocking the main thread on a network
request on startup, etc.
Ensures that upon construction of a JitBase instance, that all
underlying members within the option and state structs are guaranteed
to be initialized.
This prevents potentially using a member uninitialized in some form.
Also amends the condition that was being checked. Previously it was
checking if the destination register value was 0x80000000, however it's
actually the source register that should be checked.
This macro (that has unfortunately become the de-facto way of
introducing targets) has a lot of disadvantages that outweigh the fact
that you avoid writing two extra lines of CMake script.
- It encourages the use of variables. In a build system the last thing
we want to care about is mutable state that can be avoided.
- It only handles linking in the libraries and nothing else. It's a
laziness macro.
- We should be explicit about what we're doing by introducing the target
first, not last.
This gets the ball rolling by migrating Core off the macro. Note that
this is essentially 1-to-1 unrolling of the macro, therefore we're
still linking in all libraries as public, even though that may not be
necessary.
This can be revisited once everything is off the macro for a quicker
transition period.
Trims the direct usages of the global by making the code go through the
JIT interface (where it should have been going in the first place).
This also removes direct JIT header dependencies from the breakpoints as
well. Now, no code uses the JIT global other than JIT code itself, and
the unit tests.
All of these with the record bit set update condition register 1 with the
contents of the FPSCR's FX, FEX, VX and OX bits.
Helper_UpdateCR1() does exactly that, so we use it here to perform this
for us.
These are only used internally. This also allows us to eliminate some
symbols that get dumped into the exposed Gen namespace.
By extension this also hides the Write[X] functions from OpArg's public
interface. This is only used internally by XEmitter, so they shouldn't
be usable by anything else.
This wouldn't be much of a data reader if it can't access the
read-only data pointer in read-only contexts. Especially if it
can get a writable equivalent in contexts that aren't read-only.
It's questionable to not return a reference to the instance being
assigned to. It's also quite misleading in terms of expected behavior
relative to everything else. This fixes it to make it consistent with
other classes.
Allows the default constructor to be defaulted and ensures the default
values are associated with the member variables directly.
Also corrects a prefixed underscore in the two parameter constructor.
Given that this only contains functions from the VideoBackendBase class,
it makes more sense to move these to the relevant cpp file to keep them
all together.
This is only ever memset to zero and never used again.
This also gets rid of an instance of undefined behavior considering the
draft standard for C++17 (N4659) states at [dcl.type.cv] paragraph 5:
"
The semantics of an access through a volatile glvalue are implementation-defined.
If an attempt is made to access an object defined with a volatile-qualified type
through the use of a non-volatile glvalue, the behavior is undefined.
"
Before this, DolphinQt2 would crash at boot with an assertion error
when using a Windows debug build, at least if the Dolphin GUI
language was set to English.
Depending on which constructor is invoked, m_id or m_compute_program_id
can end up in an uninitialized state. We should ensure that the object
is completely initialized to something deterministic regardless of the
constructor taken.
This prevents Dolphin from crashing when the emulated software crashes.
AFAIK, there is absolutely no performance to enabling this with the
x64 JIT.
Eventually, we should probably just remove bMMU
(https://github.com/dolphin-emu/dolphin/pull/1831). We can't do that
yet because of the ARM JIT.
A very basic hardware test shows that the ARMMSG doesn't change until
IOS replies. (People could have disassembled IOS to verify this too...)
Console:
sending request at 00034640 - ARMMSG 133e0fa0
00000000000000000000000000000010(ack) - ARMMSG 133e0fa0
00000000000000000000000000000100(reply) - ARMMSG 00034640
Dolphin, prior to this fix:
sending request (00034640) - ARMMSG 133e0fa0
00000000000000000000000000000011(ack) - ARMMSG 00034640
00000000000000000000000000000100(reply) - ARMMSG 00034640
Dolphin, after this fix:
sending request at 00034640 - ARMMSG 133e0fa0
00000000000000000000000000000011(ack) - ARMMSG 133e0fa0
00000000000000000000000000000100(reply) - ARMMSG 00034640
(Yes, note that the X1 bit is still set. This is a bug that I will
fix in the next commit.)
The IPC interrupt is triggered when IY1/IY2 is set and Y1/Y2 is written
to even when this results in clearing the bit.
This shouldn't change anything in practice but it's a difference
that Dolphin wasn't taking into account, which made me waste some time
when I was writing a hwtest :/
This adjusts IOS IPC timing to be closer to actual hardware:
* Emulate the IPC interrupt delay. On a real Wii, from the point of
view of the PPC, the IPC interrupt appears to fire about 100 TB ticks
after Y1/Y2 is seen.
* Fix the IPC acknowledgement delay. Dolphin was much, much too fast.
* Fix Device::GetDefaultReply to return more reasonable delays. Again,
Dolphin was way too fast. We now use a more realistic, average reply
time for most requests.
Note: the previous result from https://dolp.in/pr6374 is flawed.
GetTicketViews definitely takes more than 25µs to reply.
The reason the reply delay was so low is because an invalid
parameter was passed to the libogc wrapper, which causes it to
immediately return an error code (-4100).
* Fix the response delay for various replies that come from the kernel:
fd table full, unknown resource manager / device, invalid fd,
unknown IPC command.
Source: https://github.com/leoetlino/hwtests/blob/af320e4/iostest/ipc_timing.cpp
This replaces usages of the non-standard __FUNCTION__ macro with the standard
mandated __func__ identifier.
__FUNCTION__ is a preprocessor definition that is provided as an
extension by compilers. This was the only convenient option to rely on
pre-C++11. However, C++11 and greater mandate the predefined identifier
__func__, which lets us accomplish the same thing.
The difference between the two, however, is that __func__ isn't a
preprocessor macro, it's an actual identifier that exists at function
scope. The C++17 draft standard (N4659) at section [dcl.fct.def.general]
paragraph 8 states:
"
The function-local predefined variable __func__ is defined as if a
definition of the form
static const char __func__[] = "function-name ";
had been provided, where function-name is an implementation-defined
string. It is unspecified whether such
a variable has an address distinct from that of any other object in the
program.
"
Thankfully, we don't do any macro or string concatenation with __FUNCTION__
that can't be modified to use __func__.
Currently, when immediately compile shaders is not enabled, the
ubershaders will be placed before any specialized shaders in the compile
queue in hybrid ubershaders mode. This means that Dolphin could
potentially use the ubershaders for a longer time than it would have if
we blocked startup until all shaders were compiled, leading to a drop in
performance.
- In D3D, shaders could be compiled on the main thread, blocking
startup.
- Reduced the latency between a pipeline being requested and used in all
backends in hybrid ubershader mode, when no shader stages were present.
- Fixed a case where async compilation could cause the same UID to be
appended multiple times to the UID cache.
- Fix incorrect number of threads being used when immediately compile
shaders was enabled.
Fixes a crash which could occur in platforms which do not support
buffer_storage, and EFB2RAM is enabled (which indirectly uses the
attributeless buffer).
While the code is namespaced out properly, the files weren't separated
into their own directory. This moves the files so that introducing a general
interface is easier in the future for supporting other architectures.
Lowest hanging fruit I could find with a profiler.
Not sure this stuff actually needs to be done, but assuming it is, why
not do it quickly? 10x faster, goes from 1% CPU to 0.09%.
Yes, this commit is only to blame OSX and Mali. Through the former supports unsynchronized mappings, the latter supports *no* way to stream dynamic data at all. Let's try to make bad news, as they ignore friendly feature requests. Maybe we just need to make more noise...
Some locales use non-breaking spaces as separators, so getting the
encoding right is important. If DolphinWX gets a string that isn't
valid UTF-8, it flat out won't display the string.
This enables shaders to be compiled while the game is starting, instead
of blocking startup. If a shader is needed before it is compiled,
emulation will block.
As these are stored in a map, operator< will become a hot function when
doing lookups, which happen every frame. std::tie generated a rather
large function here with quite a few branches.
We would want to improve the granularity here in the future, but for
now, this should avoid any performance loss from switching to the
VideoCommon shader cache.
This saves us from having to call GetPath when the same file is being
read over and over. (GetPath is more expensive than GetOffset due to
it iterating through parts of the file system and creating strings.)
The original reason I wanted to do this was so that we can replace
the Android-specific code with this in the future, but of course,
just deduplicating between DolphinWX and DolphinQt2 is nice too.
Fixes:
- DolphinQt2 showing the wrong size for split WBFS disc images.
- DolphinQt2 being case sensitive when checking if a file is a DOL/ELF.
- DolphinQt2 not detecting when a Wii banner has become available
after the game list cache was created.
Removes:
- DolphinWX's ability to load PNGs as custom banners. But it was
already rather broken (see https://bugs.dolphin-emu.org/issues/10365
and https://bugs.dolphin-emu.org/issues/10366). The reason I removed
this was because PNG decoding relied on wx code and we don't have any
good non-wx/Qt code for loading PNG files right now (let's not use
SOIL), but we should be able to use libpng directly to implement PNG
loading in the future.
- DolphinQt2's ability to ignore a cached game if the last modified
time differs. We currently don't have a non-wx/Qt way to get the time.
This saves us from having to hardcode strings, and it also gives
us strings in whatever format is appropriate on the current OS
(for instance, IIRC Windows uses Alt+F where other OSes use Alt-F).
This commit changes devices to always return IPCCommandResult rather
than just a return code for Open() and Close() in order to be able
to better emulate reply timing.
In hindsight, I should have considered we would want to emulate
timing when I cleaned up the device interface, but alas.
This rectifies that mistake.
There is code below that assumes the presence of those macros (by #undef'ing them), but none of the included headers provided them.
This fixes a build failure on OpenBSD where the undef'd macros _do_ get picked up later on in a compilation unit (through which include, I don't know), and thus shadow the Common::swap* functions.
tl;dr: This PR speedups dolphin on mobiles with the Mali GPU and ES 3.2
drivers by a factor of 10 by using the method with the biggest overhead.
Please keep care not to buy this shit!
The ARM driver team seems to care very well about their customers. But
bad luck, users and open source developers are *not* their customers. So
even device-independent feature requests are just ignored for *years*:
https://community.arm.com/graphics/f/discussions/4645/gl_ext_buffer_storage-support
The bad point, they neither implement any of the other common ways to
stream dynamic content in unextented GL:
- They just ignore the GL_MAP_UNSYNCHRONIZED_BIT flag
- They don't support on-device buffer updates and just stall with
glBufferSubData
It seems like no benchmark is using any dynamic content - and like no
customer cares about anything but benchmarks, or users...
We have a flag to disable the glBufferSubData way, this PR adds the flag
to also disable the unsychronized mapping way. The second one is
available since their ES 3.2 update, but slow as hell.
So how to continue? The last remaining technical way to stream dynamic
content at all is to alloc a new buffer per draw call with glBufferData.
This is very gross, but still a factor 10 speedup compared to stalling
the GPU. Small tests shows that you can expect another 3-5 times speedup
with EXT_buffer_data, so Mali would be on pair with Adreno here. So if
you have bought such a device unfortunately, please try to make noise on
your vendor forums/support and ask for this extension. If you are going
to buy a new mobile, I'd recormend to avoid *any* mobile with a Mali GPU
in it.
We now differentiate between a resize event and surface change/destroyed
event, reducing the overhead for resizes in the Vulkan backend. It is
also now now safe to change the surface multiple times if the video thread
is lagging behind.
The option is named DisableCopyToVRAM under the Hacks section in
GFX.ini. It is intentionally not exposed to the GUI, as users should not
need to use it under normal circumstances. The main use is debugging
issues in the EFB-to-RAM shaders.
This could cause glReadPixels() calls which assume no buffer is bound
(e.g. CPU EFB access) to fail. The problem was limited to devices which
don't support persistent mapping, as the map path is not otherwise.
Whenever udev_monitor_receive_device() returns a non-null pointer,
the device must be unref'd after use with udev_device_unref().
We previously missed some unref calls for non-evdev devices.
Both libusbhid (system library) and libhidapi (3rd party library)
provide a function called hid_init. Dolphin was being linked to both.
The WiimoteScannerHidapi constructor was calling hid_init without
arguments. libusbhid's hid_init expects one argument (a file path).
It was being called as if it was defined without arguments, which
resulted in a garbage path being passed in, and because of that,
the Qt GUI was failing to launch with the following error:
'dolphin-emu-qt2: @ : No such file or directory'
It's not guaranteed that the eventfd is smaller than the monitor fd,
because fds are not always monotonically allocated. To select()
correctly in all cases, use the max between the monitor fd and eventfd.
The console appears to behave against standard IEEE754 specification
here, in particular around how NaNs are handled. NaNs appear to have no
effect on the result, and are treated the same as positive or negative
infinity, based on the sign bit.
However, when the result would be NaN (inf - inf, or (-inf) - (-inf)),
this results in a completely fogged color, or unfogged color
respectively. We handle this by returning a constant zero for the A
varaible, and positive or negative infinity for C depending on the sign
bits of the A and C registers. This ensures that no NaN value is passed
to the GPU in the first place, and that the result of the fog
calculation cannot be NaN.
- Smplification of graphics backend startup/shutdown.
- Don't send complete message until CPU is ready to execute.
- Remove redundant stop message.
- Remove OSD message with backend name.
Otherwise we might get UB if the value we cast is larger than the
max value of the underlying type that the compiled picked for the enum.
I haven't done any extensive check through Dolphin to find cases
of this, I'm just fixing the cases I already know of.
Tested on a linux Intel Skylake integrated graphics with
blend_func_extended force-disabled, as it's the only platform I have
that doesn't crash with ubershaders and supports fb_fetch
It seems it doesn't like modifying inout variables in place - so instead
use a temporary for ocol0/ocol1 and only write them once at the end of
the shader
The advantage of std::list is that elements can be removed from the
middle efficiently, but we don't actually need that, because the
ordering of the elements doesn't matter for us. We can just replace the
element we want to remove with the last element and then call pop_back.
Replacing list with vector should speed up looping through the elements.
GameTracker's usage of GameFileCache is thread-safe even without
using a mutex. All of its access to GameFileCache happens on the
thread m_load_thread, except for the call to GameFileCache::Load,
which finishes before m_load_thread starts executing.
Starting with 5.0-5504, trying to launch DolphinQt2 from Visual Studio
shows the error message "The operation could not be completed. Undefined
error" instead of launching the exe file. (The exe gets created
correctly, it just doesn't get launched. It's possible to work around
the problem by launching the exe manually outside of Visual Studio, but
then you won't have an attached debugger automatically.) This commit
fixes that by removing headers from DolphinQt2.vcxproj's ClInclude list
that already are in the QtMoc list. (The problem was originally about
LogWidget.h and LogConfigWidget.h, but 5.0-5600 made the problem be
about CheatWarningWidget.h and GeckoCodeWidget.h instead.)
There are two reasons for this change:
1. It removes many repetitive lines of code.
2. I think it's a good idea to enable the use of old-style section
names even for settings that previously haven't been settable in game
INIs. Mixing the two styles in INIs (using the new style only for new
settings) is not ideal, and people on the forums don't even seem to
know that the new style exists (nobody knew a way to set ubershader
settings per game, for instance). Encouraging everyone to start using
only the new style might work long-term, but it would take take time
and effort to make everyone get used to it. Considering that this commit
*reduces* the amount of code by adding the ability to use old-style
names for more settings, I'd say that adding this ability is worth it.
Trying to force the XSI version by undefining _GNU_SOURCE can lead
to compilation errors on some systems because of headers expecting
that _GNU_SOURCE is defined.
This commit uses define checks to detect which version we have.
I tried making an overloaded function (int and const char*) instead,
but that led to a warning about one of the variants being unused.
The Time Base Register was added under the BAT registers. TBL and TBU
were ORed together to get one 64-bit value to display. It is labeled TB
The Graphics Quantisation Registers were added under the Segment
Registers. They are Labeled GQR0-GQR7.
All new registers are read only.
GLES doesn't support C-style array initialisers, so stuff like:
Type var[2] = {
VALUE_A,
VALUE_B
};
isn't supported in GLES (it was added in
GL_ARB_shading_language_420pack).
The texture conversion shader used this, so would fail to compile on
GLES.
The PC offset ADRP() path takes a s32 value, but the input offset was
being tested as abs(ptr) < 0xFFFFFFFF. This caused values between
0x80000000 and 0xFFFFFFFF to incorrectly use this path, despite the
offsets not being representable in an s32.
This caused a crash in the VertexLoader on android 8.1 immediate in wind
waker (and possibly all other apps on android 8.1) as the jit and data
sections happened to be loaded 4gb apart in virtual memory, causing some
pointers to hit this
Some homebrew expect exception handlers to be present -- which is
almost always the case on console, since most of the time homebrew are
launched from either a libogc or SDK title) -- and break if they are
not. To fix this, we just need to include default, dummy handlers.
Set HID0, HID4, GPR1 to values that are used by libogc for
initialisation. This makes boots more similar to a launch
from the HBC or another loader, since normally the registers
have already been initialised by the loader.
This fixes a crash in homebrew that assume GPR1 points to a correct
location and attempt to use it before initialising registers.
HLSL does not define roundEven(), only round(). This means that the
output may differ slightly for OpenGL vs Direct3D. However, it ensures
consistency across OpenGL drivers, as round() in GLSL can go either way.
These three instructions use the B field (bits 16-20 of the opcode)
to determine what the operand register is. However, the code was
using the path that uses the C field (bits 21-25).
This amends the code to use the B field (and also fixes the 64-bit PPC
opcodes, because why not?).
Fixes issue 10683.
This fixes the rendering of the scan visor in Metroid Prime 2: Echoes,
as seen in https://fifoci.dolphin-emu.org/dff/mp2-scanner/
The alpha channel was off-by-one on Ivy Bridge due to the rounding
after multiplication with colmat. This commit removes this matrix
altogether in most cases, making them simple GLSL swizzles.
This will generate one shader per copy format. For now, it is the same
shader with the colmat hard coded. So it should already improve the GPU
performance a bit, but a rewrite of the shader generator is suggested.
Half of the patch is done by linkmauve1:
VideoCommon: Reorganise the shader writes.
Currently, a simple typo in the system name will trigger an assert
message that complains about a "programming error". This is not
user friendly and misleading.
So this changes GetSystemFromName to return an std::optional, which
allows for callers to check whether the system exists and handle
failures better.
Manually convert each argument to a UTF-8 std::string, because the
implicit conversion for wxCmdLineArgsArray to char** calls ToAscii
(which is obviously undesired).
Fixes https://bugs.dolphin-emu.org/issues/10274
Also skips swapping the window system buffers in headless mode, as there
may not be a surface which can be swapped in the first place. Instead,
we call glFlush() at the end of a frame in this case.
Cel-damage uses the color from the lighting stage of the vertex pipeline
as texture coordinates, but sets numColorChans to zero.
We now calculate the colors in all cases, but override the color before
writing it from the vertex shader if numColorChans is set to a lower value.
This was causing an issue where DolphinQt couldn't save graphics options
(DolphinWX doesn't hit this code path), because this function was being
called before the in-memory config was flushed to disk.
With this PR, the in-memory config isn't reset, and only SYSCONF-related
variables may get changed.
7f0834c9 moved the locations of the Real XFB (now XFB to RAM) and
Disabled XFB (now Immediate Mode) settings. There are programs
other than Dolphin that parse DTM headers, so this is not good.
Note that Immediate XFB actually is the inversion of Disabled XFB.
I hope that's not too much of a problem...
All file scope variables are able to be made internally linked.
CD3DFont is essentially used as an extension to the utility interface, so
this is able to be made internal as well, removing a global from
external view.
This lets Dolphin know if a configured GameCube Controller should actually
be treated as connected or not.
Talked to @JMC47 a bit about this last night. My use-case is that all of
my controllers are the same hardware (Xbox One controllers) so share the
same configuration (modulo device number). Treating them all as always
connected isn't a problem for most games, but in some (Smash Bros.) it
forces me to go find a keyboard/mouse and unconfigure any controllers
that I don't actually have connected. Hotplugging devices (works on macOS,
at least) + this patch remove my need to ever touch the Controller Config
dialog while in a game.
This patch makes the following changes:
- A new `BooleanSetting` in `GCPadEmu` called "Always Connected", which
defaults to false.
- `ControllerEmu` tracks whether the default device is connected on every
call to `UpdateReferences()`.
- `GCPadEmu.GetStatus()` now sets err bit to `PAD_ERR_NO_CONTROLLER` if
the default device isn't connected.
- `SIDevice_GCController` handles `PAD_ERR_NO_CONTROLLER` by imitating the
behaviour of `SIDevice_Null` (as far as I can tell, this is the only use
of the error bit from `GCPadStatus`).
I wanted to add an OSD message akin to the ones when Wiimotes get
connected/disconnected, but I haven't yet found where to put the logic.
This is already initialized in the class definition. This would
previously cause a -Wreorder warning on macOS, as m_config is
defined after m_currently_mapped.
Originally, Layer contained a std::map of Sections, which containted a std::map
containing the (key, value) pairs. Here we flattern this structure so that only
one std::map is required, reducing the number of indirections required and
vastly simplifying the code.
We need this because VS currently doesn't consider
std::is_trivially_copyable<typename
std::remove_volatile<SCPFifoStruct>::type>::value
to be true and because no compiler should consider it
to be true if we replace the volatiles with atomics.
No code is relying on this unexplained null byte check, since
the only code that calls UTF16ToUTF8 on non-Windows systems
is UTF16BEToUTF8, which explicitly strips null bytes.
Axis range was previously calculated as max + abs(min), which relies on the assumption that
min will not exceed 0. For (min, max) values like (0, 255) or (-128, 127), which I assume to
be the most common cases, the range is correctly calculated as 255. However, given (20,
235), the range is erroneously calculated as 255, leading to axis values being normalized
incorrectly.
SDL already handles this case correctly. After changing the range calculation to max - min,
the axis values received from the evdev backend are practically identical to the values
received from the SDL backend.
We shouldn't try to create folder names that contain characters
such as : or / since they are forbidden or have special meanings.
(No officially released disc uses such characters, though.)
There has been a lot of confusion about what the CPU clock override
section does among users, and looking at it… I’m not surprised! It
doesn’t directly state which CPU clock rate is being overridden!
This small change adjusts the language to clarify that the emulated CPU
is being adjusted.
The main problem was that the volume of the mixer wasn't savestated.
The volume is typically 0 at the beginning of a game, so loading a
savestate at the beginning of a game would lead to silent DTK audio.
I also added savestating to StreamADPCM.cpp.
Nowadays that Dolphin detects regions of discs properly and doesn't
force programs with unknown regions (such as homebrew) into running
under a certain region, the "Force Console as NTSC-J" option is
practically useless for making anything run correctly. Enabling it
is however an easy way to totally break many non-Japanese games.
The earlier code always tried to use TitleDatabase for getting
title names, but that didn't work for disc-based games, because
there was no way to get the maker ID.
Unlike VEN, the endpoint is determined by the value at 8-12.
If it's non-zero, HID submits the request to the interrupt OUT
endpoint. Otherwise, the request is submitted to the IN endpoint.
This commit changes HIDv5 to keep track of endpoints (like IOS does)
and use them when submitting interrupt transfers.
This implements /dev/usb/hid v5, found in IOS57, IOS58 and IOS59.
This is an initial implementation that ignores some differences
with VEN because I lack understanding of what IOS is actually doing
sometimes. These are documented on the WiiBrew article:
https://wiibrew.org/wiki//dev/usb/hid_(v5)
One major difference that this implementation handles is about IDs.
It turns out Nintendo has decided to include the interface number in
the top byte of HIDv5 device IDs, unlike VEN -- even though everything
else about ioctl 1 is otherwise the same!
USBv5 IOS resource managers share most of their code. Some ioctls
are even completely the same! So let's separate the common code
from the VEN specific stuff to make HIDv5 easier to implement.
The descriptor copy code is not actually the same in HIDv4 and VEN,
so it did not make a lot of sense to put it in USB/Common.cpp.
Separate and move it to HIDv4 and VEN.
This cleanup is important because there are even more differences
between HIDv4 and HIDv5.
Fix the device ID struct to reflect the actual structure used by IOS.
It turns out that offset 2 is the internal device index. The reason
that field seemed to be "0x1e - interface_number" is that IOS only
keeps track of 32 devices and always looks for free entries from
the end of the internal array. With each USB interface being exposed
as a separate USBv5 device, "0x1e - interface_number" was mostly
correct... but wrong!
We also made the assumption that the interface number can be
identified from just a USBV5 device ID, which is definitely not true.
VEN (and HID) keep track of the interface number in the internal struct
instead of "reconstructing" it from the device ID (which is normally
not possible if we were generating IDs correctly)
This commit fixes all of these inaccuracies.
Some lines of code in Dolphin just plainly grabbed the value of
g_ActiveConfig.iEFBScale, which resulted in Auto being treated as
0x rather than the actual automatically selected scale.
This reverts commit 1fc910b3ea,
replacing the old INI setting EFBScale with a new INI setting
called InternalResolution, which has a simpler mapping:
| EFBScale | InternalResolution
----------------- | -------------------- | --------------------
Auto (fractional) | 0 |
Auto (integral) | 1 | 0
1x | 2 | 1
1.5x | 3 |
2x | 4 | 2
2.5x | 5 |
3x | 6 | 3
4x | 7 | 4
5x | 8 | 5
6x | 9 | 6
All the fractional IRs were removed in f090a943.
It is not possible to tell whether DLC contents are supposed to be
present on the NAND or not, because they're treated as "optional".
So this commit changes the NAND check to not consider missing
contents for DLC titles as an issue.
"N/A" can be awkward to handle in translations.
I don't think there's much point in showing "N/A" rather than
leaving the description box blank, so let's just leave it blank.
Use std::string(cstring, strnlen(cstring, max_length)) instead of
trying to remove extra null characters manually, which is a bit
ugly and error prone.
And indeed, the original code contained a bug which would cause
extra NULLs to not be removed at all if the string did not
end with a NULL -- causing issues down the road when constructing
paths for sub-entries.
Because the Wii NAND size is finite, mark titles that were installed
only for booting as temporary, and remove them whenever we need to
install another title (to make room). This is exactly what the
System Menu does for temporary SD card title data.
Also clean up the way the system menu label is updated. We don't want
to access the NAND while emulation is running, and especially not
that many times per second on an unpredictable timing.
This commit removes the last usage of NANDContentManager in IOS code.
Another cleanup change is that loading ARM (IOS) binaries is now done
by the kernel in the BootIOS syscall, instead of being handled as a
special case in the MIOS code. This is more similar to how console
works and lets us easily extend the same logic to other IOS binaries
in the future, if we decide to actually load them.
This removes the hack that enables directly booting from WADs
without installing them first for the following reasons:
1. It makes the NAND content handling much more complicated than what
it should be and makes future changes like permissions or booting
NAND titles without a WAD more annoying to implement.
Because of this hack, we needed an extra level of abstraction
(NANDContent*) which has to read tons of things from the NAND, even
most of the time it's useless. This in turn forces us to have
caching, which is known to break titles and requires manual cache
invalidations. Annoying and error prone.
2. It prevents the WAD boot code from being easily accurate. With this
change, we can simply reuse the existing launch code, and ask IOS
to launch the title from the NAND.
3. The hack did not work that well since it did not cover a lot of ES
commands. And it works even less since the ES accuracy fixes.
This results in Dolphin returning inconsistent results: a
lot of the ES "DI" commands will just fail because the active title
is not installed on the NAND. uid.sys is not changed, etc.
And I'm not even talking about FS stuff -- where this would still
totally fail, unless we add even more unnecessary hacks.
This is not just theoretical -- the system menu and the Wii Shop are
known to behave strangely because the hack damages the NAND
structure, and we've already had several users report issues.
This commit makes it so WADs are always installed prior to launching.
A future commit will remove any code that was there only for the hack.
The GameCube's sample rate is slightly different due to a hardware bug.
The exact numbers are (54000000 / 1124) for GameCube and (54000000 / 1125)
on Wii. I also modified 32KHz mode. This fixes audio desyncs in several
GameCube games and severe issues in Sonic Mega Collection.
This updates the maker data to (mostly) mirror that of the Wiki:
https://wiki.dolphin-emu.org/index.php?title=GameIDs
Only maker ids from that page are now included in Dolphin. This
means no homebrew/unofficial makers.
Also, separate multiple maker names with a slash
A bunch of changes, looks mainly like bug fixes and code cleanup.
Notable changes:
- `cubeb_get_min_latency`'s signature was changed to take params via
pointer, requiring Dolphin code to be tweaked in two places.
- A fix for kinetiknz/cubeb#320, as reported by @shuffle2
- Fixed build on FreeBSD (kinetiknz/cubeb#344), as contributed by @endrift
Fixes a regression which broke running several Dolphin instances at the
same time on Windows. Thanks to exjam for spotting the issue
pretty much immediately. Sorry about that!
Also changes the file names to be more consistent on all platforms.
Assign a name to the CreateFileMapping handle on Win32 so third party
applications can read from Dolphin's memory and integrate with the
current emulation.
Built and tested, multiple sessions are still possible without
collisions.
There was a race condition between the video thread and the host thread,
if corrections need to be made by VerifyValidity(). Briefly, the config
will contain invalid values. Instead, pause emulation first, which will
flush the video thread, update the config and correct it, then resume
emulation, after which the video thread will detect the config has
changed and act accordingly.
Drivers can return VK_ERROR_OUT_OF_DATE_KHR from vkQueuePresentKHR, and
we should resize the image in this case, as well as when getting it back
from vkAcquireNextImageKHR.
Change the repair logic to fix issues more aggressively by deleting bad
titles. This is necessary because of a bug in Dolphin's WAD boot code.
The UI code was updated to inform the user about titles that will be
deleted if they continue a repair, before deleting anything.
Old versions of Dolphin are so broken regarding NAND handling that
we need this to repair common issues and avoid issues with titles
like the System Menu or the Wii Shop.
This isn't an exhaustive check, but this will catch most issues
and offer to fix them automatically (if possible).
Some of my WiiWare games does not have a maker :
- Blue's Journey : EAFPJ8
- Magician Lord : EACPJ8
- The King of Fighters '94 : EAGPJ8
- The Last Ninja : C9XPGX
- World Games : C9ZPGX
I noticed the Strong Bad games, FAST - Racing League, and Tetris Party
were lacking info in the game lists' maker column.
This adds the information based on the games' MakerID.
The newer title dumpers don't clobber tickets anymore (that's good!),
which means personalised tickets still have the console specific data
used to decrypt the title key in them. Dolphin should ignore that data
when importing WADs, because the title key has already been decrypted,
and we must not try to decrypt it *again*.
Makes the toolbar look more comfortable instead of all squished
together, and more similar to our current look.
Instead of setting a hardcoded minimal size for buttons, MakeActions()
now uses the maximum size hint width.
* remove useless units after 'zero' values
* reduce the size of 'Dolphin' to be more reasonable and look better
* avoid hardcoding the normal and small font sizes
Just create the AboutDialog on the stack -- the actual object lives on
the heap anyway, since Qt uses the pimpl idiom. Removes the need for
an explicit new and a special delete on close attribute.
EmulationStateChanged is functionally correct right now, but
ConfigChanged expresses more semantically why the config setting gets
re-read and the widgets updated.
There are two special cases that the DSP accelerator handles in a
special way: when the end address is of the form xxxxxxx0 or
xxxxxxx1.
For these two cases, the normal overflow handling doesn't apply.
Instead, the overflow check is different, the ACCOV exception never
fires at all, the predscale register is not updated, reads are not
suspended, and if the end address is 16-byte aligned, the DSP loops
back to start_address + 1 instead of the regular start_address.
When an ACCOV is triggered, the accelerator stops reading back anything
and updating the current address until the YN2 register is set.
This is kept track of internally by the DSP; this state is not exposed
via any register.
However, we need to emulate this behaviour correctly because some
ucodes rely on it (notably AX GC); failure to emulate it will result
in reading past the end and start address for non-looped voices.
When the current address is xxxxxxxf, after doing the standard ADPCM
decoding and incrementing the current address as usual to get the
next address, the DSP will update the predscale register by reading
2 bytes from memory, and add two to get the next address.
This means xxxxxx10 cannot be a current address, as the DSP goes
from 0f to 12 directly.
A more serious issue with the old code is that if the start address
is 16-byte aligned, some samples will always be skipped, even when
that should not be the case.
An easy way to test whether this behaviour is correct is to check
the current address register and the predscale after each read.
Old code:
...
ACCA=00000002, predscale=<value>
ACCA=00000003, predscale=<value>
...
ACCA=0000000f, predscale=<value>
ACCA=00000010, predscale=<another value>
ACCA=00000013, predscale=<another value>
ACCA=00000014, predscale=<another value>
...
New code (and console):
...
ACCA=00000002, predscale=<value>
ACCA=00000003, predscale=<value>
...
ACCA=0000000f, predscale=<value>
ACCA=00000012, predscale=<another value>
ACCA=00000013, predscale=<another value>
...
Slightly cleaner, allows DSP accelerator behaviour to be
added to both HLE and LLE pretty easily, and makes the accelerator
easier to unit test.
I chose to include all accelerator state as private members, and
to expose state that is accessible via registers with getters/setters.
It's more verbose, yes, but it makes it very clear what is part of
the accelerator state and what isn't (e.g. coefs).
This works quite well for registers, since the accelerator can do
whatever it wants internally. For example, the start/end/current
addresses are masked -- having a getter/setter makes it easier to
enforce the mask.
const char[1] and wxString() can both be converted to multiple common
types, so this results in an ambiguous conditional expression
compilation error (C2445)
These rely on instance state, or are used within instance-based class
member functions, so they should belong to the instance itself instead
of being file statics.
The logic is entirely the same; only the inputs and outputs are
different, so deduplicating makes sense.
This will make fixing accelerator issues easier.
Ideally Common.h wouldn't be a header in the Common library, and instead be renamed to something else, like PlatformCompatibility.h or something, but even then, there's still some things in the header that don't really fall under that label
This moves the version strings out to their own version header that doesn't dump a bunch of other unrelated things into scope, like what Common.h was doing.
This also places them into the Common namespace, as opposed to letting them sit in the global namespace.
SetFormat() is only ever used internally. ResetBuffer() is only
used to implement the VertexManagerBase class interface, so
there's no need to make it protected.
The "X.h" header *just* contains protocol constants, not functions or
typedefs - so stuff like "Display" and "Window" are not defined unless
you include "Xlib.h".
"Xrandr.h" happens to include "Xlib.h" itself, so enabling xrandr
effectively worked around this issue.
If we allocate a large amount of memory (A), commit a smaller amount,
then allocate memory smaller than allocation A, we will have already
waited for these fences in A, but not used the space. In this case,
don't set m_free_iterator to a position before that which we know is
safe to use, which would result in waiting on the same fence(s) next
time.
Calling vkCmdClearAttachments with a partial rect, or specifying a
render area in a render pass with the load op set to clear can cause the
GPU to lock up, or raise a bounds violation. This only occurs on MSAA
framebuffers, and it seems when there are multiple clears in a single
command buffer. Worked around by back to the slow path (drawing quads)
when MSAA is enabled.
Before this change, we simply fail if the device does not expose one
queue family that supports both graphics and present. Currently this is
fine, since devices tend to lay out their queues in this way. NV, for
instance, tends to have one queue family for all graphics operations and
one more for transfer only. However, it's not a hard requirement, and it
is cheap to use a separate queue, so we might as well.
Currently, this is only the logic op bit, but this will be extended to
the framebuffer fetch/blend modes. In the future, when/if we move to
VideoCommon pipelines, this state will be part of the pipeline UID
anyway, and we can mask it out in the backend by using a two-level map,
so the shaders/programs are shared.
Based on hardware tests, masking occurs for the accelerator registers.
This fixes Red Steel and Far Cry Vengeance, which rely on this behavior
when reading back the current playback position from the DSP.
This reverts commit d23fd17e1a.
Dynamic sampler indexing is broken in VK_NV_glsl as of 385.41. The
performance gap doesn't seem to be as wide with the updated driver, so
to save maintaining two code paths, it's easier to just drop the
extension support completely.
ImgTec's driver uses a major.minor@changeID versioning system
This is packed into a double so "1.9@4850625" becomes "109.4850625"
The next release brnach is expected to be 1.10, hence the need for 2
digits for the branch minor.
The changeID should be unique for each build, but is shared over all
branches, so only makes sense to compare withing a branch.
It's likely branch 'major' versions will be used for major hardware
revisions, and the drivers for both maintained in parallel. Thus it
may not make sense to compare versions between different major
verisons - if/when this happens we can hook up a DriverDetails::Family
as needed.
CNTVCT_EL0 is force-enabled on all linux plattforms.
Windows is untested, but as this is the best way to get *any* low
overhead performance counters, they likely use it as well.
Within Cleanup(), it is called at *every* end of the block. This generates bigger code,
but it is the only way to handle blocks with multiple exit nodes.
This optimisation doesn't work on PowerVR's Vulkan implementation. We
(incorrectly) disallow Framebuffer objects to be used with a different
load or store op than that which they were created with, despite the
spec allowing such.
This fixes the windwaker intro "smearing"
Modernizes the arrays and makes future simplifications possible (e.g. usages within the software renderer).
It also makes cases where we use array->pointer decay explicit.
This apparently fixes https://bugs.dolphin-emu.org/issues/10499 somehow.
The first changed line of this commit is just for performance - the
second changed line is where the difference in behavior is.
Since all queues are FIFO data structures, the name wasn't informative
as to why you'd use it over a normal queue. I originally thought it had
something to do with the hardware graphics FIFO.
This renames it using the common acronym SPSC, which stands for
single-producer single-consumer, and is most commonly used to talk about
lock-free data structures, both of which this is.
Prevents resource managers that shouldn't be visible from being exposed
to titles.
This adds a new function to get features for an IOS version, and also
moves the version checks from the modules themselves to VersionInfo.
This hopefully documents some of the differences between IOS better
and should be slightly cleaner than having random version checks.
* IOCTL_WFSI_PREPARE_DEVICE -> IOCTL_WFSI_IMPORT_TITLE_INIT
(equivalent of ES_ImportTitleInit, also the official name)
* IOCTL_WFSI_IMPORT_TITLE -> IOCTL_WFSI_IMPORT_TITLE_CANCEL
(equivalent of ES_ImportTitleCancel)
The class NonCopyable is, like the name says, supposed to disallow
copying. But should it allow moving?
For a long time, NonCopyable used to not allow moving. (It declared
a deleted copy constructor and assigment operator without declaring
a move constructor and assignment operator, making the compiler
implicitly delete the move constructor and assignment operator.)
That's fine if the classes that inherit from NonCopyable don't need
to be movable or if writing the move constructor and assignment
operator by hand is fine, but that's not the case for all classes,
as I discovered when I was working on the DirectoryBlob PR.
Because of that, I decided to make NonCopyable movable in c7602cc,
allowing me to use NonCopyable in DirectoryBlob.h. That was however
an unfortunate decision, because some of the classes that inherit
from NonCopyable have incorrect behavior when moved by default-
generated move constructors and assignment operators, and do not
explicitly delete the move constructors and assignment operators,
relying on NonCopyable being non-movable.
So what can we do about this? There are four solutions that I can
think of:
1. Make NonCopyable non-movable and tell DirectoryBlob to suck it.
2. Keep allowing moving NonCopyable, and expect that classes that
don't support moving will delete the move constructor and
assignment operator manually. Not only is this inconsistent
(having classes disallow copying one way and disallow moving
another way), but deleting the move constructor and assignment
operator manually is too easy to forget compared to how tricky
the resulting problems are.
3. Have one "MovableNonCopyable" and one "NonMovableNonCopyable".
It works, but it feels rather silly...
4. Don't have a NonCopyable class at all. Considering that deleting
the copy constructor and assignment operator only takes two lines
of code, I don't see much of a reason to keep NonCopyable. I
suppose that there was more of a point in having NonCopyable back
in the pre-C++11 days, when it wasn't possible to use "= delete".
I decided to go with the fourth one (like the commit title says).
The implementation of the commit is fairly straight-forward, though
I would like to point out that I skipped adding "= delete" lines
for classes whose only reason for being uncopyable is that they
contain uncopyable classes like File::IOFile and std::unique_ptr,
because the compiler makes such classes uncopyable automatically.
I'm not sure why this hasn't popped up as an error on the buildbots,
but the build fails on my new install of VS2017. The error is C2445:
result type of conditional expression is ambiguous: types 'wxString'
and 'const char [1]' can be converted to multiple common types
to get bigger, breaking an optimization. This forces the emitter to use a
32bit pointer instead of an 8bit one, fixing the issue at the expense of
efficiency.
Seems like I was wrong that ANDI2R doesn't require a temporary register here.
There is *one* case when the mask won't fit in the ARM AND instruction:
mask = 0xFFFFFFFF
But let's just use MOV instead of AND here for this case...
Currently, GameFile returns a generic banner if the file didn't have one
available (either because the file format doesn't support it, or because
it's a Wii file without an associated save).
It makes more sense to handle the lack of banner in the UI layer. The
game list will use the generic missing banner explicitly (no change from before), and the game info window now omits the banner display entirely if the file didn't have one (since it's not useful to display/allow the user to save the "missing banner" banner).
Given a relatively recent proposal (P0657R0), which calls for deprecation of putting stuff into the global namespace when using C++ headers, this just futureproofs our code a little more.
Technically this is what we should have been doing initially, since an
implementation is allowed to not provide these types in the global
namespace and still be compliant.
It's strange to see GameTracker add its own initial paths in
construction, because you might expect a race condition where the
GameLoaded signal is emitted before it gets connected to in
GameListModel.
In fact, this doesn't happen, but only because of how it abuses the Qt
signals mechanism to load files asynchronously: GameLoader emits a
GameLoaded signal which gets forwarded to the GameTracker::GameLoaded
signal _after_ control returns to the event loop, at which point
GameListModel has connected.
This commit moves the logic of adding initial paths out of GameTracker
to a point after the signals are connected, which is more obvious and
doesn't rely on how GameTracker implements concurrency.
ifstream::read() sets the failbit if trying to read over the end, which
means that (!input) would be hit for the 'last' block if it wasn't
exactly BSIZE (1024) bytes.
Makes it easier to turn off general IOS messages that can be
distracting (e.g. /dev/net/ssl being opened hundreds of time...)
without losing the ability to view WFS messages.
The opagent library was (incorrectly) marked as a dependency for "Core"
instead of "Common".
When linked with --as-needed, any symbols the linker can tell are not
used are discarded. As the link is done in command-line order, and the
Core library (and dependencies) are processed before Common, it would
link in Core, then opagent, but as at that point no opagent symbols are
used the whole opagent library would be discarded.
Moving the opagent library to be a dependency of Common fixes this, as
after the Common library is linked, there *are* opagent symbols used.
This helpers are not for general CR calculation, they are just for the
common case of the sign extended result of integer instructions if the
rc bit is set.
They must not be used by other instructions like cmp, so there is no
need to be as flexible.
cmpi shall compare two signed 32 bit values. The used difference a-b
may overflow and so the resulting 32 bit value can't represent it.
A correct way would be cr = s64(a) - s64(b) and it should be done in
this way in the JITs, but the Interpreter shall implement the most
readable way.
Also drops the now unused helper function.
The switch statements in these functions appear to get transformed into
an if..else chain on NVIDIA's OpenGL/Vulkan drivers, resulting in lower
performance than the D3D counterparts. Transforming the switch into a
binary tree of ifs can increase performance by up to 20%.
Since we don't want users to have to configure the region manually
and always enforce one automatically, we should fall back to a region
that was likely to be chosen by the user instead of always using
PAL whenever the title region cannot be detected.
Dolphin doesn't mess with installed NAND titles like the system menu,
so it is a reliable indicator of what region the user wants.
"Pad size" just doesn't make much sense. Let's go with "Buffer size"
instead, since the control for it is labeled "Buffer".
(Another possibility is "Pad buffer size", but I'm against that,
because we've stopped referring to controllers as "pads" in almost
all GUI strings.)
* Add missing Language setting loading/saving. This was added after the
original OnionConfig PR, which is why support for it was missing.
* Change MovieConfigLoader to reuse ConfigInfos. Less duplication.
* Extract MovieConfigLoader::Save into SaveToDTM. The DTM should use
the current config and not just the movie layer. This makes more
sense than just saving the movie layer, which may not always exist,
and also fixes a crash that would happen when creating a new
recording because the movie layer wouldn't exist in that case.
(Plus, having to get the loader from the layer and call ChangeDTM
on it manually is not very pretty.)
Not really used anywhere yet, but useful for not having to duplicate
config locations and for getting rid of conflicts when I get around
to rebase my Main.Core and Main.DSP porting PR.
Settings that come from the SYSCONF are now included in Dolphin's
config system as part of the base layer. They are handled in a
special way compared to other settings to make sure they are only
loaded from and saved to the SYSCONF (to avoid different, possibly
contradicting sources of truth).
This could cause the first branch of the bootucode procedure, which
takes its parameters from the AX registers, to run during the ROM init
sequence. Since the ROM doesn't set any of the AX registers, the values
aren't meaningful, and can cause bad DMA transfers and crashes.
This adds a WiiWad constructor that takes a BlobReader, so that the
class can be used with more than just files from the host filesystem.
Required for using WiiWad with WADs from update partitions.
Must be 9 characters at most; otherwise the serial number will be
rejected by SDK libraries, as there is a check to ensure the string
length is strictly lower than 10.
This was breaking Metroid Prime 2: Echoes’s scanner in some rooms, such
as the one in https://fifoci.dolphin-emu.org/dff/mp2-scanner/
It was found on Ivy Bridge on Mesa, the alpha value read back from the
EFB was off-by-4 in multiple objects, which was a conversion error
because int4() is equivalent to floor() and the value wasn’t always
higher.
The casts to u32* are technically undefined behavior. The u8* cast is
left, as char/unsigned char is exempted from this rule to allow for
bvtewise inspection of objects (and this is what s8/u8 are typedefs of
on platforms we support).
Writing to 0x60 does actually not "init exception[s]" or anything like
that. Not at all. Rather, it *breaks* a check in Nintendo's SDK, which
makes it fail to realise that the hook hasn't been set up.
This prevents the SDK initialisation routines from writing the rest of
the hook instructions (total: 0x20 bytes), which in turn causes an
anti-piracy check to fail in some Ubisoft games (including Tintin).
Dolphin can be really amazing sometimes.
No clue where people got the 0 value from, or why it's labelled as
"time". As far as I can tell, it is always set to 0xffffffff by
official NAND titles, including the system menu.
It's not specific to WADs. The BS2 emulation boot code will also need
to update the state file.
Move the struct to Boot and add a helper function that will handle
reading + computing the checksum + writing the state file.
Sentret_C posted this comment on Transifex recently:
"What Dolphin refers to as "Table View" and "List View" are
similar to "List View" and "Grid View" in Steam, and I think
the Steam names describe them better."
I agree with that, so here's a commit that changes the names.
This is supposed to get efb2tex to the same texture as efb2ram, by applying the related efb copies as updates after each other, in the order of their creation.
Improve bookkeeping around formats. Hopefully make code less confusing.
- Rename TlutFormat -> TLUTFormat to follow conventions.
- Use enum classes to prevent using a Texture format where an EFB Copy format
is expected or vice-versa.
- Use common EFBCopyFormat names regardless of depth and YUV configurations.
This way it allows us to use surfaceless contexts in EGL/GLX. It also
ensures that the shared context shares a similar setup to the main
context's framebuffer, potentially reducing the number of variants a
driver needs to generate.
Previously we were falling back to an earlier version of the compiler.
The older version cannot compile our ubershaders without various
graphical issues.
When recording during netplay, the stop message was only sent after you
have chosen a filename for the replay, causing the other player(s)
to freeze for a few seconds. This takes care of the annoyance.
There were two problems with this:
1. If the starting offset was beyond the end of the disc,
we would dereference an invalid iterator.
2. The data beyond the end of the disc was non-deterministic.
Having DiscContents with size 0 would mean that some DiscContents
might not get added to the std::set because of them comparing
identically to another DiscContent.
This replaces an older piece of code in WriteDirectory that ensures
that no two files have the same starting offset. (We now care about
the ending offset, not the starting offset. The new solution both
ensures that no two files have the same ending offset and that no
two files have the same starting offset.)
For instance, we don't want to show TGC files that might be
inside the /files/ directory of a GameCube DirectoryBlob,
and we don't want to show the /sys/main.dol files for extra
partitions of Wii DirectoryBlobs.
Now it's clearer that SetDOL depends on SetApploader
and BuildFST depends on SetDOL.
As a side note, we now load the DOL even if there's
no apploader. (I don't think it matters whether we
do it, but it was easier to implement this way.)
This lets VolumeDirectory/DirectoryBlob skip implementing
various volume functions like GetGameID, GetBanner, etc.
It also lets us view extracted discs in the game list.
This ends up breaking the boot process for Wii
DirectoryBlobs due to workarounds being removed from the
boot process, but that will be fixed later by adding
proper DirectoryBlob support for things like TMDs.
We now expect the directories to be laid out in a certain
format (based on the format that WIT uses) instead of requiring
the user to set the DVD root and apploader path settings.
This is useful for blob types that store Wii data unencrypted
(such as WIA and discs extracted to directories) so that
we don't have to waste CPU time encrypting in the blob code
just to decrypt right afterwards in the volume code.
The old approach to detecting DOL/ELF files doesn't fit
with the new way of implementing extracted discs.
The game list is already doing it in a way that's similar
to the approach that this commit uses.
The Config::AddLoadLayer functions call Load on the layer
explicitly, but Load is already called in the constructor,
so they'd cause the loader's Load function to be called twice,
which is potentially expensive considering we have to read an INI
from the host filesystem.
This commit removes the Config::AddLoadLayer functions because
they don't appear to be necessary.
This was mainly included for debugging, but could end up being confusing
for users, as well as polluting the GL program cache with a mix of uber
and specialized shaders if the option was changed.
On Windows, File::GetTempFilenameForAtomicWrite returns a path
somewhere in C:\Users\XXX\AppData\Local\Temp\{UUID here}\
in which all writes just fail.
Just use the SYSCONF path + ".tmp" for the temporary file name.
These vertex formats enable all attributes. Inactive attributes are set
to offset=0, and the smallest type possible. This "optimization" stops
the NV compiler from generating variants of vertex shaders.
This add support for SD protocol 2 while staying compatible with protocol 1.01.
Most of this is quite hacky, but it seems to be working well.
The original implementation was quite confusing, so I didn't touch most of the stuff I did not understand.
This makes the EGL interface select OpenGL|ES contexts over "desktop"
OpenGL ones.
Possibly not useful for anyone outside my own debugging, but you never
know
It's not particularily useful to list the platform here,
and these kinds of messages that use words as parameters
are more likely to be mistranslated than the average string.
Same as the previous commit, except I'm copying strings
in the other direction because the DolphinWX variants
of these strings could use some improvement.
The spec says it should have an EXT not OES suffix, as it's enabled as
an interaction with GL_EXT_multi_draw_arrays.
On some drivers GetProcAddress() returns NULL, which causes the
GLExtensions init to fail
This 'happened' to work if GetProcAddress() doesn't return NULL on missing
functions (as allowed in EGL) - as the function appears to never be called so
this would not have been noticed.
Mesa also (incorrectly?) exports the EXT version, so this would all
happen to work there, but appears to be contrary to the spec.
This invalid prefix even ended up in the upstream khronos registry, the
issue was reported here:
https://github.com/KhronosGroup/OpenGL-Registry/issues/81
The section is 0x461 bytes long, not 0x460. The config data is also now
initialised to zero to avoid garbage being written to the SYSCONF.
Because our handling has been wrong forever, we discard older BT.DINF
section backups as using them would result in the section being the
wrong size / incomplete again.
It turns out that the last byte of array entries isn't unused (as we
thought); instead, it looks like it's actually part of the main data,
and the length stored next to the name is in fact the length minus one.
Getting it wrong and always storing a null byte in there won't affect
most entries (since the last byte is zeroed most of the time), except:
- IPL.NIK: the length is stored in the last byte, and it must be kept.
- BT.DINF: u8 unknown[0x45] should be another Bluetooth device entry.
- Possibly other unknown affected entries.
I don't know who thought it would be a good idea to put the Wiimote
connect code as part of the Host interface, and have that called
from both the UI code and the core. And then hack around it by having
"force connect" events whenever Host_ConnectWiimote is called
from the core...
BluetoothEmu had its own bdaddr_t type which is a old style C struct
and typedef, which makes comparisons and copies a bit ugly.
On the other hand, BTReal had its own btaddr_t type using std::array.
To make things very slightly nicer, this commit changes the Bluetooth
code to use a single type (std::array<u8, 6>) for all BT addresses.
Imports/exports don't always use the title key. Exporting a title and
importing it back uses the PRNG key (aka backup key handle or key #5),
not the title key (at all).
To make things even more fun, some versions of IOS have a bug that
causes it to use a zeroed key instead of the PRNG key. When Nintendo
decided to fix it, they added checks to keep using the zeroed key only
in affected titles to avoid making existing exports useless.
(Thanks to tueidj for drawing my attention to this.
I missed this edge case during the initial implementation.)
This commit implements these checks so we are using the correct key
in all of these cases.
We now also use IOSC for decryption/encryption since built-in key
handles are used. And we now reject any invalid common key index,
just like ES.
Core::PauseAndLock requires all calls to it to be balanced, like this:
const bool was_unpaused = Core::PauseAndLock(true);
// do stuff on the CPU thread
Core::PauseAndLock(false, was_unpaused);
Aside from being a bit cumbersome, it turns out all callers really
don't need to know about was_unpaused at all. They just need to do
something on the CPU thread safely, including locking/unlocking.
So this commit replaces Core::PauseAndLock with a function that
makes both the purpose and the scope of what is being run on the
CPU thread visually clear. This makes it harder to accidentally run
something on the wrong thread, or forget the second call to
PauseAndLock to unpause, or forget that it needs to be passed
was_unpaused at the end.
We also don't need comments to indicate code X is being run on the
CPU thread anymore, as the function name makes it obvious.
The region mismatch check that we used can give false positives.
Skipping the check won't lead to any harm - games will ignore
save files that have a non-matching fourth game ID character.
According to http://scanlines16.com/en/blog-3/retro-gaming/game-cube/gamecube-korean-master-list/,
Korean GC releases use the following country codes:
- E or W for games in English
- K for games in Korean
- Unknown value for games in Japanese (my guess is that they might
have made the discs bit-for-bit identical to Japanese releases
because the regions of these games are already set to NTSC-J)
As far as I know, the GC has no Taiwanese releases, which is what
the W country code is used for on the Wii. But I could be wrong.
A small note: The country_byte == 'K' check in the code isn't
actually necessary as long as RegionSwitchGC returns NTSC_J
for 'K', but I thought it would be better to not rely on that.
The county code isn't 100% reliable for detecting the region.
For instance, some games released in Korea have the country
code E even though they're region-locked to NTSC-J consoles.
This commit makes the GC disc region detection match the Wii
disc region detection (apart from the region value being in
a different place on the disc).
Showing the Wii remote connection status leads to inconsistent UX,
because we don't do anything like that for GameCube controllers
or with Bluetooth passthrough.
It's also questionable how useful it is given that:
* it doesn't print the number of connected remotes, just that one
remote is connected, connecting or not connected, so the only info
it provides is actually wrong when using multiple remotes;
* this user-facing feature is actually broken in master and no one has
complained AFAIK, which means people don't really rely on it;
* the status bar isn't visible most of the time unless the user is
using render to main or deliberately keeping the main window's
status bar visible by moving the render window and they're not too
far away from their screen;
* emulated Wii remotes now reconnect on input, which means that there
is less of a need to actually know at all times whether a remote
is connected, since pressing any button will reconnect it and provide
immediate, visible feedback via OSD messages and the Wii remote
pointer appearing.
Rather than returning 0 / not creating an expected SI interrupt. You can
test this by running VBA-M in a debugger and stopping it while it's
connected to Dolphin: on current master, Dolphin will freeze-up until it
gets a response. With this PR, Dolphin will gracefully disconnect the device, and reconnect if it starts responding again.
Tracking a buffer's size manually and storing it under a name that
does not make it obvious it is related to the buffer is really... meh.
Also gets rid of the need to manually manage its capacity and
new/delete an array.
This commit merges the import and export contexts into a single context
because this is what IOS does, which means we can only reproduce its
behaviour correctly if we use a single context for both operations.
The other reason is that having two separate and very similar structs
is not really a good idea.
While working on this commit, I was notified that our handling of
ImportTmd/ExportTitleInit is not correct. In particular, we always use
the title key for both importing and exporting, which is wrong. To make
this easier to fix in a follow-up PR, the context now also has a title
key field, just like ES. This also lets us avoid computing it every
single time in ImportContentDone.
Allows them to be reused easily. Still a bit too much duplicated code
in my opinion (OpenContent/SeekContent/ReadContent should just call
FS code), but this is a start.
I think I do not need to explain why hardcoding space usage for two
random directories when we can calculate it and when IOS doesn't
actually do that is wrong.
There are some cases where overriding the opening.bnr names
isn't desirable, such as when someone has several modded
versions of a game that differ in names but not game IDs.
This was causing Dolphin to always save "WriteToWindow = False". Instead
of disabling logging to the window (a config value), tell LogManager
that there's no window to log to (a runtime state).
This is a remake of https://github.com/dolphin-emu/dolphin/pull/3749
Full credit goes to phire.
Old message:
"If none of the texture registers have changed and TMEM hasn't been invalidated or changed in other ways, we can blindly reuse the old texture cache entries without rehashing.
Not only does this fix the bloom effect in Spyro: A Hero's Tail (The game abused texture cache) but it will also provide speedups for other games which use the same texture over multiple draw calls, especially when safe texture cache is in use."
Changed the pr per phire's instructions to only return the current texture(s) if none of the texture registers were changed. If any texture register was changed, fall back to the default hashing and rebuilding textures from memory.
The actual problem was combining the values from the date and time
pickers incorrectly. The uninteresting parts of the returned wxDateTime
need to be ignored and the WX documentation says so for the time picker.
I also cleaned up the handling of both widgets a bit, removing redundant
member variables in the process, in order to not risk correctness.
It's a bit confusing to get a yes/no dialogue box without any indication
of what yes or no will do in this situation, so add a short explanatory
sentence.
Only remaining issue is that clicking on the titlebar of the window, to give it focus, is already interpreted as input. But clicking on the window in the task bar, or using alt tab works to get back, without causing an input event.
Changes:
- `ShowDevelopmentWarning` is now under the '[Interface]' group in
Dolphin.ini, with other interface-related settings. So, whoever uses
DolphinQt will have to edit that manually again. Sorry!
- Game search paths and the last file are now shared properly with
DolphinWX
- Qt-only preferences like "Preferred View: list/table" are now
stored using the platform's native settings storage, rather than in
UI.ini
struct GekkoOPTemplate was implemented differently in different
compilation units, which breaks the ODR and could end up causing issues
as symbols exported from one compilation unit could end up being used by
another even if they have different implementations.
This puts them in an anonymous namespace, restricting any generated
symbols to the single compilation unit.
Some code was calling more than one of these functions in a row
(in particular, FileUtil.cpp itself did it a lot...), which is
a waste since it's possible to call stat a single time and then
read all three values from the stat struct. This commit adds a
File::FileInfo class that calls stat once on construction and
then lets Exists/IsDirectory/GetSize be executed very quickly.
The performance improvement mostly matters for functions that
can be handling a lot of files, such as File::ScanDirectoryTree.
I've also done some cleanup in code that uses these functions.
For instance, some code had checks like !Exists() || !IsDirectory(),
which is functionally equivalent to !IsDirectory(), and some
code was using File::GetSize even though there was an IOFile
object that the code could call GetSize on.
The MonoSpaceFont of the LogWindow was using a Windows native way to
specify a font name.
Now it's using wxFONTFAMILY_TELETYPE.
On Win32 it will additionally request the specific font name "Consolas",
so it doesn't use ugly "Courier New". I pilfered that specialization
from Source/Core/DolphinWX/Cheats/ARCodeAddEdit.cpp.
Before, if you extracted a directory like /map/Final/Release/,
Dolphin would create the nested folders map, Final and Release
in the output directory and put the files in Release instead of
just putting the files directly in the output directory.
While setting up a proper NAND for Wii emulation has become much easier
now that disc and online system updates work, they still require users
to have a recent disc game, certificates extracted from IOS or a NAND
dump for online updates to work and to really get all system titles.
This commit adds the ability to do an online update right from
Dolphin itself, which solves that usability issue.
Allows reusing the WAD import logic more easily, whereas UICommon
code can only be used from UICommon and UI.
And managing what's on the NAND is the Core's responsability, not UI.
It didn't work when there were non-ASCII characters
in the directories argument, but it worked fine with
non-ASCII characters in names of found files and folders.
* IOS: WiiRoot shutdown was moved to HW.
* Movie: Don't call UpdateWantDeterminism() if we're not running yet,
because this will automatically be done during the boot process.
Not doing this will result in two NANDs being created.
This is larger than I thought I would be, but unfortunately it's quite
hard to split fixes like this when the handling is wrong in tons of
different places.
The content table is limited in size. It can only hold 16 entries.
Three consequences:
* Since the table cannot grow indefinitely, instead of using a std::map
we use a std::array as we should.
* Remove a hack where the CFD was cleared back to 0 on IPC close (wtf?)
* The CFD now doesn't keep increasing to infinity. It's unknown if this
would fix anything at all, but some issues in the past were caused
by CFDs being excessively large.
Other minor changes:
* Simplify save state logic.
* Keep track of the UID like ES does. Not sure how useful this is, but
we can do this very easily so why not.
* Remove the guesswork and use the actual error codes.
* Add more error checking to make Dolphin less likely to crash.
Something that should be done in the future: deduplicate the filesystem
logic. Something that takes one line in the actual ES code takes
10+ lines in our implementation... while duplicating the FS logic...
This will likely harder to fix though, so I'm leaving that
for another time.
It seems to make no difference besides allowing lower latencies and more
stability on hardware OpenAL cards. Maybe the Wait() call waits for too
long, causing buffers underruns.
Before these changes each value of latency were actually 5ms, with a
minimum latency of ~10 ms. If it was set to 4 ms on the UI, the actual
latency was 10 + 5 * 4 = 30 ms.
Now 30 ms on the UI means 30 ms on the backend.
Tillmann Karras