Library / SDK
mupen64plus/mupen64plus-core avatar
mupen64plus/mupen64plus-core

Mupen64Plus-Core: Nintendo 64 Emulation Library

Core module of the Mupen64Plus project

1,565 stars285 forksCLicense varies

At a glance

What is it?
Mupen64Plus-Core is the C library at the center of Mupen64Plus, supplying the emulation core that graphics, sound, input, and RSP plugins connect to. It is intended for developers assembling a complete Nintendo 64 emulator, not for users looking for a standalone front-end.
Who is it for?
Mupen64Plus-Core fits developers who need the C core library and are prepared to provide compatible plugins and a front-end. It is not a standalone emulator for end users.
Can I use it commercially?
Not without permission. GitHub finds no licence file in the repository, and without a licence all rights are reserved by default: you may read the code but not reuse it. Check the README, or ask the authors, before using it.
Is it still maintained?
Yes. The repository last received commits 3 days ago.
What is it written in?
Mainly C, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on October 20, 2026, and from our analysis. They are not legal advice.

Editorial analysis

What Mupen64Plus-Core Does Inside Mupen64Plus

Mupen64Plus-Core solves a specific integration problem: it provides the core library used by Mupen64Plus while leaving the surrounding media and user-interface components to other software. The README says that this package contains only the Mupen64Plus core library. A fully functional emulator also needs graphics, sound, input, and RSP plugins, plus a user-interface program called a front-end. The intended user is therefore a developer, packager, or integrator who already understands the Mupen64Plus component structure.

The project originated from mupen64, which the README attributes to Hacktarux, and is written primarily in C. Its repository contains source code under src, platform-related projects under projects, shared data under data, documentation under doc, and licensing information under LICENSES. This layout makes the package appear to be the engine rather than the complete application. Installing only the core library does not produce a usable emulator by itself.

That boundary matters for evaluation. The core can be built and installed independently, but a user still needs compatible plugin and front-end components. The README does not document a configuration file for selecting those plugins or a command-line interface for launching a game, so this repository is not the place to look for a complete user experience.

Core Architecture and Build-Time Boundaries

The documented architecture is a library-centered emulator design. Mupen64Plus-Core supplies the core, while separate graphics, sound, input, and RSP plugins provide the corresponding device or service layers. The front-end supplies the user interface. This division allows the core to be integrated with separately installed components, but it also means compatibility between those pieces is a deployment requirement rather than something resolved by this package alone.

The build system exposes the boundaries and feature choices of the library. The default build uses compiler optimization and link-time optimization according to the listed defaults. Other documented options control assembly use, OpenGL or GLESv2, LIRC, networking, OpenCV, Vulkan behavior, accurate FPU behavior, and debugging facilities. The `NO_ASM=1` option removes assembly-dependent code, including the dynamic recompiler and MMX or SSE code. The `NEW_DYNAREC=1` option replaces the dynamic recompiler with Ari64's experimental dynarec, which is a deliberate build-time choice rather than a general compatibility promise.

The available targets confirm that this repository is a library package. The `all` target builds the Mupen64Plus core library, `install` installs it, and `uninstall` removes installed files. A build can produce a library and optional debugger API, but the README does not describe a standalone emulator executable generated from this package.

Installing Mupen64Plus-Core From Source

The README gives source-build instructions for the Unix-oriented `projects/unix` directory. Before building, the documented source requirements are GNU C and C++ compilers, libraries, headers, GNU make, Nasm, development packages, SDL 2, libpng, freetype 2, and zlib. The commands below use the names and sequence shown in the README.

After unpacking the source distribution, change into the Unix build directory and build the core library:

bash
unzip mupen64plus-core-x-y-z-src.zip
cd mupen64plus-core-x-y-z-src/projects/unix
make all

The reader should see the core library build complete without the `make all` target attempting to install files. To list the available targets and options, run make by itself:

bash
make

That command displays the documented build, installation, debugging, and platform options. A useful caution is that this builds only the core library. The complete Mupen64Plus installation still requires the other plugins and a front-end.

Choosing a Prefix and Installing the Library

Source installation uses the `PREFIX` option. The README says the prefix must be supplied both when building and installing, because the resulting binary is compiled to find data in the selected installation location. The documented example targets `/usr`:

bash
make PREFIX=/usr all
sudo make PREFIX=/usr install

The installation places files under `$PREFIX/bin` and creates shared data under `$PREFIX/share/mupen64plus`. The make output also documents separate `SHAREDIR`, `LIBDIR`, and `INCDIR` options, plus `DESTDIR` for packagers. The core library is installed to `LIBDIR`, and its headers to `INCDIR`.

The README describes a binary distribution installation path that switches to root and runs the provided installer:

bash
su
# ./install.sh
# exit

It states that `install.sh` copies the executable to `/usr/local/bin` and creates `/usr/local/share/mupen64plus`. The README warns that using a custom prefix with the binary installer can cause the front-end to fail to find the core library unless the path is known to the dynamic library loader. That warning applies to the complete installation arrangement, so checking paths is important before adding plugins or a front-end.

Build Options for Developers

The make options make the core adaptable to different targets, but they also expose the trade-off between platform features and portability. The documented `USE_GLES=1` option builds against GLESv2 instead of OpenGL, while `VC=1` targets Broadcom Videocore GLESv2. ARM builds can use `NEON=1` or `VFP_HARD=1`, and `BITS=32` builds 32-bit binaries on a 64-bit machine. These are build decisions with hardware and platform implications.

