So, I have been neglecting the blog for quite a while. It’s time to rectify that with this huge blogpost on a problem that’s been constantly frustrating me even more than the issues with Dolphin’s ram search. Be warned; this blog post will be a bit more like a rant than usual because I’m literally at my wit’s end and have nothing more I can do but write about my issues and try to inform everyone else of the situation.

The subject of this rant? Nintendo 64 emulation. More precisely, the problem and pain that comes with trying to use them to research Nintendo 64 games.

It’s all about the state of the Nintendo 64 emulation: all its problems, all its pain to deal with and most importantly, how much of a problem it is to research Nintendo 64 games.

Previously on this blog…

Some of you might have read a previous post I made about the difficulties and usefulness of an emulator. This post gets into the details about what are emulators for and what they can do.

To summarize, an emulator is a software that simulates a hardware environment that is completely incompatible with the environment it is run on. For example, an Nintendo 64 emulator for PC allows you to play Nintendo 64 games on your PC because this program simulates it using several resources from your machine to recreate this environment as best as it can. As the game is running in a contained environment, a lot of neat use cases for emulators have popped up. They’ve become a way to more easily push games to their limits, with savestates and other features allowing for easier glitch hunting and tool assisted speedrunning. Emulators even make modding games easier because it’s much easier to poke at the internals of a game from within an emulator than on a closed system.

While this may all sound great, there’s actually a lot of hard decisions an emulator must make when targeting a system. Namely, how accurate is it trying to be and how fast can emulate the target system within that goal.

Essentially, the idea is that you can have the correct and accurate implementation which is more correct, but that will need a lot more computing power than if you approximated it “well enough” to just run the games. In newer emulators, it’s often a balancing act of trying to be accurate enough to run games correctly while having enough performance to run well on newer computers. Dolphin, a Wii/GameCube emulator, was used as an example to explain that even though it might seem like a weird choice at first, it’s always better to go for accuracy and have a certain balance with performance, enough so that modern PC can run most of the things relatively well while older ones might have problems. To quote myself from this post:

So, Dolphin has learned me a lesson, even though it’s a very hard decision and it would certainly seem like it’s not that beneficial, it is always always always better to have a high focus on accuracy. even on things that seems to not have much case, as long as it’s worth it performance wise and what it brings, as long as the question is asked, it’s always better than ignoring it and “just make it work”.

The reasoning behind that statement is that Dolphin is a project that has been through A LOT. It started as an experimental emulator that only ran at single digit framerates even on the most powerful of hardware, then expanded into to a much faster plugin based emulator (more on that later), before finally going open source in 2008 and COMPLETELY changing the vision of the project by dropping the plugins system. While they did continue to optimize, the project shifted from trying to be good enough to trying to be correct whenever possible.

Still, things weren’t all that great with Dolphin 3.0 when it released in 2011. This was 7 years ago and I remember I briefly used it and 3.5 which was released 6 months later. The experience basically sucked, audio was a garbled mess, and many games had severe issues. It just unpleasant to use in general.

But in 2018, not only has it improved, but it has improved at an outstanding rate. It’s hard to believe that just seven years ago it was a total mess. Not only can it boot pretty much any game, most games run extremely well, even very obscure games. On top of that, it supports many features that would have seemed like a pipe dream less than a decade ago.

One of the most impressive things that happened not too long ago was the support for the Wii shop channel shortly before it was scheduled to shutdown purchases. To even get there, you have to correctly emulate the internal Wii OS called IOS, you have to support updates as the shop will require it, you have to support internet connectivity by emulating the Wii and you even have to support a pretty decent chunk of the NAND features, and the list goes on.

At this point, Dolphin is known to be very widely compatible among the GameCube and Wii libraries, but under the hood it’s also gotten to be very good at emulating the hardware. Tons of crashes that occur on real hardware just work in Dolphin, which is absolutely invaluable to someone who is trying to reverse engineer games. While it’s great that a game works correctly when everything is going right, it’s even more assuring that the emulator does its job when things go wrong, too.

So, how in the world this project got THIS good in 7 years?

Focusing on accuracy

EVERYTHING that made this emulator a huge success has to do with the decisions they made much earlier on. Dropping the plugin system and removing hacks caused huge headaches for years, but we’re seeing it pay dividends in the modern times. A lot of the things they decided to emulate accurately may elicit a “wtf? Why are they even bothering with that?” but again and again, some game relied on a weird behavior. Usually, it’s not even a game they’re targeting to fix!

