Since January 2025, I no longer associate with SM64 romhacks or anything related. This page and emu are therefore not currently maintained. ~ShiN3

A legacy to Be Forgotten

A manifest against Project64 1.6 and its derivatives.

Unlike others may, I will not claim to be an expert on any of the topics at hand.

I simply am someone who has been in the realm of Nintendo 64 emulation for over a decade, and who has come across enough grievances that I became motivated to do something to solvent the worst of them.

One of these grievances in recent times has been the small group of people who have kept insisting on being diehard Project64 1.6 fans. I have seen my own share of developers, including myself, constantly express their frustration at the existence of Project64 1.6 users that they'd have to deal with.

We have concluded, time and time again, for a myriad of different reasons, that people should stop using Project64 1.6 and swap it out for a different emulator, as staying in Project64 1.6 provides no benefit whatsoever over using newer emulators.

But to understand why we believe that Project64 1.6 should be left to die, we must first answer a different question:

Why do people use Project64 1.6?

The answer to this question isn't a simple topic, but it can be divided into three main points that are interconnected with eachother:

1.1. Certain games' speedrun rulesets

Some games, to this day, require Project64 1.6 for speedruns.

For example:

Vanilla Super Mario 64's only allowed Project64 version, and the emulator that is recommended to many people when they want to speedrun the game, is 1.6.
Ocarina of Time only allows Project64 1.6 and 1.7.
Mario Kart 64 technically allows every version, but their speedrun.com ruleset encourages the use of Project64 1.6.

This makes it so that when people download Project64 1.6 to speedrun certain games, they will keep using it when playing other games where it is more harmful than good to do so.

But why is Project64 1.6 the emulator that is encouraged by speedrun communities in the first place?

1.2. The disaster of newer official Project64 releases

Every official Project64 version released after 1.6 has had at least one major flaw, which has consistently led the different communities to stay away from them:

