Offtopic comments not related to testing or reviews / technical questions will be moderated

The second pr based off of @phire 's original Hybrid XFB #3880 . Leverages the AbstractTexture ( #5305 ) to treat the xfb as a texture.

What this PR does: It allows you to play games that require "RealXFB" with higher internal resolution (the actual xfb will still be native resolution)

What's done:

• Initial hybrid xfb support for Vulkan, D3D, Opengl, Software
• Make texture cache always use safe hashing for XFB copies.
• Initial Screenshot / Video dumping for D3D, Vulkan, Opengl, Software through VideoCommon
• GUI Options
• Update fifoplayer to support XFB
• Vertical scaling for PAL games
  • XFB to RAM copies need to apply the scale
  • XFB to Tex copies need to store, but not apply the scale.
  • Partial texture updates need to apply any store scaling before display.
• Remove lots of unnecessary code!
• GPU texture decoding works for XFBs
• Option for 'Immediate mode' XFB which can provide better latency at the cost of graphical errors (usable on both XFB2Tex or XFB2Ram)
• Somehow allow Swap to detect when the XFB hasn't changed since last frame
• Update game inis
  • All games previously requiring real xfb or virtual xfb, now have immediate mode defaulting to off
  • Games that show partial/incomplete frames sets immediate mode to off
  • Added a couple of new inis that also have these restrictions
• Strided XFB copies fully supported
  • Fixes "Sonic 3d Blast"
  • Fixes "Zelda Collector's Edition"

What's left:

• Nothing!

Future Enhancements:

• Find a new sane home for the "End of frame" stuff.
• Fix "Super Mario Strikers" (loading screen backgrounds do not show up with XFB2Tex)
• Screenshots do not account for post-processing
• Partial XFB support for games like Mario Strikers or Chicken Little
  • The proper solution likely is either leverage locking so users can use XFB2Ram without a perf hit or to treat hash changes as overwrites. This means we'd upscale the 1x res xfb in memory and combine it with the texture cache xfb, treating a key color (fuchsia) as alpha

It seems MoltenVK is now mature enough to handle the shaders Dolphin generates without completely falling over. It will be interesting to see how it performs compared to OpenGL, but more importantly, it enables mac users to use features blocked by the GL version, e.g. bounding box.

We'll also have to decide how to distribute MoltenVK. Currently, the loader searches for an environment variable named LIBMOLTENVK_PATH, and if present uses that. Otherwise, it looks in the application bundle directory, under DolphinWx.app/Contents/Frameworks/libMoltenVK.dylib.

I'd suggest building MoltenVK externally, and copying the library in as a buildbot step. IMO, this is better than including yet another huge externals dependency, for a single platform.

Known limitations:

• In single core mode, enabling multithreading in graphics options can lead to lower performance. In dual core mode, it seems similar. Probably best to disable it though, due to MoltenVK doing its own threading internally.
• Ubershaders cause the shader compiler to freak out. I haven't looked into whether this is a SPIRV-Cross (via MoltenVK) issue, or we need to update our glslang.

The CemuHook controller input protocol

This was done by implementing the protocol for controller input used by CemuHook in a new controller interface class (CemuHookUDPServer). The protocol is used for transmitting controller input (including motion input) to Dolphin from specific server applications written to support specific controller types. For example, the Sony Dualshock 4 is supported through the DS4Windows application. This is the only configuration I have tested. See this page on the CemuHook site for more information and instructions on testing motion input before trying to use it with Dolphin.

Server configuration

First make sure you have tested your controller's motion input like in the link above. Then run and quit Dolphin once to create the settings file UDPServer.ini in the Dolphin config folder. In the settings file change Enabled = False to Enabled = True. Default values for the other settings (IPAddress and Port) may need changing depending on the server application used. With DS4Windows you just need to enable the UDP Server in DS4Windows' settings.

Emulated Wii Remote configuration

In the GUI for configuring an Emulated Wii Remote, a new tab called Motion Input was added. The old Motion Controls tab was renamed to Motion Simulation to differentiate them. In the Device dropdown list select a UDPServer device for motion input support. Point settings are described below. Accelerometer and Gyro settings should be left alone.

Pointer emulation