If you think about it, it’s pretty logical: If you are trying to simulate a hardware, the more you implement, the more that simulated hardware will be able to do. In fact, that is pretty much the DEFINITION of an emulator, its job is to simulate the hardware and act as the interface between your PC and the simulated environment. As computationally difficult as it might be, enough to require a modern PC, the existence of this project, its success and its history is a proof a good emulator should strive for this concept of being accurate, but acceptable performance wise for modern PC.

This is why I consider that a good emulator is an emulator that gets this trade-off between performance and accuracy right.

Ok, now that this reminder is done, let’s get back to the hardware we are interested in: the Nintendo 64

The Nintendo 64 emulation scene

Currently, they are three popular emulators in use for this console; Nemu64, Mupen64Plus and Project64. Unfortunately, before we get into the details of each one, we need to talk about one annoying trait that all three of them share: a plugin system.

Okay, what’s the deal with plugins and why does it seem like a bad thing?

A plugin based emulator is an emulator that instead of having all its modules integrated into one program, it’s an emulator that offers a plugin interface to several of its modules and it is the job of the different plugins to implement these modules. Common examples are audio plugins which implement the DSP (digital signal processing), video plugins which implements the GPU and video interface or an input plugins which implements the controller interface so that thing you would use to map your controllers and such.

This probably sounds great – it allows parts of the emulator to update and gives more people chances to contribute from outside of the project. While that’s true, these are clearly the not kinds of options you want in a good emulator.

The problem is, why would you want a plugin interface with multiple solutions when there is only one implementation in the original hardware. The Nintendo 64 only has one DSP, why you need to have a plugin interface if you can just implement it correctly? if anything it adds a unnecessary overhead because of the interface so why an emulator should ever have these? Even in the case of using plugins as a way to interface with different PC hardware is inefficient, as they can’t share as much common code. Dolphin’s backends have been moving toward a “videocommon” that allows the actual backends to get smaller and smaller to allow for higher performance and better support across operating systems. At least in these N64 emulators, the plugins can wildly vary in how they implement things.

And there lies the entire problem: plugins are much more headache than they’re worth. So why did so many emulators have a plugin system back in the day?

It apparently was a practice used back when open source emulation was much less of a thing. The emulator developers would document the plugin interface and would allow other people to write plugins that could implement parts of the emulator. Thus, both the emulator and plugins could be closed source as well.

All of this secrecy led to plugins that had wildly different issues and often had users trying different plugins for each game. This was a toxic situation for anyone that cared about accuracy and preservation. If you wanted to make a new video plugin and guarantee it gets used, you wouldn’t want to make an accurate one. All you had to do was make it do something better than another plugin. Whether that’s an enhancement, or a fix for a certain game (even at the cost of breaking others,) or adding support for a new API was up to the developer.

At the end of the day, N64 emulation was a total mess of users asking “which plugin should I use for x game.” If you browse old Nintendo 64 emulation sites, you can find dozens of plugins recommended for various computers or games.

Modern emulators like Dolphin will often implement different settings that handle a lot of what entirely different plugins did for N64. This meant all the user had to do was check a box to see if the game was having a problem, not have to go searching for a new video plugin that implemented something in a different manner!

This is part of how Dolphin handles its accuracy vs performance trade-off. There are a lot of settings that aren’t needed for most games but are there in case you need them. Some of them are more accurate, some of them act as hacks to handle behaviors that aren’t possible to correctly emulate yet, but, they’re all there in one cohesive product.

Choosing how the entirety of the video system is done is NOT an option that should exist and be presented to the user. Yet every popular N64 emulator still does, and it’s part of why N64 emulation is such a huge mess.

Unfortunately, the situation gets even worse if we consider each individual emulator. So let’s dig in and start with the oldest: Nemu64

Nemu64, one of the oldest, but still used emulators

Website (which definitely hasn’t aged well): http://nemu.emuunlim.org/

Let’s first start by saying this: this emulator’s first version was released in freaking 1998, which is only one year after the Nintendo 64’s release and its latest version was released…..in 2003!!!

When I heard this emulator was still in use today, especially because of its debugger, I was in shock, why would you ever use a 15 years old program that hasn’t been maintained for years when two modern emulators exist?

