Anemone3DS: a theming and boot splash manager for the Nintendo 3DS written in C

What Anemone3DS manages on a 3DS

Anemone3DS is described in one line as a theme and splashscreen manager for the Nintendo 3DS, written in C. The Makefile gives it a second description, the application metadata string, that reads "A complete theming tool for the 3DS".

That is the whole scope, and it is a specific one. The tool exists for people running homebrew on a 3DS who want the system menu to look different from the stock theme, and who want the screen you see at power on replaced with something of their own. It is not a general homebrew launcher, a file manager, or a system modification tool, and it is not aimed at the wider ecosystem of current Nintendo hardware.

The repository layout backs up the theme focus. There is `romfs/`, which holds the assets packaged into the executable's virtual filesystem, `meta/` for the banner and icon metadata, `assets/` for other bundled files, `source/` and `include/` for the C code, and a top level `Makefile` and `LICENSE`.

One detail in the credits section is more informative than the feature list. The acknowledgement notes that the code of Rinnegatamante served as a reference on theme installation, and that the GYTB and ABE code from other authors served as a reference on badge management. A separate mention credits the BCSTM-Player project as a reference on the BCSTM format. Those references map onto the three substantial jobs in the tool: applying a theme, handling badges, and dealing with the binary stream format used for the system animation data behind the boot splash. Reading the credits is a faster way to understand the subsystems than the README itself, which never describes them in prose.

The Makefile refuses to build without DEVKITARM

Building Anemone3DS is a devkitARM project, and the toolchain is not optional. The README states that `$DEVKITPRO` and `$DEVKITARM` should be set to `/opt/devkitpro` and `$DEVKITPRO/devkitARM` respectively.

The Makefile enforces this rather than trusting the developer. It checks whether `$(DEVKITARM)` is empty and stops with an error if it is:

export DEVKITARM=<path to>devkitARM

That is the exact hint the build system prints when the variable is missing. The Makefile then includes `$(DEVKITARM)/3ds_rules`, the standard devkitARM rules file for 3DS targets, which is where the compiler flags, the linker behaviour and the ROMFS packaging steps come from. The application metadata is set at the top of the same file, with `APP_TITLE:= Anemone3DS`, `APP_DESCRIPTION:= A complete theming tool for the 3DS`.

For anyone who has built devkitPro software before, this is a familiar pattern and the whole build is `make` in a configured shell. For anyone who has not, the hard part is not this project but the toolchain: devkitARM is installed following the devkitPro getting started instructions, and the base install group `3ds-dev` has to be present in devkitPro pacman before the rest works. Expect the setup to take longer than the compilation.

pacman packages, makerom and bannertool

Once the toolchain is in place, the dependency list is specific and the README is precise about what each piece is for.

The base system needs `make`, `git` and `pkg-config`. The libraries come from devkitPro pacman, and the documented package names are `3ds-jansson`, `3ds-libvorbisidec`, `3ds-libpng`, `3ds-lz4`, `3ds-libarchive` and `3ds-curl`, installed with the pacman front end:

[sudo] [dkp-]pacman -S <package-name>

The bracketed parts of that command are the interesting part. Depending on the distribution, the pacman invocation is prefixed with `sudo` and, on some setups, with `dkp-`. Use the variant your devkitPro installation provides.

Two external programs sit outside the pacman system and have to be handled by hand. A recent build of makerom and the latest release of bannertool are required, and both must be added to your PATH. The README links makerom to the Project_CTR repository and bannertool to the buildtools repository.

Those two tools are not optional conveniences. bannertool produces the banner and icon metadata that the `meta/` directory supplies, and makerom assembles the final executable image, so without them on the PATH the build reaches the packaging stage and fails there rather than at the start. Getting them onto the PATH is the single most common stumble in this build, because the error appears late.

When the toolchain, the packages and the PATH are all correct, the build is a single command:

make

All built binaries end up in `/out/`, which is where you pick up the file to install on the console.

Cloning the source and the licensing of the bundled icons

The clone step is the one part of the setup with no ambiguity, and the README is explicit that any other cloning method works equally well:

git clone https://github.com/astronautlevel2/Anemone3DS

The default branch is `master`, and the tree you get contains `source/`, `include/`, `romfs/`, `meta/`, `assets/`, a `Makefile`, `CONTRIBUTORS.md`, `LICENSE` and the `README.md`.