The Wiimote camera sensor (pointer) is emulated from motion input. There are however some inaccuracies in motion sensors making the pointer slowly drift horizontally. To help this, there are two options in the Point box on the Motion Input tab. One is Recenter, which lets you recenter the pointer on the screen with a button press. The other is Total Yaw, which horizontally limits the pointer movement like when a computer mouse pointer hits the screen edge. Try out both options to see which works best in which games. I have playtested very little, but for Skyward Sword it seems best to disable Total Yaw by setting it to 360 and mapping Recenter to Pad S just like the ingame recenter function. Then, when you need to recenter, point the controller in the direction of the screen center and tap Pad S twice without moving the controller.

Funny story

Initially I had troubles getting any motion input to work. Among several things I tried Wii Sports Tennis to see if I could get any reaction from the motion input. I first tried a few forehands and backhads to get the guy to serve. Then I remembered how the pros do it and took a proper swing from behind my head. The brand new DS4 controller I used first hit a ceiling lamp, knocking the controller out of my hand. The controller then, to my horror, flew towards my four months old 1100$ TV, just missing to its left and also just above a computer monitor stored temporarily on the floor. The controller hit the wall behind the computer monitor with a loud crack, prompting people on the above floor come asking what the hell was going on. Incredibly, the ceiling lamp, both displays, the controller and the wall survived with just a few scratches.

Fixes Texture lookup by applying point sampling.

Old: This adds an epsilon in the texture sampling stage to prevent rounding errors.

An epsilon of 0.5 gave the same results (when it comes to artifacts)as point sampling without actually point sampling so there is no behavioral change. 0.5 was chosen as that is the lowest value that can always be represented when converting a 24bit signed integer to a float. The only fifolog that this doesn't fix is Just Dance 2 but the same artifacts can be found when point sampling and this depends on the hardware, so this is probably a rounding error(https://github.com/dolphin-emu/dolphin/pull/9473#issuecomment-768564342, https://github.com/dolphin-emu/dolphin/pull/9473#issuecomment-767937443). But Just Dance 2 is improved compared to master, at least on my hardware (Nvidia).