I had to find out, but kept my expectations tempered as I tried it. As expected… emulation quality wasn’t quite its strong point.

If your goal is accuracy, Nemu64 is pretty much useless. I will mention though, this emulator was never open sourced and as you can see from the menu bars, it does use a plugin system and came with this garbage video plugins that….seems to love putting blue in Mario Party 🙂

But, this emulator does have something that interests me and has been keeping it in use despite all of its flaws: a debugger.

Let me tell you this right now: this debugger has the WORST user interface I have ever encountered! This thing is basically unusable. It’s one of those cases where the only reason this thing gets any use is because there is no good alternative! Considering the Super Mario 64 and The Legend of Zelda: Ocarina of Time are among the most well-researched games and this was the main tool they had? It just makes it more impressive.

Let’s get into the problems. The main issue I noticed was the instruction list cannot be scrolled. They mandate that you click on the arrows on the top and bottom of the window. And guess what? They just so happen to be very sensitive.

When you’re dealing with items displayed in rolls, it just makes trying to sort through information a total pain in the ass. Add onto this that you’re dealing with a billion windows and the entire interface becomes a mess. You have a register viewer window, a ram viewer window (which cannot be scrolled at all – you have to search by address!), the ram search window (which lacks important filters), the instruction list window, the bookmark window, and the symbols window. This would be a lot easier to use as panels in a GUI instead of being split off like this. Take a look for yourself!

With all of that disappointment out of the way, let’s talk about Mupen64Plus

Mupen64Plus, doesn’t have a debugger 😦

Website: https://mupen64plus.org/ Github: https://github.com/mupen64plus/mupen64plus-core

This is the only popular N64 emulator that natively runs on Linux. If you’re on Linux and want to debug N64 games? Look elsewhere, Mupen64Plus lacks a debugger!

It also has some familiar flaws we went through with Nemu64, like featuring a prominent plugin system, per-game hacks, but none of that matters when I don’t have a debugger to use. While you can get some of the functionality you need from MHS or Cheat Engine, you’ll still be lacking essential information without a debugger.

But, it’s not all bad with Mupen64Plus. This emulator is a bit less offensive when it comes the whole accuracy vs performance trade-off. And, it was one of the first open sourced N64 emulators, beating Project 64 by around five years.

Thanks to being open source alternative with decent compatibility, in 2013 Mupen64Plus was integrated into Bizhawk. Bizhawk is a TAS tools wrapper that makes Tool Assisted Superplays/Speedruns easier to create. There are also many third party front-ends for Mupen64 which can make it easier to use. And it’s a good thing they exist, Mupen64Plus is normally run from terminal/command prompt without one!

Despite the hitches if you manage to get Mupen64Plus set up, emulation quality is decent enough that you won’t be too upset. Compatibility isn’t perfect, but performance is more than good enough on modern computers. Unfortunately, without a debugger, I personally didn’t have much use for Mupen64Plus.

That leaves us with one more major option…

Project 64, the most used Nintendo 64 emulator

Website: https://www.pj64-emu.com/ Github: https://github.com/project64/project64

Project 64 is yet another plugin based Nintendo 64 emulator.

What separates Project 64 from the rest is that this one caught on like fire. When you see someone talking about N64 emulation, most of the time they’ll be talking about Project 64. Despite being the most popular, Project 64 has tons of longtime issues that have prevented it from standing alongside some of the popular emulators from other consoles.

How we got from Project 64 1.4 to 2.3

Like a lot of emulators from this time period, Project 64 started out as a closed-source project with a plugin system. Considering other projects that came after Project 64 very closely mimicked the plugin system and look, you must understand that Project 64 was very influential.

Unfortunately, it’s actually somewhat difficult to see what happened in the ancient Project 64 scene before version 1.4. That particular version is special because the source code was leaked and has since been modified for specialized tasks by others.

The eventual longtime standard for emulation would actually be Project 64 1.6, which is a common version of Project 64 you’ll see still recommended on many sites. If you used an N64 emulator on Windows from the late 2000s to early 2010s, it was probably Project 64 1.6!

Project 64 1.6 is considered the most accurate version of Project 64 by some speedrunning communities, too. This is because the timings are a lot closer to hardware than other releases, even if it’s missing some features in other parts of emulation. When Project 64 1.6 was released, N64 emulation seemed as though it was reaching a golden age… and then it suddenly stopped.

