Dolphin is an emulator for running GameCube and Wii games on Windows, Linux, macOS, and recent Android devices.

Overview

Dolphin - A GameCube and Wii Emulator

Homepage | Project Site | Buildbot | Forums | Wiki | Issue Tracker | Coding Style | Transifex Page

Dolphin is an emulator for running GameCube and Wii games on Windows, Linux, macOS, and recent Android devices. It's licensed under the terms of the GNU General Public License, version 2 or later (GPLv2+).

Please read the FAQ before using Dolphin.

System Requirements

Desktop

  • OS
    • Windows (7 SP1 or higher).
    • Linux.
    • macOS (10.12 Sierra or higher).
    • Unix-like systems other than Linux are not officially supported but might work.
  • Processor
    • A CPU with SSE2 support.
    • A modern CPU (3 GHz and Dual Core, not older than 2008) is highly recommended.
  • Graphics
    • A reasonably modern graphics card (Direct3D 11.1 / OpenGL 3.3).
    • A graphics card that supports Direct3D 11.1 / OpenGL 4.4 is recommended.

Android

  • OS
    • Android (5.0 Lollipop or higher).
  • Processor
    • A processor with support for 64-bit applications (either ARMv8 or x86-64).
  • Graphics
    • A graphics processor that supports OpenGL ES 3.0 or higher. Performance varies heavily with driver quality.
    • A graphics processor that supports standard desktop OpenGL features is recommended for best performance.

Dolphin can only be installed on devices that satisfy the above requirements. Attempting to install on an unsupported device will fail and display an error message.

Building for Windows

Use the solution file Source/dolphin-emu.sln to build Dolphin on Windows. Visual Studio 2019 16.3 or later is a hard requirement. Other compilers might be able to build Dolphin on Windows but have not been tested and are not recommended to be used. Git and Windows 10 SDK must be installed when building.

Make sure to pull submodules before building:

git submodule update --init

The "Release" solution configuration includes performance optimizations for the best user experience but complicates debugging Dolphin. The "Debug" solution configuration is significantly slower, more verbose and less permissive but makes debugging Dolphin easier.

An installer can be created by using the Installer.nsi script in the Installer directory. This will require the Nullsoft Scriptable Install System (NSIS) to be installed. Creating an installer is not necessary to run Dolphin since the Binary directory contains a working Dolphin distribution.

Building for Linux and macOS

Dolphin requires CMake for systems other than Windows. Many libraries are bundled with Dolphin and used if they're not installed on your system. CMake will inform you if a bundled library is used or if you need to install any missing packages yourself.

macOS Build Steps:

  1. mkdir build
  2. cd build
  3. cmake ..
  4. make

An application bundle will be created in ./Binaries.

Linux Global Build Steps:

To install to your system.

  1. mkdir build
  2. cd build
  3. cmake ..
  4. make
  5. sudo make install

Linux Local Build Steps:

Useful for development as root access is not required.

  1. mkdir Build
  2. cd Build
  3. cmake .. -DLINUX_LOCAL_DEV=true
  4. make
  5. ln -s ../../Data/Sys Binaries/

Linux Portable Build Steps:

Can be stored on external storage and used on different Linux systems. Or useful for having multiple distinct Dolphin setups for testing/development/TAS.

  1. mkdir Build
  2. cd Build
  3. cmake .. -DLINUX_LOCAL_DEV=true
  4. make
  5. cp -r ../Data/Sys/ Binaries/
  6. touch Binaries/portable.txt

Building for Android

These instructions assume familiarity with Android development. If you do not have an Android dev environment set up, see AndroidSetup.md.

If using Android Studio, import the Gradle project located in ./Source/Android.

Android apps are compiled using a build system called Gradle. Dolphin's native component, however, is compiled using CMake. The Gradle script will attempt to run a CMake build automatically while building the Java code.

Uninstalling

When Dolphin has been installed with the NSIS installer, you can uninstall Dolphin like any other Windows application.

Linux users can run cat install_manifest.txt | xargs -d '\n' rm as root from the build directory to uninstall Dolphin from their system.