OLD: This solution was provided by u/fortsnek47 on reddit (https://www.reddit.com/r/EmuDev/comments/l0y7sg/gc_fixing_those_vp6_videos/). I don't have any games with texture lookup issues so I can't test these changes.

Games that can be tested: https://wiki.dolphin-emu.org/index.php?title=Template:Problems/VP6_Videos

This pull request adds support for compiling Dolphin for ARM on MacOS so that it can run natively on the M1 processors without running through Rosseta2 emulation providing a 30-50% performance speedup and less hitches from Rosseta2.

It consists of several key changes:

• Adding support for W^X allocation(MAP_JIT) for the ARM JIT
• Adding the machine context and config info to identify the M1 processor
• Additions to the build system and docs to support building universal binaries
• Adding code signing entitlements to access the MAP_JIT functionality
• Updating the MoltenVK libvulkan.dylib to a newer version with M1 support

Thanks everyone on IRC for the help in making this change!

This thread will be strictly moderated, any off-topic or pointless comments will be deleted.

• Not going to implement XFB, waiting on TextureCache-based XFB first.
• Same with screenshot/frame dumping
• You can probably play games now.
• Performance in my brief testing is slightly above OpenGL on nVidia
• AMD seems roughly ~25% faster compared to OpenGL in some scenarios (apart from needing the dualsrc blend fallback)
• Can't really test on Intel, my most recent iGPU is a Haswell and Vulkan support is buggy

Rough overall todo:

• [x] Basic framework
• [x] Ability to draw stuff
• [x] Texture/vertex uploading
• [x] Update to new source styling
• [x] Sort out shader compiler
• [x] Having games render a decent amount of stuff
• [x] Not crash regularly (somewhat improved)
• [x] EFB to texture
• [x] EFB to ram
• [x] EFB format changes
• [x] GPU texture conversion
• [x] CPU EFB access
• [x] Bounding box
• [x] Perf queries
• [x] MSAA support
• [x] Stereoscopy support
• [x] Anisotropic filtering support
• [x] Logic ops for blending
• [x] Vsync
• [x] Texture dumping
• [x] Support for mobile/android
• [x] Support for drivers without coherent buffer mapping (needed?)
• [x] Support for drivers without dual source blending (looking at you, Adreno)
• [x] Pipeline state caching

Now feature-complete, time for clean-ups/bug-fixing/performance work.

This change is

Super Mario Galaxy renders fog and various other effects like lava and water by tinting higher mipmap levels. This is a neat trick and all, but it means that by letting the host GPU handle mipmaps at resolutions higher than the wii could output (and especially by activating anisotropic filtering), the effect breaks down because the mipmaps get pushed much farther down from the camera than originally intended. In fact they almost disappear!

Before (6x IR):

Note how the background star, lava and the reflections in the Starbits ice things are broken.

With the hack enabled (still 6x IR):

So to fix this I did a bunch of things:

• Added a checkbox in Graphics/Hacks. I added it as an Hack because the downside of this fix is that with this enabled lower LODs show unnecessarily closer! In any game that doesn't use LOD tricks, this causes blurrier textures (although more accurate to the original!) This option is auto-disabled at 1x IR.
• When the option is on, instead of using the native texture read functions, all shaders (normal and uber) go through a texture_read function. texture_read selects the LOD level by hand so that it can scale the ddx/ddy by the IR scale and get an approximation of the original values on real consoles. This is not super precise, I guess, along borders (where the gradients change quickly) but overall it seems to work pretty well! Note that the new function is also slower, because it has to compute the levels by hand! I couldn't see any real slowdown when playing on my computer, though.
• When the option is on, it completely disables Anisotropic Filtering as well. Besides the fact that textureLod ignores it, Anisotropic is another effect that greatly pushes LODs out so you don't want to use it either.
• Enabled that option by default in Super Mario Galaxy 1 & 2, because I think it makes no sense to play them at higher IR with broken graphics. Most textures don't seem to have more than 1 mipmaps anyway, except the ones used this way. weird.
• Fixed a typo :D

Let me know what you think!

This adds the ability to passthrough a whole Bluetooth adapter and skip the majority of the Bluetooth emulation code. We use libusb to send HCI commands, receive HCI events and transfer ACL data directly to the first adapter that is found, or to a specific adapter (if configured to).

This is possible because the Wii's Bluetooth module is actually just a pretty standard Bluetooth adapter…

…except for two vendor-specific commands and one other HCI command (for which replies are faked), and also for the sync button. On the Wii, the sync button triggers an HCI event, which emulated software interpret as a command to perform a BT inquiry. We definitely need to emulate that, so this PR also adds a hotkey and a button to trigger the "sync button" event.

What works in this passthrough mode:

• Pairing and reconnecting Wiimotes on button press
• Letting the emulated software really disconnect Wiimotes
• Reconnecting Wiimotes after e.g. an ES_Launch (depending on the adapter)
• Wiimote audio with all Wiimotes, -TR or non -TR
• Third-party Wiimote support just like on the Wii, even on Windows
• Generally improved Wiimote input, especially with a Motion+

Limitations:

• It is difficult to connect more than 3 Wiimotes at the same time. A Wii Bluetooth module works perfectly, so this really depends on the quality of the adapter.
• Loading a state save breaks it completely, even if the state load is reverted. Not much I can do, since we're doing hardware passthrough.

This change is

If users want to test, use this link: https://dl.dolphin-emu.org/prs/pr-5702-dolphin-latest-x64.7z

This pull request completes the implemention of ubershaders in the graphics backends, started by @phire. Most of the hard work was done already by them, I just had to write the vertex ubershaders, integrate it into the backends, and fix bugs.

Last time I checked, ubershaders are fifoci regression-free on GL. Haven't tried D3D or Vulkan.

In the graphics options under the enhancements tab, there is a new drop-down field, "Ubershader mode". The options are:

• Disabled: "Classic" mode with normal shader generation. Stuttering will still exist, same as before. Recommended for low-end systems.
• Hybrid: Compiles specialized shaders asynchronously, while this occurs, ubershaders will be used. Best balance of performance and stuttering. This is not the same as the Ishiiruka async shaders! Game objects will continue to render as normal while shaders are being compiled. Not guaranteed to remove stuttering completely, as drivers often defer some work to the first time a program is used, and/or GL_LINK_STATUS is checked (cough NVIDIA), which we do on the main thread.
• Exclusive: Only use ubershaders for rendering. Largest performance hit. Don't expect to hit full speed at high resolutions, even on high-end systems. Least possible amount of compilation "stutter".

There's also a few hidden options, which you can modify via the ini:

• BackgroundShaderCompiling: Enables aforementioned "hybrid" mode.
• DisableSpecializedShaders: Enables aforementioned "exclusive" mode.
• PrecompileUberShaders: Precompiles all ubershader combinations at boot time. For drivers that support a shader cache, this will only take time on the first boot, subsequent boots should be very fast. You want to leave this enabled for the best experience, as the ubershader compile time is much longer than the specialized shader compile time.
• ShaderCompilerThreads: Sets the number of worker threads created for asynchronous shader compilation. Most drivers have some sort of lock involved in shader creation, so this will only scale up to a certain point. It defaults to 1, as this hopefully should be sufficient for background compiling in most cases, as well as not oversubscribing those with fewer CPU cores. This can be also be set to -1, which determines the number of threads based on system it is running, or 0, which disables asynchronous compilation.
• ForceVertexUberShaders: Replaces specialized vertex shaders with uber shaders. Only really useful for debugging issues in the uber shaders.
• ForcePixelUberShaders: Replaces specialized pixel shaders with uber shaders. Only really useful for debugging issues in the uber shaders.

Feel free to report bugs at this point. Please attach a fifolog where possible, and provide as much detail as you can, as this will allow me to get the issue fixed faster.

For the best experience depending on your operating system and GPU vendor:

• Intel on Windows
  • Use D3D for Exclusive or Hybrid modes.
  • Driver generates variants with OpenGL -> suttering.
  • The Vulkan driver only supports Skylake+, and is buggy anyway.
• Intel on Linux
  • Use Vulkan for Exclusive or Hybrid modes.
  • anv works quite well.
  • i965 doesn't share compiled code between contexts, which means the main context will always recompile and stutter.
• AMD on Windows
  • Use D3D for Hybrid mode.
  • Use D3D or Vulkan for Exclusive mode.
  • The AMD GL driver is just slow in general.
  • Vulkan doesn't work too badly, but the shader cache is ineffective, leading to long boot times.
• AMD on Linux
  • Use Vulkan for Exclusive or Hybrid modes.
  • I haven't tested radeonsi, but radv likely behaves similarly to anv. If radeonsi shares GPU code between contexts, GL may be an option.
• NVIDIA on Windows
  • Use D3D for Hybrid mode. GL isn't too bad with the latest changes, but may still have some stutter.
  • Use D3D or GL or Vulkan for Exclusive mode. D3D will get you the best performance.
• NVIDIA on Linux
  • Use GL for Hybrid mode.
  • Use GL or Vulkan for Exclusive mode. GL performs slightly better.

Few notes:

• There is a large performance hit when using ubershaders. This is most noticeable in the exclusive mode. In the hybrid mode, ubershaders likely aren't used for every object being rendered, meaning the overall performance hit will be lower. There's still room for optimizations, but these can come later.
• Per-pixel lighting is not currently compatible with ubershaders. If you enable per-pixel lighting, ubershaders won't be used, and you will still experience compilation stutter.
• The ubershader caches are shared between games, hence the dependency on PR #5679. The compile times can be pretty long, so it makes sense to share them where possible.
• D3D11 currently offers the best experience in regards to compilation stutter. The NV GL driver still generates variants behind our back, which sometimes creates a noticeable hitch.
• AMD's Vulkan driver is garbage and doesn't use a pipeline cache, so every variant is expensive to create. This means when we generate ubershader variants, it'll still stutter. Not much we can do about this, unless they implement derived pipelines, which we could potentially make use of. They also fail at arrays in shader input/output interfaces, forcing an ugly workaround.
• Progress dialogs for shader compilation at boot are implemented for D3D, and Vulkan only.
• OpenGL asynchronous compilation is currently done via the ARB_parallel_shader_compile extension, currently only implemented by NVIDIA. We may consider a multi-context approach in the future, but for other vendors, you may wish to use one of the other backends.

Improve netplay setup dialog UX

• Focus "Hash Code" / "IP address" text box by default in "Connect"
• Focus game list in "Host" tab
• RETURN keypress now host/join depending on selected tab
• Remember last hosted game

Join scenario:

• Copy netplay code
• Open netplay
• Paste code
• Press enter

Host scenario:

• Open netplay
• Go to host tab
• Press enter

Improve NetPlay UX

• Log ping to OSD under FPS
• Remove PanicAlertT:
  • Simply log message to netplay window
  • Remove them when they are useless
• Show some netplay message in OSD
  • Chat messages
  • Pad buffer changes
  • Desync alerts
• Stop the game consistently when another player disconnects / crashes
• Prettify chat textbox

OSD:

Chat box:

Implemented in this PR right now:

• All Riivolution features described on this page.
• Ability to launch Riivolution-patched games in DolphinQt.
  • Right-click a game in the game list and select 'Start with Riivolution Patches...'.
  • By default XMLs and files will be loaded by assuming the directory one up from the XML as a virtual SD card root. This can be changed in the patch launcher window.
  • The default root directory is {user dir}/Load/Riivolution/.
  • Launching via the GUI like this remembers the last selected patches in the same way actual Riivolution does.
• Ability to launch Riivolution-patched games in DolphinNoGUI.
  • Write a .json file like this and then point DolphinNoGUI at it.

Known desired features or issues that are (currently) not implemented in this PR:

• A generic patch GUI, where Dolphin lists all patches installed for a game and allows you to select, prioritize, and organize them, which stay persistent across game sessions.
  • This will not be in this PR, and will likely not exist for a while. From what I know, @iwubcode wants to implement this in the future.
• A way to launch Riivolution patches over Netplay or for TASing, and a way to have them show as extra entries in the game list for full game patches.
  • I'd like to do a follow-up PR for this that exposes the currently-CLI-only .json format in the GUI for this purpose.
• Conflict resolution. If multiple patches target the same file, the last patch wins -- this is consistent with Riivolution itself, but not great.
  • Either we defer this to the future generic patch GUI or we have to think of something here. I'd be fine with just leaving it as-is for now.
• The loading times are wrong due to the rebuilt FST.
  • I've worked around this by enabling the fast disc speed option for now when Riivolution patches are enabled, but if desired I can investigate making this actually accurate for this PR. Otherwise this will be a follow-up PR at some point in the future.

NOTE: Some of the specific details below may be a bit outdated, but the general gist still applies.

This implements the ability to parse and apply Riivolution XML files by rebuilding the game's FST before launch using DirectoryBlob.

A new subfolder in the user directory (Load/Riivolution) has been added to act as the virtual SD card root that Riivolution patches would normally search files in. Patch XMLs in Load/Riivolution/riivolution will also be parsed automatically when using this feature, mimicking how Riivolution loads XML files in (SD root)/riivolution.

To launch a game using this feature, right-click it in the game list and select Start with Riivolution... after placing the desired patch files in Load/Riivolution. Then select the patches you'd like to apply, and click Start.

So for example, to launch Newer Super Mario Bros. Wii you would do the following:

• Download the mod from its official website.
• Extract the NewerSMBW and riivolution folders into the Load/Riivolution directory. (example)
• Launch Dolphin, right-click your vanilla New Super Mario Bros. game in the game list, and select Start with Riivolution....
• For this patch the defaults are already correct, so just hit Start in the patch selection window. (example)
• And enjoy!

I'm open to suggestions for improving the user-experience, though I don't think the current way is terrible.

This is based on the Yuzu "Scheduler" which in turn is based on DXVKs command stream thread. If the Yuzu license is incompatible with the one in Dolphin, I'll change it to lean closer to the DXVK implementation which is licensed under zlib.

This PR moves most Vulkan calls and the StateTracker to a separate worker thread. This should yield a speedup of around 5-15% depending on the game.

Fixes https://forums.dolphin-emu.org/Thread-manual-texture-sampling-does-not-work-with-stereoscopic-3d.

Otherwise, texelFetch() will use an out-of-bounds layer for game textures (that have 1 layer; EFB copies have 2 layers in stereoscopic 3D mode), which is undefined behavior (often resulting in a black image). The fast texture sampling path uses texture(), which always clamps (see https://www.khronos.org/opengl/wiki/Array_Texture#Access_in_shaders), so it was unaffected by this difference.

(The description of this pull request touches on events from before I joined the Dolphin project. I believe my descriptions of how the code worked back then are more or less accurate, but I may be misstating things when it comes to the motivations behind the code!)

Next year, the Android port of Dolphin is going to hit an anniversary: 10 years since the start of its development. That long ago, there certainly weren't any phones that could run Dolphin fast, but the development of Dolphin's Android port never stopped (well, at least never fully), and by now it's become quite a capable emulator.

The person who laid the groundwork for the Android port all those years ago was Sonicadvance1. He's said that he enjoyed the time he spent adding an ARM JIT and OpenGL ES support, but tellingly, I can't remember him ever saying that he enjoyed working with Android.

Really, adding any major feature to Dolphin's Android GUI is not fun at all. Having to completely reimplement a GUI that we already have a fully working PC version of is a drag as it is, but what makes it much worse is JNI. Because Android's GUI libraries are written in Java and Dolphin is written in C++, you need some way to bridge the two languages. And the tool we have for that, JNI, really is a pain to use. My guess from reading the code left around from the early days of Dolphin's Android port is that Sonicadvance1 tried to avoid using JNI wherever possible, but still had to use it in some places because it was absolutely necessary.

This code from the early days worked, but in some cases, its avoidance of JNI led to features getting reimplemented in Java in subtly incompatible or buggy ways, more advanced features being hard to add, and other problems. The past few years, I've been going through Dolphin and removing reimplemented features in favor of calling existing C++ code where it would be beneficial. Yes, it meant I had to spend time writing lots of JNI code, but I think the result has been worth it. The game list, the settings... Those are both areas that improved a lot with the ability to call into our existing C++ code. (Remember when you couldn't change settings while a game was running?) But there's one area that I haven't touched until now because of how big and daunting it was: Input.

On PC, Dolphin has an incredibly sophisticated system for mapping inputs to emulated controllers. Because of how quirky Wii controllers are compared to normal gamepads, having a good system for this is almost a necessity. The Android version of Dolphin has until now been completely sidestepping this system. Let me try to explain what it has been doing instead.

Initially when Dolphin was being ported to Android, it only supported touchscreen input. Gamepad input didn't come until a bit later. For the initial touchscreen support, a slightly crude but perfectly functional approach was used: When you first launched Dolphin, an input mapping file would be created with pre-defined mappings that mapped the buttons and sticks of the emulated controller to "fake" inputs provided by the Android app. The app would then change the state of the "fake" inputs as you touched the virtual buttons and sticks on the touchscreen.

Why did there have to be a mapping file? Well, simply because Dolphin's existing C++ code expected there to be mappings. On PC, this file is where the user's choices for how to map their gamepad (or keyboard, or other input device) would be stored. But it's not like the code cares if the mappings were set up by the user or by an automated process, so the solution of pre-defined mappings worked fine.

Then it was time to add gamepad support, which required some way of storing the mappings set up by the user. Simply storing them in the mapping file would be a problem in that it would break the touchscreen controls. So, what the Android version of Dolphin did instead was to create its own input mapping system in Java, which stored the mappings in SharedPreferences... and also in Dolphin.ini at the same time. The inputs from the gamepad would be mapped by this second input mapping system to the "fake" inputs I mentioned before, and would then be mapped a second time by Dolphin's original input mapping system using the pre-defined mappings. Certainly not the prettiest solution, but it worked, and implementing a solution without this second input mapping system would be a lot of work.

The biggest problem of this second input mapping system is that it doesn't inherit support all the sophisticated features of Dolphin's usual input mapping system. Essentially, the developers had to start from scratch in terms of features. Various people have tried to add features since then, but it's always been hard to do, and some of the features that have been added have been pretty clunky. (Did you know that if you set a Wii Remote extension in the per-game settings, the Android app will actually copy the entirety of the pre-defined mappings, put them in an input profile, edit the game INI so that the new input profile will be loaded when launching the game, just to then be able to set the Wii Remote extension in the input profile? That's the extent of workarounds that had to be added because of the fundamentally different approaches of the two input mapping systems!)