The Lost Version and the Transition to Open Source

A buy-in beta test program was setup for Project 64 1.7 which promised to improve upon the already popular Project 64 1.6. But, the project suddenly stalled and everything went silent. While some copies of it are still floating around out there, for the most part the emulator’s development went silent.

Out of nowhere in 2013, Project 64 2.0 suddenly released! It was huge news – it was going open source and after five years of development, it have to be good, right? Except, Project 64 2.0 is widely considered much inferior to Project 64 1.6. While some of the issues have been fixed since 2.0, the 2.x line still has a lot of downsides.

One of the things you’ll notice if you boot up a game that lags is that it won’t lag nearly as much on Project 64 2.0. A general user may think this is a great thing, but Project 64 already had less in-game lag than console! So by having even less, it’s actually going in the wrong direction. For a general user, better framerate may just seem better, but for those of us trying to reverse-engineer and research games through emulation, the emulator correctly emulating the console is important.

For this articles purposes, I’ll be looking at the latest version of the emulator available: Project 64 2.3.2, released in 2017.

Diving into Project 64

At first impression, things seem maintained pretty well. Still, there are a lot of oddities to take into account. It’s still 32-bit. A lot of modern emulators take advantage of 64-bit for better performance, particularly those with recompilers. Compared to modern emulators, Project 64 is so lightweight that it probably doesn’t matter on PCs, but it is worth noting as other emulators jumped aboard 64-bit long ago to grab optimizations.

A much bigger red flag is that Project 64 is still Windows only! The weird thing is that most of the core actually compiles in Linux already. The only step required once the rest of the core becomes platform agnostic would be to do a front-end which considering an emulator core, this should be trivial to do, or, heck, they could just make it work via terminal in the meantime.

On the plugin side of things, most of them can be compiled in Linux as well. As an added bonus, because Mupen64Plus uses a similar plugin system as Project 64, many of the plugins that are offered for Project 64 are also offered for Mupen64Plus. While this may sound insignificant, it does offer more options to get the best emulation experience possible.

Okay, but does it work for game research?

