At first there weren't many enums in Volume.h, but the number has been
growing, and I'm planning to add one more for regions. To not make
Volume.h too large, and to avoid needing to include Volume.h in code
that doesn't use volume objects, I'm moving the enums to a new file.
I'm also turning them into enum classes while I'm at it.
Fully opt-in, reports to analytics.dolphin-emu.org over SSL. Collects system
information and settings at Dolphin start time and game start time.
UI not implemented yet, so users are required to opt in through config editing.
Since all Virtual console releases use the same emulator (though there
are multiple revisions some emulators) and generally need the same
setting, this commit allows the creation of INI files which cover all
Virtual Console games fow each system.
For example, F.ini can provide settings that all NES games have in common
and C.ini will provide settings for all Commadore 64 games.
If needed, a 3 letter ini can override settings for individual games.
Dolphin has supported the recalibration shortcut (X+Y+Start) for quite a long while. So if someont's axises are terrible, you could easily
recalibrate.
Games even get the initial calibration upon boot(Most of the time).
While changing over the GCAdapter code, I was testing to make sure the reset and calibration shortcuts still worked, turns out they didn't work at
all.
Looking in to the problem, we capture the combination properly, and we wait three seconds until we actually fire that off recalibration.
The problem is for Nintendo's SDK to properly handle recalibrating, we need to send back data saying that it needs to recalibrate.
On hardware this is done as part of the 64bits of data the controller sends back to us.
On holding of the controller, bit 61 of the return value is set, which the Nintendo SDK catches, and then signals immediately afterwards a CMD_ORIGIN
command in order to recalibrate the controller.
We were outright ignoring this bit, so the library wasn't ever recalibrating. I suspect in the past the class itself used to use the calibration data
to to offset the data, but somewhere along the lines it got munged out of existence.
The Gamecube adapter does this shortcut in a bit of a unique way, instead of sending the command and having the library support it and what have you.
Once holding the shortcut for the amount of time, the adapter reports back that the controller has actually been disconnected. Then when you let go of
the combination, the adapter states that a new device has been connected to that port, and the recalibration happens because a new device is
"connected."
This fixes controller calibration for both emulated GC controllers and also the Wii Gamecube Adapter.
We don't throttle by frames, we throttle by coretiming speed.
So looking up VI for calculating the speed was just very wrong.
The new ini option is a float, 1.0f for fullspeed.
In the GUI, percentual values are used.
The Wii U Gamecube controller adapter setup has always been a bit weird. It tries to be as automatic as possible to make the user experience as easy
as possible.
The problem with this approach is that it brings a large disconnect in the user experience because you have the Gamecube controller setup with regular
gamepads and then for some reason below that you have a "direct connect" option which will cause the Gamecube Adapter to overwrite the regular inputs
if something was connected.
While this works and allows the user to only click one checkbox to get the device working, it breaks the user's experience because they don't really
know what "direct connect" means and won't look it up to figure out what it is. Just expecting the device to work (At least one occurence of this in
the IRC channel in the last week).
This way around also had the terrible nature of making the code more filthy than it needed to be. The GCAdapter namespace was parasitic and hooked in
to the regular GC Controller SI class to overwrite the data that it was getting from the default configuration.
Now instead we have a specific SIDevice class for the Wii U Gamecube adapter. This class is fairly simple and is a child of the regular SI Gamecube
Pad device and only reimplements what it needs to.
This also gives the ability to configure controllers individually, which allows the user to configure rumble individually per pad input.
Overall the code is cleaner, and it fits more in line with how the rest of Dolphin works.
It's used by both the GUI to do things like install WADs and check up on
the system menu, in which case the global root should be used, and by
/dev/es, in which case the local one should. The latter isn't
*terribly* useful today, since no contents will ever be installed in
temporary roots (although it's still relevant for data directories), but
converting the whole thing makes sense because then it will Just Work
once the entire NAND is synced.
Because it would have been a bit of work to split it up (but I can if
desired), this commit also contains some basic cleanup of
NANDContentLoader:
(1) The useless interface class INANDContentLoader is removed and the
methods are changed to just return CNANDContentLoader (the only
implementation);
(2) CNANDContentManager is changed to use unique_ptr and cleaned up a
bit.
This is a bit indirect, but since homebrew always boots in a European environment the framerate depends on the bPAL60 flag, which is always auto turned off if bNTSC is set to true as of 2e5e724f94. By actually indicating that we're PAL on homebrew boot, the rest just falls into place.
The new implementation has 3 options:
SyncGpuMaxDistance
SyncGpuMinDistance
SyncGpuOverclock
The MaxDistance controlls how many CPU cycles the CPU is allowed to be in front
of the GPU. Too low values will slow down extremly, too high values are as
unsynchronized and half of the games will crash.
The -MinDistance (negative) set how many cycles the GPU is allowed to be in
front of the CPU. As we are used to emulate an infinitiv fast GPU, this may be
set to any high (negative) number.
The last parameter is to hack a faster (>1.0) or slower(<1.0) GPU. As we don't
emulate GPU timing very well (eg skip the timings of the pixel stage completely),
an overclock factor of ~0.5 is often much more accurate than 1.0
Eventually, netplay will be able to use the host's NAND, but this could
still be useful in some cases; for TAS it definitely makes sense to have
a way to avoid using any preexisting NAND.
In terms of implementation: remove D_WIIUSER_IDX, which was just WIIROOT
+ "/", as well as some other indices which are pointless to have as
separate variables rather than just using the actual path (fixed, since
they're actual Wii NAND paths) at the call site. Then split off
D_SESSION_WIIROOT_IDX, which can point to the dummy NAND directory, from
D_WIIROOT_IDX, which always points to the "real" one the user
configured.
This is available with the `GDBSocket` option in
`~/.dolphin-emu/Config/Dolphin.ini`.
GDB can connect to it with:
$ powerpc-eabi-gdb
(gdb) target remote |socat STDIO UNIX:foo.sock
Because I don't like so much binding the GDB stub socket to 0.0.0.0.
On Linux, with a suitable umask, we can make sure that another local
user cannot connect to the socket.
I'm not sure if Maker is the best name (Developer? Publisher?
Company? Copyright?) but I went with it because it's
what the game properties window uses. For the sake of
backwards compatibility, the INI option wasn't renamed.