macOS users can simply delete Dolphin.app to uninstall it.

Additionally, you'll want to remove the global user directory (see below to see where it's stored) if you don't plan to reinstall Dolphin.

Command Line Usage

Usage: Dolphin [-h] [-d] [-l] [-e ] [-b] [-V ] [-A ]

  • -h, --help Show this help message
  • -d, --debugger Show the debugger pane and additional View menu options
  • -l, --logger Open the logger
  • -e, --exec= Load the specified file (DOL,ELF,WAD,GCM,ISO)
  • -b, --batch Exit Dolphin with emulator
  • -V, --video_backend= Specify a video backend
  • -A, --audio_emulation= Low level (LLE) or high level (HLE) audio

Available DSP emulation engines are HLE (High Level Emulation) and LLE (Low Level Emulation). HLE is faster but less accurate whereas LLE is slower but close to perfect. Note that LLE has two submodes (Interpreter and Recompiler) but they cannot be selected from the command line.

Available video backends are "D3D" and "D3D12" (they are only available on Windows), "OGL", and "Vulkan". There's also "Null", which will not render anything, and "Software Renderer", which uses the CPU for rendering and is intended for debugging purposes only.

Sys Files

  • wiitdb.txt: Wii title database from GameTDB
  • totaldb.dsy: Database of symbols (for devs only)
  • GC/font_western.bin: font dumps
  • GC/font_japanese.bin: font dumps
  • GC/dsp_coef.bin: DSP dumps
  • GC/dsp_rom.bin: DSP dumps
  • Wii/clientca.pem: Wii network certificate
  • Wii/clientcakey.pem: Wii network certificate key
  • Wii/rootca.pem: Wii network certificate issuer / CA

The DSP dumps included with Dolphin have been written from scratch and do not contain any copyrighted material. They should work for most purposes, however some games implement copy protection by checksumming the dumps. You will need to dump the DSP files from a console and replace the default dumps if you want to fix those issues.

Wii network certificates must be extracted from a Wii IOS. A guide for that can be found here.

Folder Structure

These folders are installed read-only and should not be changed:

  • GameSettings: per-game default settings database
  • GC: DSP and font dumps
  • Maps: symbol tables (dev only)
  • Shaders: post-processing shaders
  • Themes: icon themes for GUI
  • Resources: icons that are theme-agnostic
  • Wii: default Wii NAND contents

Packaging and udev

The Data folder contains a udev rule file for the official GameCube controller adapter and the Mayflash DolphinBar. Package maintainers can use that file in their packages for Dolphin. Users compiling Dolphin on Linux can also just copy the file to their udev rules folder.

User Folder Structure

A number of user writeable directories are created for caching purposes or for allowing the user to edit their contents. On macOS and Linux these folders are stored in ~/Library/Application Support/Dolphin/ and ~/.dolphin-emu respectively, but can be overwritten by setting the environment variable DOLPHIN_EMU_USERPATH. On Windows the user directory is stored in the My Documents folder by default, but there are various way to override this behavior:

  • Creating a file called portable.txt next to the Dolphin executable will store the user directory in a local directory called "User" next to the Dolphin executable.
  • If the registry string value LocalUserConfig exists in HKEY_CURRENT_USER/Software/Dolphin Emulator and has the value 1, Dolphin will always start in portable mode.
  • If the registry string value UserConfigPath exists in HKEY_CURRENT_USER/Software/Dolphin Emulator, the user folders will be stored in the directory given by that string. The other two methods will be prioritized over this setting.

List of user folders:

  • Cache: used to cache the ISO list
  • Config: configuration files
  • Dump: anything dumped from Dolphin
  • GameConfig: additional settings to be applied per-game
  • GC: memory cards and system BIOS
  • Load: custom textures
  • Logs: logs, if enabled
  • ScreenShots: screenshots taken via Dolphin
  • StateSaves: save states
  • Wii: Wii NAND contents

Custom Textures

