called.
The user will get a brief system popup tutorial the first time it's
used, so we don't need to show them the menu every time. Once they
enable it by pulling down, hide again after 3s.
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
Move the parameter extraction earlier on in onCreate. Mostly this moves
setting sIsGameCubeGame to before setContentView, which means
EmulationFragment will always see it in a consistent state. Previously,
there was a race, which mean the controller overlay would randomly be
Wii controls for a GameCube game (since the default is false).
Use the correct support version of things, ActivityOptionsCompat and
transitions
Rename static var mIsGameCubeGame to sIsGameCubeGame. s is static, m is
member.
Make the MenuFragment added and removed by fragment transactions only,
instead of being initially present in the XML. This fixes a glitch where
it doesn't animate correctly the first time it's used.
The Activity is responsible for just its views and menus and such. It
signals the Fragment via setGamePath, StartEmulation and StopEmulation.
The Fragment manages the actual emulation lifecycle. It is solely
responsible for calling the NativeLibrary lifecycle methods.
With this lifecycle simplification, the NativeLibrary no longer needs to
kill the Activity. It happens normally now.
This simplifies a lot of things, live handling rotation.
Without this View, the emulation SurfaceView acts like it has the
highest Z-value, blocking any other View. This includes the menu
fragments and the screenshot ImageView.
This makes it clear that the Activity is being cleared and removes null as
a valid param. This improves readability (and logging slightly).
Fix spacing between [Tag] and message. This matches the rest of the log
messages.
In the support lib, the code comes from the SDK, not the device like the
framework version. This means we're shipping a more recent and less buggy
version.
It's also a good idea to keep the entire project on one version. We have a bit
of a mix now. I think some of the Fragment animation issues were because of
this mixing.
For the leanback activities, AppCompatActivity requires AppCompat themes, which
they don't ship for Theme.Leanback. So use FragmentActivity instead (that's the
parent of AppCompatActivity, but still in the support library). For passed
around Activities, use FragmentActivity to work with both.
Bump the support lib version to 26. This allows for using property
animators (R.animator) in FragmentTransaction.setCustomAnimations.
Add the google maven repo, as from support lib 26 onwards, they're only
publishing it in there.
Bump the gradle version while we're at it, keep Android Studio quiet.
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
Other than what action they send back to
EmulationActivity.handleMenuAction(), they are the same.
Change the menu-handling logic in EmulationActivity to keep track of a
boolean for whether the submenu is visible, rather than keeping the
fragment tag. There's only one fragment visible, so this makes more
sense.
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.
Some toolchains provide enough of C++17 to conflict with Dolphin's
included backport of std::variant and std::optional. Specifically,
the recently-released macOS 10.13 SDK does not provide the <optional>
or <variant> headers, but does provide `in_place_t` in the <utility>
header.
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*.
Prefixing everything with a constant packagename is not needed for
internal keys, and just adds complexity.
Rename ARGUMENT_ prefix to ARG_ to match (most) of the rest of the
codebase.
Restrict visiblity of above as much as possible.
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.
FRAGMENT_ID wasn't actually the fragment's ID (that's misleading, and
sounds like the tag). It's actually the layout resource ID. There's no point in making that a static constant.
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.
This adds a test ucode that can be used to check the accelerator loop
behaviour with various start/end addresses.
It's actually more of a test template than a ready to use test.
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.
Mike