Project64 1.7 was a closed beta of 2.0 that people could only access by paying for it.
As such, the only versions available online today are leaked builds, which may vary from eachother in specifics.
Project64 2.0 set the default VI Refresh Rate to 2200 rather than 1500, which is an inaccurate overclock setting that makes certain load times faster than 1.6.
While this is perfectly fine for emulators that are primarily aimed at SM64 romhacks to do (such as Luna's Project64 and ParaLLEl Launcher), that's not so much the case for vanilla Project64 where accuracy actually matters and developers aren't going out of their way to adjust specific games' settings to match their corresponding speedrun rules.

These two versions were enough to keep some communities away from all newer releases, but unfortunately the issues don't stop there:

Project64 2.1 added massive lag spikes on every EEPROM write. This makes it significantly slower and more annoying to use.
Additionally, 8MB memory size must be set for each individual ROM that is opened, adding an unnecessary extra step to playing any game.
Project64 2.2 inadvertently hosted its installer on a website that added malware to every file that it hosted.
Project64 2.3 introduced a nagware window that makes you wait for 30 seconds every time you open the emulator unless you pay the developers to get a key that you can input.
Additionally, this release broke many SM64 romhacks. Most decomp hacks won't run at all, and certain binary hacks have issues with it too, such as Super Mario Star Road having an unavoidable game crash.
It is worth noting that although some people claim that me using the word "nagware" is disrespectful to the Project64 developers, the fact that their own source code refers to it as a "nag window" voids that argument.
Project64 3.0 would've been a great release, since it fixed the issues that 2.3 had with romhacks, but it unfortunately keeps the nagware window, and even doubles down on it by making the codes to remove it machine specific and therefore harder to bypass.

The only version that has been spared from this breakdown is 2.4.
It's a series of beta builds of 3.0, and while some of them have issues, there is a certain version that was used by a minority of SM64 romhack players for a while that had most of 3.0's features, but with no nagware window, although unfortunately this version didn't work on Wine.
Also unfortunately, by the time that this version's potential was found, the damage caused by the other versions was already done, and people were, at best, highly skeptical of any newer builds.

1.3. The wish for a stable emulator

Ultimately though, most people just want to play the game and don't have time for the history lesson that my previous two points are telling.

They just want an emulator that won't break and that will work decently for just about anything that they throw at it, and that they won't have to constantly replace with something else.

I will admit that, perhaps 3 years ago, that was a valid wish. Those were valid concerns. So, what's different now?

2. The rise of actually good emulators

On late 2021, Rosalie's Mupen GUI was created, and would eventually be adopted by the vanilla SM64 speedrun community despite it being faster than 1.6. Soon afterwards, ParaLLEl Launcher was first released, which for the first time, natively provided legacy SM64 romhack support in a newer emulator.

These Mupen based alternatives reasonably didn't sit well with everyone, however.
There are notable downsides in terms of both features and performance, and so despite the repeated pushes for people to switch to them, the need for a proper Project64 version remained.
Since there are valid reasons for people to avoid them, we may ignore them for the purposes of this page.

On early 2023, Project64 3.0.1-N-v1 was released, and it would eventually evolve into what we know today as Luna's Project64.
As of today, I am confident in saying that Luna's Project64 is superior to 1.6 as we knew it a few years ago, and the recent developments in 1.6's history have only made it worse for 1.6 itself.

2.1. Addressing expired promises

To prove why Project64 1.6 is unnecessary as of today, we may start by addressing the above points on why 1.6 is used in the first place.

2.1.1. Solving the newer Project64's disaster

As stated earlier, there was one Project64 version that was spared from the general mess that the other versions had caused, namely Project64 2.4, but unfortunately this version doesn't run on Wine, so Linux users would be left behind if that was picked as a standard.

Instead, the logical step forward is to take a release that is open source and completely fine except for one issue, and simply remove that issue. That being, the nagware screen in 3.0.

Just like that, we end up with a Project64 version that has lots of additional features and nearly no drawbacks when compared to 1.6, and we can iron out these small "drawbacks" (which are mostly just differences based on preference) as we develop the emu further.

2.1.2. Speedrun viability

The differences in timings between Project64 1.6 and 3.0 are a matter that isn't fully determined yet as a whole.

However, a bunch of tests that have been carried out lead to the following conclusions:

Load times are fully consistent between 1.6 and 3.0, and also accurate to console.
Project64 1.6 runs SM64 roughly at 29.99fps, while 3.0 runs it at roughly 29.97fps, making the latter slightly slower, and so it won't give people who use it an unfair advantage. This difference is believed to be consistent in games with other framerate values, like 20 or 60 rather than 30.
Certain more specific cases, such as pauses in Ocarina of Time, may depend on the graphical settings being used, and therefore more information about what is and isn't allowed under the current rulesets is required to verify that things line up.

Additionally, Luna's Project64 intends to help speedrunning communities implement and force enable the settings that are required by their own rulesets, and potentially develop anticheat methods, none of which is possible when using the original Project64 1.6.

As such, there is unlikely to be any good reason to allow Project64 1.6 but not Luna's Project64 in any given game.

2.1.3. The true meaning of stability

A couple years ago we may have been fine with something that worked decently in a sea of builds that don't work at all, but nowadays, we can do better.

People who pick up Project64 1.6 with default settings will be taken straight into using the 3 Jabo plugins, and each one of them comes with its own set of issues.

We used to live in a world where many people's PCs weren't powerful enough to run anything beyond Jabo's Direct3D8, a very inaccurate plugin that doesn't even work as intended anymore due to discrete GPUs' deprecation of DirectX 8, and furthermore, people with actually good PCs were often "punished" for running more accurate plugins due to old SM64 romhacks' quirks that required Jabo to work.
But now we have advanced decomp projects that rely on console accuracy in order to work. Jabo simply won't run these games as intended or expected, and there's no way to account for that as a developer, since Jabo graphics isn't open source.
Developers who want their romhacks to work at all on Jabo are often left having to take guesses on what will and won't work, and it's a terrible experience for everyone.
Thankfully, we have ANGLE GLideN64, which takes the accuracy of the original GLideN64, improves on performance like there's no tomorrow, and adds certain legacy patches to support old SM64 romhacks.
Luna's Project64 uses ANGLE GLideN64 by default, and even though that plugin works on 1.6, most people won't know to download it and put it in.

Jabo's DirectAudio was never even good in the first place. It was full of crackling and sync issues, and unlike Jabo graphics, its performance was abysmal.
If you're a new 1.6 user, you're going to be left wondering what the best audio plugin is, and even risk running into Shunyuan audio which has a setting to unlimit FPS during loads that will therefore invalidate your speedruns if used.
Luna's Project64 uses LINK Azimer's Audio, which works great besides a minor issue that some people experience due to the messy state of Windows drivers.

Jabo's DirectInput7 is usable, it has basic 1 to 1 mapping from controller or keyboard to ingame inputs, but there's no good reason to use it when you have the wide array of better input plugins that we have to offer nowadays.
This will become even clearer when Luna's SDL Input is finished, since we will have a plugin that works with just about every controller and keyboard out there, has additional features, stick calibration, etc

3.0 allows you to change the emulator's keyboard shortcuts (and controller support is planned for Luna), 1.6 doesn't.
3.0/Luna has been given many source code and compilation based performance improvements that 1.6 lacks.
3.0 has a debugger. 1.6 doesn't, unless you count the very basic one you may randomly come across when you crash the game while using interpreter core. Which I personally don't.
3.0 has an entire JS scripting feature that I discovered a few days ago, 1.6 doesn't.

3.0 works nearly flawlessly on Wine, rivalling emulators that have native Linux builds. 1.6 doesn't.

With Nintendo 64 emulation, we live in an environment that is constantly changing. We have recently seen new developments such as the use of SD card emulation and F3DEX3, and as such, the solutions that have worked for lots of years will end up falling apart at some point.
In order to keep an emulator stable, minimal updates to support the latest new things and bring improvements to user experience are necessary.

3. So why not update 1.6?

As I have previously stated, one of the main "selling" points of Project64 1.6 was the fact that it never changes.
Even just for that reason, changing it would defeat the whole point of using 1.6 in the first place.

So if we're at the point where we're willing to change things, why shouldn't we build our castle on a better foundation?

We happen to have the story of those who didn't do that and who set an example of what you shouldn't do, as will be told by my next point.

4. The downfall of Project64 1.6

On January 2nd 2024, the SM64 romhack "Mystery of Purple Switch" was released, showcasing a vulnerability found in Project64 1.6 that allows malicious ROMs to execute arbitrary code on your PC.
This was a massive security flaw that was announced as such in several major N64 servers, and people were urged to switch to a different emulator as soon as possible.

This served as a catalyst for many different events to occur, including but not limited to the development of Project64 Legacy and Project64 Plus by a team of people that included some of the original Project64 1.6 developers.

At first, a group was put together as an attempt to establish a collaboration between the developers of Project64 Legacy and Luna's Project64, but the idea was discarded due to a difference of goals, as well as unwarranted hostility from some of Project64 Legacy's developers.

Project64 Legacy would go on to fix the arbitrary code exploit and have several releases, named Project64 1.6.2, 1.6.3 and 1.6.4.
Project64 Plus came after that, and they still insist on referring to themselves as Project64 1.6.
If the idea of building on Project64 1.6 wasn't bad enough, they decided to market themselves in an unnecessarily confusing way that could easily mislead people into downloading the original vulnerable Project64 1.6.

Accuracy has never been a concern or a goal in either of these forks, so the same issues that used to haunt romhack developers are all still there (with the exception of the TEQ crash).

And yet somehow, Project64 Plus seems, perhaps, even more problematic.

4.1. Concerns about Project64 Plus's claims and community

When I look at the Project64 Plus GitHub repository, the two words that show up in my mind are "dread" and "incompetence". It's the utter pinnacle of people who pretend that they know what they're doing and look like they know what they're doing, unless you have literally any knowledge about how romhacks work.

One of the first things you see when you look at the readme file is the following sentence:

"It is targeted at the communities that still desire to use 1.6's ability to play Rom Hacks and a-like because of an incorect core that lets a lot of things slide when it comes to compatibility."

Yes, those spelling mistakes are in the readme, but let's not judge someone who may be foreign or dyslexic... even though they have an entire group of people and access to autocorrect tools to proofread and spellcheck.

Let's instead judge the claim that 1.6 has an "incorrect core" that has the exclusive ability to play romhacks.
Because that's an utter lie.

Older romhacks tend to have issues with accurate graphics plugins as they were built with Jabo graphics in mind, and that is no longer an issue thanks to ANGLE GLideN64. And yet, there isn't a single romhack out there that requires Project64 1.6.
Every romhack that works on Project64 1.6 will also work on Luna's Project64, and there are currently no known exceptions to this statement.

Given that claim, and the general lack of interactions between the developers of Project64 Plus and the SM64 romhacking community, it seems like the players' best interests aren't being considered.

That being said, there is a specific member of that team who has actually interacted with our community at a certain point, so let's talk about how that went.

4.2. Bruce Shankle IV

I shall preface this section by saying that I have looked into Bruce Shankle's recent GitHub history related to N64 emulation, and the literal first two things I found were... very interesting.

The first one was a fork of ANGLE GLideN64 where he changed many of the default settings. The first setting I immediately looked at enabling framebuffer emulation.
ANGLE GLideN64 is a plugin designed for SM64 romhacks, and in that context, enabling framebuffer emulation will do nothing other than adding 2 frames of input delay and breaking compatibility with old romhacks.

The second was a commit to Project64 Plus improperly done from mobile updating the .cht file that had to immediately be reverted.

Needless to say, the fact that someone that is making those sorts of changes is part of the team further extends my concerns regarding the team's apparent incompetence and disregard for the community's needs and wishes.

Bruce Shankle has also recently reached out to an SM64 romhack community moderator asking for a public announcement to be made on how Project64 1.6's vulnerability was fixed. This won't be done because:

It would be misleading and may lead people to believe that the original Project64 1.6 is safe now
The romhack community in general does not want Project64 1.6 to come back in any way due to the inaccuracies found in it.

Ultimately though, nothing is as concerning as the fact that, in the last several months, Bruce Shankle has repeatedly and unjustifiably spread false pedophilia allegations against several community members, which even lead to one of the most loved SM64 romhack creators essentially being bullied off of the internet.

Even if the emulator was good and addressed the community's needs, which it seems to have no chance of doing, we wouldn't want our community to promote a project that such a person is involved with.

5. What should you do about this?

As with any piece of drama, it's always best to avoid harassing or otherwise interacting with the people involved.

Don't go around attacking 1.6 users either or annoying them to get them to stop using it. It's ultimately up to them to do so.

Simply switch to Luna's Project64, as you will get a better gameplay experience than with any 1.6 variant, and move on.
You'll be doing a favor both to yourself and to romhack creators.

~N3

Page updated

Google Sites

Report abuse