What I've been wanting to do is to remove this second input mapping system and make the Android app use Dolphin's normal input mapping system. The first big blocker was figuring out some way for touch input to work without the pre-defined mappings. That was done in PR #9624. Then, after that, it was time for JNI work. Tons of JNI work. I've never done a JNI pull request as big as this one before, and maybe I will never need to again. But now, after one year of on-and-off work, here it is.

So with that history lesson out of the way, what new features do we get in this pull request?

• You can change controller settings while emulation is running.
• You can save and load input profiles. (The old feature of per-game mappings is replaced by per-game input profiles.)
• Advanced input expressions.
• You can map your device's accelerometer and gyroscope to whatever you want, not just Wii Remote motions.
• Support for many new device sensors. (How about the ambient light level, or the hinge angle of a foldable phone?)
• Support for sensors in gamepads. (Requires Android 12 or later.)
• If a device or gamepad has multiple motors, you can now choose between them for rumble. (Requires Android 12 or later.)
• You can set many boolean and numeric controller settings that weren't available on Android before, like Relative Input.
• The Sideways Wii Remote setting, the numeric settings for Wii Remote pointing, and the setting for disabling accelerometer/gyroscope pointing have been moved from the in-emulation settings to the regular settings.
• The touchscreen controller type setting has been overhauled. You can now choose between all controllers 1-4, but selecting a Wii Remote extension is now done in the regular settings.
• Separate gamepads are never treated as a single gamepad anymore. (Previously this would happen if they had the same descriptor.)
• Dolphin no longer mixes up buttons and axes that have the same ID.
• Possibly fixes for various issues with detecting axes. (Though I'm sure there are also new weird issues that will need to be hammered out!)

There are some heavily requested features that are not included here, and that is because I tried to keep this pull request as small as possible. You may not believe that at first with how huge it is, but more or less everything I've added in this pull request is something I had to add to not have any feature regressions. (Such is the nature of completely removing an old system and building something new in its place.) But this pull request does make those features much more feasible to add, so expect follow-up pull requests from me sometime after this pull request is merged.

I am now going to say something I very rarely say: I would like as many Android users as possible to test this pull request and provide feedback. This is a big pull request, and not only are there very many ways you might want to set up controller mappings, there are also very many different input devices out there that need to be tested for compatibility!

Things that need fixing:

• [ ] The GameCube controller type isn't runtime editable, preventing you from accessing GameCube controller settings during emulation. (To be done in a separate PR.)
• [ ] Maybe make it clearer that there's a very important submenu hiding behind the controller type setting, now that a bunch of settings that are useful for touchscreen users have been moved there. (To be done in a separate PR.)
• [ ] For some reason MotionAlertDialog can detect the phone moving around even though I made IsDetectable return false for all sensor axes.
• [ ] MotionAlertDialog doesn't detect volume key presses if you press the key too fast (probably because the inputs are only polled every 10 ms). This doesn't tend to be a problem with gamepad buttons.
• [ ] If a game wants sensor data very early, Dolphin can crash with a weird JNI error.
• [ ] The profile dialog and advanced mapping dialog could use some design improvement. (@t895, can you assist?)
• [ ] I couldn't get the profile dialog and advanced mapping dialog to work right without hardcoding dimensions (marked with TODO comments in the layout XML files).
• [ ] The bottom insets of SettingsActivity are a little wonky due to the warning for old controller configs.

The currently popular methods for NAT traversal involve having two clients send each other a UDP packet. This adds an entry to their NAT, linking their endpoint to the other client, which means the other client can reply, allowing communication. However, this doesn't work for everyone: some NATs, upon receiving an unsolicited packet, will add an entry linking that packet's source to the NAT itself, which completely blocks communication. The solution is to ensure the first packet does not reach the other side, by giving it an appropriate TTL value.

Dolphin happens to be quite well set up for this: the host fires the first shot, so it can configure one TTL value to use for all connecting clients. I propose an additional input field on the netplay setup menu, where the desired TTL can be filled in, and a "Test TTL" button which, when clicked, performs a test to check if it's adequate. This test requires three steps:

1. Send a "hello" over UDP to a test server (server A), which returns the IP and/or port of server B.
2. Send a UDP packet with the given TTL value to server B.
3. Ask server A to send a reply via server B. If it arrives, the TTL value used is sufficiently high to traverse all currently relevant NATs.

It's possible to run this test multiple times concurrently for different TTL values in order to automate the process, but the manual test seems more straightforward to implement and less janky to use.

I imagine you guys will want to use a custom server for this kind of thing, but as a proof of concept, I created a Python script to perform this test using publicly accessible STUN servers.

So far, I've implemented the TTL input field, but not the test, as I'd like to hear how you guys would prefer to handle it. I'm also open to suggestions on naming things: while the occasional forum post can be found describing this technique, I've yet to see any examples of it in practice, or even anyone giving the problem or the solution a name. This is despite the issue prompting it being by no means rare: I encounter it when using my phone as a Wi-Fi hotspot, and I've met several people who run into it even on wired connections (this includes almost every Brazilian I know).

In the NetPlayClient::Connect function, a packet is sent to the host, and the next received packet is treated as the response. However, sometimes, a ping response from the traversal server will arrive in-between, which breaks everything. In certain high-latency situations, it may even occur every time. This PR simply ignores any packets from the traversal server during this interaction.