Custom textures have to be placed in the user directory under Load/Textures/[GameID]/. You can find the Game ID by right-clicking a game in the ISO list and selecting "ISO Properties".

Comments
  • Hybrid xfb

    Hybrid xfb

    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
    opened by iwubcode 213
  • Vulkan: macOS support via MoltenVK

    Vulkan: macOS support via MoltenVK

    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.
    opened by stenzek 180
  • Support for motion controllers like the DualShock 4

    Support for motion controllers like the DualShock 4

    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

    2019-09-19 15_04_21-vs2017 (1) - Remote Viewer 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.

    opened by rlnilsen 171
  • Texture lookup fix

    Texture lookup fix

    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

    opened by Miksel12 132
  • Apple M1 Support for MacOS

    Apple M1 Support for MacOS

    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!

    opened by skylersaleh 123
  • Vulkan Backend

    Vulkan Backend

    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 Reviewable

    opened by stenzek 116
  • Resolution independent mipmaps (high IR Super Mario Galaxy Fix)

    Resolution independent mipmaps (high IR Super Mario Galaxy Fix)

    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):

    00000000-3

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

    With the hack enabled (still 6x IR): 00000000-2

    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!

    opened by Tomcc 112
  • Add ability to passthrough a Bluetooth adapter

    Add ability to passthrough a Bluetooth adapter

    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 Reviewable

    opened by leoetlino 112
  • Ubershaders 2.0

    Ubershaders 2.0

    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.
    opened by stenzek 103
  • Improve netplay UX

    Improve netplay UX

    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: image

    Chat box: image

    Review on Reviewable

    opened by ShimmerGlass 96
  • HLE Riivolution patch support

    HLE Riivolution patch support

    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!

    step4

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

    opened by AdmiralCurtiss 80
  • Move Vulkan calls to a separate thread

    Move Vulkan calls to a separate thread

    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.

    opened by K0bin 3
  • PixelShaderGen: Clamp texture layer when using manual texture sampling with stereoscopic 3D

    PixelShaderGen: Clamp texture layer when using manual texture sampling with stereoscopic 3D

    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.

    opened by Pokechu22 3
  • Android input overhaul

    Android input overhaul

    (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.
    opened by JosJuice 0
  • Netplay: Add Initial Packet TTL option

    Netplay: Add Initial Packet TTL option

    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).

    opened by skyfloogle 4
  • Netplay: Fix traversal connections occasionally not working

    Netplay: Fix traversal connections occasionally not working

    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.

    opened by skyfloogle 0
Owner
Dolphin Emulator
Dolphin Emulator
Bloopair allows connecting controllers from other consoles like native Wii U Pro Controllers on the Wii U.

Bloopair Bloopair allows connecting controllers from other consoles like native Wii U Pro Controllers on the Wii U. It temporarily applies patches to

null 208 Jan 3, 2023
Drogon: A C++14/17 based HTTP web application framework running on Linux/macOS/Unix/Windows

English | 简体中文 | 繁體中文 Overview Drogon is a C++14/17-based HTTP application framework. Drogon can be used to easily build various types of web applicat

An Tao 8.5k Jan 5, 2023
Header-only C++14 library for getting network addresses associated with network interface without name lookups on Windows, macOS, Linux, and FreeBSD

NetIF Get addresses associated with network interfaces on a system without using name lookups. Header-only, requires C++14. Usage Add the header file

GMLC-TDC 9 Oct 17, 2022
Graphical small-internet client for windows, linux, MacOS X and BSDs. Supports gemini, http, https, gopher, finger.

Graphical small-internet client for windows, linux, MacOS X and BSDs. Supports gemini, http, https, gopher, finger.

Felix Queißner 569 Dec 30, 2022
Netif - Header-only C++14 library for getting network addresses associated with network interface without name lookups on Windows, macOS, Linux, and FreeBSD

NetIF Get addresses associated with network interfaces on a system without using name lookups. Header-only, requires C++14. Usage Add the header file

GMLC-TDC 9 Oct 17, 2022
ESP-IDF is the development framework for Espressif SoCs supported on Windows, Linux and macOS.

Espressif IoT Development Framework 中文版 ESP-IDF is the development framework for Espressif SoCs supported on Windows, Linux and macOS. ESP-IDF Release

Espressif Systems 9.7k Jan 4, 2023
GNUWeebBot - High-performance bot Telegram, running on Linux environment.

High-performance bot Telegram, running on Linux environment, written in C. Core Features Event Debug Event Logger Modules Telegram debug info.

GNU/Weeb 11 May 8, 2022
Source-code based coverage for eBPF programs actually running in the Linux kernel

bpfcov Source-code based coverage for eBPF programs actually running in the Linux kernel This project provides 2 main components: libBPFCov.so - an ou

elastic 113 Nov 23, 2022
Basic jam templates using Handmade libraries to get up and running quickly.

This is a selection of template projects to get up and running with for the Wheel Reinvention Jam. They are built on top of Handmade-inspired librarie

Handmade Network 16 Nov 27, 2022
AWS FreeRTOS MQTT demo project running on the NXP i.MXRT1050-EVKB.

AWS MQTT demo example project Click to import in Keil Studio Cloud: Board: NXP IMXRT1050-EVKB The tables below list the device configuration for this

Arm - Keil tools 1 Oct 18, 2021
Extract TLS session keys from running programs

Tlskeydump Tlskeydump extracts TLS key material from processes at runtime so that packet captures containing TLS-encrypted data can be decrypted and a

Konstantinos Tsanaktsidis 7 Sep 5, 2022
WslinkClient is a client intended to communicate with Wslink, which is a unique loader running as a server

WslinkClient WslinkClient is a client intended to communicate with Wslink, which is a unique loader running as a server and executing received modules

ESET 12 Apr 19, 2022
Dohd is a minimalist DNS-over-HTTPS daemon that redirects all DoH queries to a local DNS server running on localhost:53 (UDP)

dohd Dohd (pron. doh-dee) is a minimalist DNS-over-HTTPS daemon that redirects all DoH queries to a local DNS server running on localhost:53 (UDP). Fe

Dyne.org 16 Dec 1, 2022
An MQTT-based Virtual Wall for ESP8266 Devices and Gerber files to make the IR hat; this code and board can easily be adapted to be ANY infrared controller/remote!

Roomba-Virtual-Wall-ESP8266-MQTT An MQTT-based Virtual Wall for ESP8266 Devices I made this based off of the IRSend, IRremoteESP8266, and EspMQTTClien

null 8 Sep 20, 2021
Linux Terminal Service Manager (LTSM) is a set of service programs that allows remote computers to connect to a Linux operating system computer using a remote terminal session (over VNC or RDP)

Linux Terminal Service Manager (LTSM) is a set of service programs that allows remote computers to connect to a Linux operating system computer using a remote terminal session (over VNC)

null 34 Dec 16, 2022
LANDrop is a cross-platform tool that you can use to conveniently transfer photos, videos, and other types of files to other devices on the same local network.

LANDrop is a cross-platform tool that you can use to conveniently transfer photos, videos, and other types of files to other devices on the same local network.

LANDrop 3.4k Jan 7, 2023
ImmortalWrt is a fork of OpenWrt, with more packages ported, more devices supported, better performance, and special optimizations for mainland China users.

ImmortalWrt is a fork of OpenWrt, with more packages ported, more devices supported, better performance, and special optimizations for mainland China users.

null 4 Jan 31, 2022
A socket daemon to multiplex connections from and to iOS devices

usbmuxd A socket daemon to multiplex connections from and to iOS devices. Features usbmuxd stands for "USB multiplexing daemon". This daemon is in cha

libimobiledevice 1.2k Jan 7, 2023
SixtyFPS is a toolkit to efficiently develop fluid graphical user interfaces for any display: embedded devices and desktop applications

SixtyFPS is a toolkit to efficiently develop fluid graphical user interfaces for any display: embedded devices and desktop applications. We support multiple programming languages, such as Rust, C++, and JavaScript.

SixtyFPS 5.5k Jan 2, 2023