The licensing has two layers and both matter if you redistribute anything. The project itself is licensed under the GNU GPLv3, and the README adds that additional terms 7b and 7c apply to it, with the full text in `LICENSE.md`. GPLv3 carries the usual copyleft obligations for a distributed derivative work, and the two extra terms modify the standard grant, so the practical step is to read `LICENSE.md` rather than to assume the plain GPLv3 text applies.

The second layer is the assets. Most of the icons under `romfs/` come from icons8.com and are licensed under CC-BY-NC-SA 3.0, which is a share-alike licence carrying a non-commercial clause. Those terms do not match the GPLv3 terms of the code, and the combination is worth understanding before you ship a build. If your use is personal, on your own console, this is largely a non-issue. If you intend to distribute a compiled build or the assets, you have two separate licence obligations to satisfy rather than one. That is a description of what the files state, not legal advice, and the practical move is to read `LICENSE.md` and the CC-BY-NC-SA terms before publishing anything.

v3.0.1 in June 2024 against pushes in October 2026

The release history and the commit history tell different stories, and you should read both before deciding what you are installing.

The published tags are v3.0.1, labelled as a hotfix, on 2024-06-18, v3.0.0, labelled "Beyond Journey's End", on 2024-06-14, and the v3.0.0b beta on 2024-05-21. That is a small cluster of releases within about a month, the last of them more than two years before the last push, and the naming suggests a significant release followed by a quick fix.

The last push to `master` was on 2026-10-13 and the repository is not archived, so the source tree has continued to move since v3.0.1. What that means for a user is a choice with no obvious default. Building from `master` gives you the latest work, but a theme manager that manipulates system files is exactly the kind of software where you want to know that the version you are running has been exercised by other people. The tagged builds have that property; an arbitrary `master` commit does not.

The upgrade cost is also higher than a normal application because the artefact is not a self-contained installer. The output in `/out/` has to be transferred to the console and installed through the homebrew environment you already use, and the toolchain itself needs updating when devkitARM moves on. In practice, keeping a built copy of v3.0.1 around is a reasonable precaution, and rebuilding from `master` is a choice you make with the knowledge that untagged commits are the untested ones.

Why this is more build machinery than a theme switcher

The honest limitation of Anemone3DS is the toolchain, and it is worth being clear about it because the tool itself is small.

To change a theme on a 3DS you do not need a compiler. If you have a prebuilt binary or a package from the homebrew distribution channel, the runtime work is done for you. What Anemone3DS asks of a developer who wants to build it is a full cross-compilation environment: devkitARM, devkitPro pacman with the `3ds-dev` group, six library packages, two separately sourced binaries, two exported environment variables, and a PATH that points at both external tools. Each of those is individually reasonable. Together they make the difference between a five minute change and an afternoon of setup.

The scope limit is equally clear. The tool is for the Nintendo 3DS, in C, built against the 3DS toolchain rules. It is not portable to the other Nintendo handhelds, and nothing in the README or the build system suggests an attempt at that. Anyone evaluating it for a different console is looking at the wrong repository.

The alternative approach is worth naming because the difference is about distribution rather than features. Instead of compiling the tool yourself, you use a prebuilt release artefact or the packaged version distributed through the homebrew community, and you treat the source repository as the place to read what the code does rather than as something you must build. The repository is genuinely useful in that role: the credits, the `CONTRIBUTORS.md` file and the source tree tell you how theme installation, badge management and the BCSTM format are handled, and the theme format documentation lives in the source of the tool that consumes it.

The trap to avoid is pulling `master` expecting parity with the latest release and then diagnosing a theme that fails to install as a console problem rather than as a version mismatch.

Editorial conclusion

Adopt Anemone3DS if you own a 3DS, want to change the system theme and the boot splash, and are prepared to install a full devkitARM toolchain, or to compile it yourself with pacman packages for jansson, libpng, libvorbisidec, lz4, libarchive and curl, plus makerom and bannertool on your PATH. It is the wrong tool for anyone building for current Nintendo hardware, and it is more build machinery than most people expect for a theme switcher. Verify three things before you start: that `$DEVKITPRO` and `$DEVKITARM` are exported as the Makefile demands, that makerom and bannertool are on your PATH rather than merely installed, and whether the CC-BY-NC-SA terms on the bundled icons and the added GPLv3 terms 7b and 7c fit how you intend to redistribute the result.

Frequently asked questions

Official sources

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