NooDS: a DS and GBA emulator built for software rendering, on eight platforms

Software rendering, and what that choice costs

NooDS is a DS and GBA emulator, and the goal stated for it is to be fast and portable, with accurate software rendering with upscaling, and the ability to take advantage of multiple cores for better performance.

Software rendering is the decision that shapes everything else. The DS has two screens, the bottom one a touch screen, and NooDS renders its graphics in software and upscales, which is a deliberate trade: you get accurate output that matches what the hardware would draw, and you give up the raw fill rate that a GPU-accelerated emulator could provide.

For the platforms it targets, that trade is usually the right one. The Switch, Wii U and Vita have modest integrated GPUs, and the accuracy claim matters for the many DS games whose rendering quirks are load-bearing. The Makefile reflects the approach directly: the build sets -DUSE_GL_CANVAS, and on Linux it links -lGL while on macOS it does not, so the GL canvas path is used where it makes sense and the platform handles the rest.

The scope is DS and GBA, so this is a combined emulator rather than a DS-only one, with a GBA BIOS file optionally provided. The repository layout matches a two-emulator project: src contains the core, with subdirectories for arm, gpu, hle, io and memory, and src/ui has a desktop front end alongside the ui code itself. The Makefile's SRCS line enumerates exactly those directories, and the C++ standard is set to c++11 with -Ofast and -flto.

The author is explicit about the intent. The project started as something for fun and as a learning experience, and the goal is to keep it that way. If people are interested and get use out of it, that is a bonus.

The BIOS and firmware problem, which is the real setup step

NooDS should be able to run most things without any setup, but that sentence has a significant exception attached to it, and the exception is where most of the friction lives.

DS BIOS and firmware files must be provided to boot the system menu, and they can be dumped from a DS with DSBF Dumper. The firmware must come from an original DS, and the reason is stated plainly: DSi and 3DS dumps do not contain any boot code. A GBA BIOS file can be optionally provided, dumped from many systems with a separate dumper, and the file paths can be configured in the settings menu.

This is the part that stops most people, and it is a legal and practical constraint rather than a technical one. The emulator cannot ship the copyrighted boot code, so you have to extract it from hardware you own. And the requirement is specifically an original DS, not a later model, because the later models do not have the boot code in the same form.

Once you have the files, the second sharp edge is save detection. Save types are automatically detected, but this may not always be accurate, and if you run something and it has issues with saving, the save type can be overridden in the file menu. That is a common emulator complaint handled in a sensible way: guess first, let the user correct the guess.

The references section is also unusually good, and it tells you how the project reaches correctness. GBATEK is named as the main information source for all things DS and GBA, with a GBATEK Addendum thread that aims to fill the gaps in GBATEK, the melonDS blog for posts detailing various 3D quirks, and two references specifically for the HLE BIOS functions, DraStic BIOS and Cult of GBA BIOS. HLE means high level emulation, and the presence of an hle directory in the source tree matches.

What the repository layout says about the architecture

The source tree is small enough to read in one listing, and the Makefile SRCS variable enumerates the same directories: src, src/core, src/core/arm, src/core/gpu, src/core/hle, src/core/io, src/core/memory, src/ui and src/ui/desktop.

The split between core and ui is the same one the architecture depends on. Everything under core is the emulation itself, and it is where the work lives. The arm directory is the CPU, the gpu directory is the graphics hardware, the io directory is the memory-mapped peripheral interface, the memory directory is the storage and RAM model, and the hle directory is where the high level emulation of the BIOS functions lives.

That hle directory connects back to the two BIOS references in the documentation. When a game calls a firmware function that the emulator does not implement at the hardware level, the HLE path approximates it in software, and the DraStic BIOS and Cult of GBA BIOS projects are the reference implementations the author has been matching behaviour against. The same split appears in the build flags, with -DLOG_LEVEL=0 compiled in by default, so the logging exists in the code and is compiled down to nothing for release builds.

The desktop UI is wxWidgets, with OpenGL canvas support through the -DUSE_GL_CANVAS define, and the audio path is PortAudio, referenced through pkg-config for both the libraries and the cflags. The Windows build links wx-config-static, and the extra libraries there are -lole32, -lsetupapi and -lwinmm, which are the Windows APIs a GUI and audio application needs. The macOS branch adds -DMACOS and -headerpad_max_install_names, the latter being the flag that lets a bundled shared library be loaded from a path inside the app bundle rather than an absolute install path, which is what makes the.app from the install target work.

