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.
This has no effect now, as we've never bumped the database version.
Instead, it adds future proofing, and makes moving between a future
version with a bump and master clean.
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.)
Now that all inputs are corrected to zero-centered, we can use getFlat()
to ignore movements that are just noise.
This eliminates a lot of drift when the controller is at rest, notably
on the character select screen in Melee.
Android reports the same physical axis multiple times for analog
triggers, and this handles this case.
There are also some controllers with broken mappings (eg the analog
triggers on a PS4 DualShock 4). These axis don't center correctly.
There are also some controllers (again, the PS4) that send both a button
press and an axis movement. This ignores the buttons so we can use the
analog axis. Otherwise, since the button comes before the axis moves
far we would always take the button.
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.
Emulation needs to be running when the surface is destroyed, but we want
to pause in onStop. So call the surfaceDestroyed callback, as this
accomplished both.
The source Views don't need the transition name. We could get the name
from the sharedView via getTransitionName, but since the TV
ImageCardView isn't inflated in XML it would be to be manually set.
I'm not sure if that would be any cleaner than this.
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.
JosJuice