If Project 64 had a good debugger, I would be a bit more optimistic. And while there is a way to use a debugger with Project 64, like with just about everything with N64 emulation, we’re going to be jumping through some hoops first. That’s right, Project 64 itself doesn’t have enough debugging capabilities, instead we have to rely on a fork that adds a much, much comparatively better debugger called, [PJ64d](http://shygoo.net/pj64d/). EDIT: This apparently changed and I wasn’t aware of it, it seems the work on PJ64d has been merged into PJ64 so the fork isn’t necessary.



There are still a lot of annoyances with this. Wine is a no-go, so I had to use a Windows 10 virtual machine to get things running. The actual task I chose was a simple one: figure out the RNG algorithm in Mario Party and it’s seed address. This is a good basic test because it involves backtracing memory accesses, reading assembly, breakpointing and searching memory.

So the debugger is technically usable, but boy is it a painful process. The UI is nowhere near as bad as Nemu64, but it still has way too many windows that you’re forced to keep an eye on. The debugger is good enough that dedicated game researchers have managed to break apart entire games like this, such as Super Mario 64, and The Legend of Zelda: Ocarina of Time. All of that with emulation tools that’d be substandard in almost any other community.

Compared to using something like Dolphin’s sometimes touchy debugger, trying to research any N64 game is many levels harder.

All in all, this is the situation

While Project 64 is the king of Nintendo 64 emulation, it is the king of a messy kingdom with no clear direction. While the rest of emulation has moved onto bigger and better designs, it clings to an ancient plugin system and other design decisions from a bygone era.

For someone who cares just about emulation quality, reverse engineering, and game research, you’re just left with no great options. Even PJ64d, the only usable option, was much worse than debuggers available in newer and more experimental emulators. While I’d love to start documenting behaviors in Nintendo 64 games, the tools just aren’t there.

While emulation is an incredibly difficult task, it’s hard not to compare Nintendo 64 emulation efforts. Given that the Nintendo 64 is such a popular console (especially within emulation circles,) it’s hard to believe that it was left behind. We have later consoles with more fully featured emulators and brighter futures.

Project 64 sputtering doesn’t spell the end for Nintendo 64 emulation, though. We can actually look to Dolphin (GameCube/Wii) for inspiration on how an emulator can retool itself for new goals later in development.

Like many emulators before it, Dolphin started closed source with a plugin system. They stuck with that for just five years before going open source in 2008 and ripping out the plugin system soon after. Just going open source didn’t fix their problems though, the emulator itself had to go through a change in philosophy. It really wasn’t until Dolphin 4.0 (released 2013) that Dolphin started to look like what it does today.

Throughout Five long years, Dolphin went through a metamorphosis from experimental emulator into an emulator where the primary goal was correct emulation. Dolphin is an unfortunately rare exception for emulators though, so it’s not entirely fair to expect that from Project 64. We can look at some other examples for options.

Citra is a currently experimental 3DS emulator that took roughly a year to start booting its first game; The Legend of Zelda: Ocarina of Time 3D. Since then it’s marched forward with huge leaps in compatibility, optimizations and various hacks for performance. Still, the core of the emulator is fairly accurate and it seems to have a bright future ahead of it.

We still don’t know the ending to Citra’s story, so it isn’t a perfect example. A more complete example is bsnes, or as it’s known nowadays as the SNES core within Higan by Byuu. As the name probably gave away, bsnes/Higan is a SNES emulator a very clear goal: accuracy above all else. It’s trying to perfectly preserve the Super Nintendo Entertainment System within software. As far as I know, Higan has been under development for a little more than a decade, but managed to make its name against more established SNES emulators by focusing on cycle accuracy. Because cycle accuracy timings are so expensive to emulate, this greatly increases the requirements to run Higan. But, given a strong enough computer, Higan will give you as close to perfect SNES emulation as possible.

Last example, mGBA, a GBA/GB emulator by endrift. Despite going up against the much more established emulator, VBA-M, endrift’s mGBA ended up making a name for itself with accurate emulation and better emulation of niche features. The more impressive part is that endrift managed to pull this off in just a couple of years.

Throughout all of those emulation communities, we see an old emulator retool itself for modern needs or a new emulator usurp it. Nintendo 64 emulation saw neither – the core emulation hasn’t drastically improved in nearly a decade. After seeing all of these other examples, the question quickly becomes Why?

My assertion is that the plugin system is at least partially to blame. Again and again, efforts to work on Project 64 have been segmented. You can find dozens of video plugins, dozens of audio plugins, tons of input plugins, and even plugins that can do things like netplay. But guess what? All of that work, and it does nothing toward the core of the emulator. In order to make its change, Dolphin had to make a very concerted effort toward going in the way of accuracy.

For all the good that plugins once did, they’re a relic of an outdated and inefficient way to develop emulators.

But what about GLideN64?

GLideN64 is an interesting case that honestly could have a full article going into its history. In a way, it’s the “bsnes” to Glide64’s “zsnes”. It was announced by the creator of Glide64 as a complete rewrite from the ground up. To put things in perspective, Glide64 was the best graphics plugin for N64 emulators for years despite needing a wrapper to OpenGL on modern graphics cards. GLideN64 was crowdfunded to be an accurate HLE Nintendo 64 graphics plugin. Among its promises were perfect framebuffer emulation for special effects, which, they actually delivered on!

Unlike its predecessor, GLideN64 is open source and it works on all three of the emulators above. This is great news right? Among the sea of mediocrity we finally have a shining beacon.

…Nope. Developers can’t even agree to use it as a default. The reasons for it are dubious at best. Like an old dinosaur stuck in the past, it seems as though the community is afraid of alienating users by using a plugin that requires modern OpenGL features. It sounds like an easy solution – include the less accurate, older plugins for those who can’t use the correct plugin. But no, that’d be too easy.

While GlideN64 is really good I dislike it using so much cutting edge open gl features, prefer greater compatibility and using the lowest possible specs.

….WHAT?

This further cements that the plugin system is bad for emulators. Project 64 reaps the benefits of being able to use GLideN64 while not improving itself in any meaningful way internally. Instead of a better core, we end up with a better dressing.

Dolphin, Citra, Higan, mGBA and many other emulators have made sacrifices to get where they are. If you go through Dolphin’s blog, you’ll see obituaries on features like the x86-32 JIT and D3D9 simply because they were holding back parts of the core. And it’s not like Dolphin is ridiculously demanding – my GTX 950, an average gaming graphics card nowadays, works fine in Dolphin and supports every feature it needs.

If it was just one bad decision here and there, I could look past it. Every project makes mistakes. It just seems like Project 64 in particular has habitually made decisions that have repeatedly stagnated the N64 emulation community.

Dubious Motivation

You know what emulators tend to need? Testing, lots of testing. Games are usually closed boxes and you don’t know what features they’ll need or use unless you run into them. So what did Project 64 do in the lead up to the (failed) Project 64 1.7 release? A paid beta program, of course! Greatly limiting the amount of people testing your product isn’t a terrible idea at all, right?

After that failed miserably, Project 64 launched a Patreon. While I’ll let you draw your own conclusions, those decisions don’t exactly seem to be about improving emulation.

Do not take this the wrong way, using emulation as a way to make money isn’t inherently bad. But it does change the dynamics quite a bit. If you need more users to fund the project, you’d probably be better served getting the popular games working best and making quick hacks so that more people can run those games while sacrificing overall accuracy in the process. I personally recommend you read this article if you’re curious about the subject.

A lot of emulators have patreons nowadays. And while there are concerns of it affecting development in adverse ways, that doesn’t mean it has to. More money can lead to more time to develop, better unit testing, better buildbots, a better website and more! mGBA has a patreon while keeping its main calling as being an accurate GBA emulator.

How Project 64 treats donations and the Patreon again separates it from other projects, and not in a good way. Some emulators put Patreon links on their sites, at the end of blog articles, or even in the about box. Project 64 takes it a step further and has a pop-up when you close the emulator that lasts longer the more you use the emulator. It forces you to wait until it decides to close the emulator.

The irony is that the people supporting Project 64’s Patreon are against this behavior. I can’t say for sure what the motivation behind the pop-up was, but I can say this. It’s really a bad sign for the project that the this pop-up managed to get into a release. Where’s the voice of reason saying, “Hey, maybe this is a bad idea”?

I was baffled that the N64 emulation community was left in this state while putting together this write-up, and actually decided to dive a bit deeper to try and figure out what happened.

Diving into the N64 Development Community

In search of answers, I went diving through the back channels of Efnet. Deep within the old IRC network were some of the original IRC channels where N64 development was discussed. They talk here about reverse engineering the hardware, documented behaviors, etc. This was the place people went when talking about the gritty details of how the Nintendo 64 worked.

While not everything has been reverse engineered, a lot has been done and the hardware is fairly well understood. It’s not the perfect situation, but, definitely not the culprit for how Nintendo 64 emulation became this way. In fact, there was recently work to make accurate 64DD emulation more accessible. The 64DD is a disk drive device that can be attached to the Nintendo 64. Thanks to his work, this was implemented into Project 64, adding compatibility to several very rare and hard to find games that very few people would have ever gotten the chance to play on console.

After spending some time around the reverse engineers, the state of Project 64 just confuses me further. I thought that maybe Nintendo 64 emulation was so sketchy because there wasn’t that much documentation. But I found the opposite, the Nintendo 64 is actually documented fairly well! The problem more squarely falls onto the side of the emulators and particularly the people maintaining those emulators. Through mismanagement, infighting, and poor decisions, they managed stagnate the scene to the point where it’s considered a black sheep among emulated consoles.

My dreams of reverse engineering games like Mario Party 1 – 3 are put on hold for now because of this mess. I would love to do it, but, I’m not going to even try it when I hated myself just trying to find a basic RNG function.

However….. even if Project 64 can’t dig its way out of this mess, there is a small glimmer of hope on the far horizon. Let me introduce to what I think is the project that has the potential to solve EVERY of the problem I had: cen64

cen64: a Nintendo 64 emulator that tries to be cycle accurate

Website: https://cen64.com/ Github: https://github.com/tj90241/cen64

As I alluded to before, I said there was no complete emulator that eschewed the bad decisions I mentioned. I didn’t want to mention it earlier because cen64 is very experimental and a lot of stuff doesn’t work yet. In fact, marathonman, the author, announced a complete rewrite of the emulator because he was not satisfied with the interpreter design which seems fair, you can only go so far with an interpreter.

But look at this! It’s open source, can be compiled under Windows and Linux and eschews the annoying plugin system?! Consider me interested! Add onto this that it’s also cycle accurate and all we need is a good debugger and all of my problems are solved!

There’s always a “but,” with the perfect solution, and cen64 is no exception. In this case, cen64 is taking a long time and has little support thanks to most users being happy with Project 64. Maybe that means years, maybe a decade, or maybe even longer. Sometimes, that’s just part of the struggle of being an accurate emulator. mGBA initially had the same issues trying to separate itself from VBA-M, but, finally did when games and features that didn’t work on VBA-M only worked on mGBA. Same thing for Higan against SNES9x and ZSNES. Hopefully, in a few years we’ll be talking about cen64. Maybe the tipping point will be when cen64’s JIT drops and we finally see what it can do at full-speed on today’s computers.

The only way we can help is to raise awareness that a real solution to Nintendo 64 emulation exists. Share it so more people are aware of this mess and remind people who do know about it that cen64 exists and that it would solve pretty much everything if it succeed so that more people knows about it and encourage its success. I do know if it gets to the point where it does everything needs work on a debugger, if I can, I plan to contribute to the best of my ability!

With that, I would like to end with a comment from JMC4789, a Dolphin contributor. You may have heard his names previously on this blog when I talked about the Force 20 glitch in Gotcha force as he brought it to my attention. Well, he also shares similar opinions with me about the Nintendo 64 emulation scene so without further ado, here’s how he sees it from a user perspective:

JMC4789’s thoughts on the Nintendo 64 emulation

While most of this article was written from the perspective of someone that is using emulation for game research, N64 emulators also leave a lot to be desired if you’re a general user. I grew up on Nintendo 64 emulation, I’’ve used Mupen64, Project 64, Nemu 64 and probably 30 or 40 different plugins over the years. I had to deal with problems like minigames rendering incorrectly in Mario Party 2, minigames crashing in Mario Party 3, Mario Tennis being a total disaster. By now, a lot of this is fixed and hopefully you’ll have a pain free experience in these games. By far the best experience I had with any N64 emulator was playing through Super Mario 64: Star Road. As someone who considers Super Mario 64 one of the best games ever designed, it goes without saying that I didn’t have much in the way of hopes for a romhack to recapture that magic. Instead I ended up enjoying it a lot (it was my favorite game of that year), even when I was looking for reasons to criticize it. Part of it was a good emulation experience, if Project 64 had given me headaches, there’s a good chance it would have played into the expectation that I was just playing a shoddy romhack. While emulation is slowly improving, N64 emulators are still heavily flawed for a lot of games, especially if you desire any semblance of accuracy. When speedrunning Mega Man 64, I ran into no shortages of crashes, outright blue screens (this particular bug was fixed recently, though!) and really awful emulation in general. Texture seams everywhere, missing effects, and the inability to emulate the game’s frameskip, causing it to run in *slow motion* whenever there is anything on screen! Emulation was completely useless at getting any kind of viable practice for the Nintendo 64 version. Meanwhile, back when I ran on the Playstation version, I had no less than five emulators I could choose from and instead of worrying about correct features, I was looking at things like savestates, disc timings, and other bonuses. The basic emulation was just a given to work! Even on a problematic title like The Misadventures of Tron Bonne, you could look to more accurate offerings like Xebra even when the more general purpose emulators didn’’t work. Having done speedruns on several PSX and N64 titles, emulation is infinitely more useful when running on PSX emulators because you get an experience pretty close to the console. That’s not to say N64 emulators are useless or that everyone working on N64 emulators is incompetent. The N64 is a tricky beast and there’s been tons of little things that talented people have emulated. I never thought I’d see 64DD emulation, and I’m absolutely thrilled that it exists. Nintendo 64 emulation is mostly good enough for general users if you do your research and know what plugins to use. Better plugins nowadays makes that easier than ever. Like Aldelaro, I too am hoping that cen64 (or one of the current N64 emulators) can lead us into a new era of Nintendo 64 emulation with a greater focus on a cohesive (pluginless) experience that strives for pushing things forward rather than patching up the present.

Special thanks

I would like to thank JMC4789 for not only the section above, but also because he agreed to work with me as an editor on this post. It was nice to work on this post together as we both want changes in how Nintendo 64 emulation are done and we both hope that cen64 succeed in its promises and I think the post turned out very well. He also has a blog specifically about emulation too called emulation-cross which I recommend you check out if you are interested in more emulation talks like this one.