The Gradle build files (build.gradle, settings.gradle, gradle.properties and the gradle directory) sit alongside the C++ sources rather than inside src, which is the usual arrangement for a project that is a native C++ application with a thin Java shell for the mobile builds.

Eight platform targets, one Makefile

NooDS is available for Windows, macOS, Linux, Android, iOS, Switch, Wii U and Vita, and the latest builds are automatically provided via GitHub Actions, downloadable from the releases page. The release listing shows a single rolling release entry rather than versioned tags, so the project ships a continuously updated binary rather than milestones.

The build system is a plain Makefile with per-platform makefiles for the three console targets, Makefile.switch, Makefile.vita and Makefile.wiiu, and separate targets for iOS and Android. The desktop build is the same on macOS and Linux, needing wxWidgets and PortAudio, installed with Homebrew on macOS or a built-in package manager on Linux, then make -j$(nproc) in the project root.

On Windows the dependency set is a single MSYS2 pacman command:

pacman -Syu mingw-w64-ucrt-x86_64-{gcc,pkg-config,wxwidgets3.3-msw,portaudio,jbigkit} make

followed by make -j$(nproc) from the project root.

The console targets each need their own toolchain: devkitPro and its switch-dev package for the Switch, devkitPro and wiiu-dev for the Wii U, and the Vita SDK for the Vita, each built with make switch -j$(nproc), make wiiu -j$(nproc) and make vita -j$(nproc) respectively.

Android needs Android Studio or the command line tools and is built with make android, with dependencies installed as needed, which is why the repository carries a build.gradle, a gradle directory, a settings.gradle and a gradle.properties. iOS needs Xcode and NooDS.xcodeproj, or make ios for an unsigned .ipa, and the Makefile shows that build as an xcodebuild archive with the code signing identity and signing required both disabled, then repackaging the archive into an .ipa.

The desktop packaging is also in the Makefile, with an install target that runs a mac-bundle.sh script and copies the NooDS.app bundle into /Applications, an uninstall target that removes it, and a flatpak target that builds and bundles a Flatpak using a YAML manifest in the meta directory.

A project that explicitly does not take pull requests

The contributing section is short and unambiguous. This is a personal project, and the author has decided not to review or accept pull requests for it. If you want to help, you can test things and report issues or provide feedback, and if you can afford it, donate to motivate the author and allow more time to be spent on things like this. Nothing is mandatory, and any interest in the projects is appreciated, even as just a user.

That is a legitimate choice for a hobby project, but it changes what the project is and is not for a prospective contributor. There is no upstream route for a feature or a fix. The realistic options are to maintain a fork, to report issues and wait, or to work on the underlying reference material instead.

It also means the project should be evaluated as the work of one person with a stated intent to keep it personal. That cuts both ways. The upside is that the design decisions are consistent and there is no committee. The downside is that the bus factor is one, and the rolling release scheme means there is no stable version to pin a fork against.

For a user, none of this matters much beyond knowing that bug reports are the accepted contribution. The Discord server is linked for chat about the projects, and there is a blog called Hydra's Lair where the author may or may not write about things, which is a fair description of the odds of finding a post about a specific question.

The project is licensed GPL-3.0 with a LICENSE file at the root, the repository is not archived, and the last push was on 2026-08-09, which is also the date of the rolling release.

Editorial conclusion

NooDS suits someone who wants a portable DS or GBA emulator that runs on a console or a handheld as readily as on a desktop, and who is comfortable supplying their own BIOS and firmware dumps. It is a poor fit if you want to contribute code, because the author states plainly that pull requests are not reviewed or accepted, and a poor fit if you need a UI or feature set the upstream project does not have. Before adopting, dump your own BIOS and firmware with DSBF Dumper from an original DS, because DSi and 3DS dumps contain no boot code, and check the settings menu for the path configuration and the file menu for a save type override if a game misbehaves when saving.

Frequently asked questions

Official sources

1. Hydr8gon/NooDS on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases