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

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

  • 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

  • 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!

  • 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

  • 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!

  • 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

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

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

  • DSP accelerator improvements

    DSP accelerator improvements

    Improvements based on hardware testing:

    • D3 reads only seem to depend on the size bits of the format
    • D3 writes are always treated as if the format was 16-bit
    • D3 reads/writes appear to be raw data so D3 has been renamed to "Raw" and DD reads are called "Sample"
    • Format bit 2 seems to just break DD reads entirely, named it "raw_only" for now
    • Format bit 3 determines the decoding mode: ADPCM or PCM (not sure what non-4-bit ADPCM does, ADPCM is harder to test)
    • Format bits 4-5 appear to configure how the GAIN is processed in PCM mode (again, untested in ADPCM mode)

    Some IROM functions use some of the previously-unseen PCM formats for hashing/crypto.

  • DSPHLE: Add HLE version of libasnd ucode

    DSPHLE: Add HLE version of libasnd ucode

    This PR adds an HLE version of the libasnd ucode, which is used by older homebrew (and is simpler than the newer libaesnd ucode).

    I've done very limited testing with the oggplayer and mp3player examples included in libogc (these), which covers a single voice with 16-bit mono or stereo samples (though the stereo samples use the same data for both channels). For those, it works, but I'm not sure what else actually uses libasnd so I haven't tested further.

    I've only implemented the newest version that's included with libogc. Older versions probably won't be too hard to implement, as there have only been 3 commits on it, but I noticed that the compiled version in dsp_mixer.h used by libogc in the past doesn't exactly match the source code, so that needs to be investigated. (There's also padding differences caused by generating a header versus using bin2o.)

    This PR also includes the commit from #10753.

  • Reduce gradual audio desyncing in dumps and apply the correct sample rate for GameCube audio

    Reduce gradual audio desyncing in dumps and apply the correct sample rate for GameCube audio

    This PR aims to resolve issue 12951. Its current status right now should reduce the gradual desync, but not completely eliminate it. Eliminating it would be a bit complicated here, as either audio dumps would need to be reworked into some format that accepts non-integer sample rates (which I haven't has any luck finding such), or resampling the audio to an integer sample rate (probably the most "simple" here). Keeping this as draft for now.

  • VideoCommon: Fix SSBO layout and remove associated

    VideoCommon: Fix SSBO layout and remove associated "bug"

    Bug was ours, not AMD's

    If you don't specify a layout, the driver's free to do whatever it wants and we're supposed to ask it what it did. AMD probably went for std140 layout (where int[4] would have each int padded to 16 bytes)

    I don't see any reason we'd want an SSBO without std430, so I stuck it into the macro, but we could put it outside like we do for UBOs if you'd prefer that

  • Qt: Show currently configured Memory Card path in the config window.

    Qt: Show currently configured Memory Card path in the config window.

    More convenience stuff.

    img

    (AGP path is shown instead when that is selected.)

    The region shown is whatever the user has selected last if available, which I suspect is the least confusing option.

    If you try to manually write or paste an invalid path (missing region, already in other card, whatever) it will revert your change.

Bloopair allows connecting controllers from other consoles like native Wii U Pro Controllers on the Wii U.
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

Jun 13, 2022
Drogon: A C++14/17 based HTTP web application framework running on Linux/macOS/Unix/Windows
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

Jun 19, 2022
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

Feb 4, 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.

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

Jun 17, 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

Feb 4, 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

Jun 24, 2022
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.

May 8, 2022
Source-code based coverage for eBPF programs actually running in the Linux kernel
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

May 24, 2022
Basic jam templates using Handmade libraries to get up and running quickly.
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

Feb 20, 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

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

Feb 18, 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

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

Mar 28, 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

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

Jan 5, 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 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.

Jun 20, 2022
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.

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

Jun 18, 2022
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

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.

Jun 22, 2022