Optional functionality is also explicit. `NETPLAY=1` enables netplay but requires SDL2_net. `LIRC=1` enables LIRC support. `OPENCV=1` enables OpenCV support, and `VULKAN=0` disables Vulkan support in the default video extension implementation. `ACCURATE_FPU=1` enables more accurate FPU behavior, including correct cause bits, but may not produce the same build profile as the default.

Debugging is available through `DEBUG=1`, `DEBUGGER=1`, `DBG_CORE=1`, `DBG_COUNT=1`, `DBG_COMPARE=1`, `DBG_TIMING=1`, `DBG_PROFILE=1`, `PROFILE=1`, and `V=1`. The README states that the debugger API runs slower. These switches are useful during development, although the documentation does not quantify their effect on playback or system requirements.

Limits of the Core Package

The clearest limitation is functional completeness. A binary built from this package is not described as a standalone emulator because the core depends on graphics, sound, input, and RSP plugins and a front-end. Missing one of those categories leaves the installation unable to provide the complete experience described by the README.

The package also has a dependency footprint. Binary requirements include SDL 2, libpng, freetype 2, and zlib, while source builds require their development packages in addition to compilers and Nasm. Installation can fail or misbehave when the selected prefix does not match where the front-end searches for the core library and shared data. The binary installer's custom-prefix warning is a concrete deployment boundary, not a hypothetical portability concern.

The repository's license is listed as unknown in the project information, while the repository includes a `LICENSES` directory. The README excerpt does not identify the exact applicable license terms. A developer considering redistribution or integration should inspect `LICENSES`, `INSTALL`, and the release documentation directly. No legal conclusion can be drawn from the repository description alone.

Mupen64Plus-Core Compared With a Complete Emulator

Mupen64Plus-Core differs from a complete emulator by scope rather than by a separate emulation technology. The core provides the central library, while the complete Mupen64Plus arrangement adds graphics, sound, input, and RSP plugins and a front-end. The core package therefore offers lower-level integration for developers who need to assemble or package their own emulator stack.

This approach can fit a project that already has a front-end and compatible plugin set. It is less suitable for a user who expects to download one package, configure input, load a game, and start the emulator through a documented interface here. The README provides build and installation commands, but it does not document game launching, plugin selection, or a complete end-user configuration workflow.

There is no documented version compatibility matrix in the excerpt. The project metadata lists releases including Mupen64Plus v2.6.0, but the repository information does not state which plugin or front-end versions must be paired with that release. Integrators must verify that relationship rather than assuming that any separately installed component will work.

Maintenance and Release Context

The repository is not archived, and the last push was on 2026-10-02. That is the available maintenance signal, so it should be considered alongside the dependency and compatibility questions above rather than treated as proof that every component is synchronized. The release list includes `nightly-build` dated 2022-04-12, `Mupen64Plus v2.6.0` dated 2024-07-15, and `Mupen64Plus v2.5.9` dated 2019-02-10. The repository has a GitHub Actions build workflow, a Coverity Scan badge, and AppVeyor configuration in its listed files and README badges.

The upgrade decision depends on matching the core with its surrounding Mupen64Plus components. The excerpt does not document an upgrade procedure, rollback procedure, migration guide, or plugin compatibility policy. It also does not give a complete license statement. For an adoption decision, the first checks are the `LICENSES` directory, the selected build options, and the installation prefix relationship between the core, shared data, front-end, and dynamic loader.

Editorial conclusion

Mupen64Plus-Core fits developers who need the C core library and are prepared to provide compatible plugins and a front-end. It is not a standalone emulator for end users. Verify first that the required plugins, shared data, and installation paths match the rest of your Mupen64Plus installation, and confirm the applicable license from the LICENSES directory before redistribution.

Frequently asked questions

What is Mupen64Plus-Core used for?

It is the C core library for Mupen64Plus. The README says that a complete emulator also requires graphics, sound, input, and RSP plugins plus a front-end.

How do I build Mupen64Plus-Core from source?

Unpack the source distribution, enter its `projects/unix` directory, and run `make all`. The source build requires GNU C and C++ tools, GNU make, Nasm, development packages, SDL 2, libpng, freetype 2, and zlib.

Can I install Mupen64Plus-Core with a custom PREFIX?

For a source build, the README says to pass the same `PREFIX` when building and installing. Its example uses `make PREFIX=/usr all` followed by `sudo make PREFIX=/usr install`.

Does Mupen64Plus-Core include a complete Nintendo 64 emulator?

No. The repository description and README identify it as the core library only. A complete emulator also needs graphics, sound, input, and RSP plugins and a front-end.

What license applies to Mupen64Plus-Core?

The repository information does not identify the license. The repository includes a `LICENSES` directory, so the applicable terms need to be checked there before distribution or integration.

Official sources

  1. Issues
  2. mupen64plus/mupen64plus-core on GitHub
  3. README
  4. Releases
Add this badge to your README

If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.

Add this badge to your README

markdown
[![Hysen Labs](https://hysenlabs.com/badge/mupen64plus-mupen64plus-core.svg)](https://hysenlabs.com/projects/mupen64plus-mupen64plus-core)

Was this useful?