Just wondering if it is a known issue that Banjo Tooie can crash randomly? When it happens the sound continues but the image freezez and nothing happens when i push a button. It has happened twice in about 3 hours so far. Doesnt happen with other games. I run everything in native res and with dithering on. No “graphics enhancements”. I use “parallel” for gfx plugin and rsp plugin.
I have a i7 8700k Gtx 1080ti 16gb ram No bluetooth headphones
Try it with Mupen64Plus-Next. ParaLLEl-N64 is outdated and more inaccurate, so you shouldn’t use it unless you need the extra speed, which you shouldn’t considering your specs.
What isnt it the other way around? Well guess ill try it mupen then
You’d think so, but no, Mupen64Plus-Next is newer and closer to upstream. It still has access to the ParaLLEl plugins, as well as GLideN64, which ParaLLEl-N64 does not.
Thank you. Iam now running tooie with mupen64 plus next and angrylion as rdp. Looks as good as before and no crashes so far!
The old Parallel core needs a name change. Its too confusing and and a lot of people use it thinking it’s the correct one. And every time someone has to post “use mupen64 plus-next with Parallel RDP/RSP core options instead” which is a mouthful.
Im not sure why the old Parallel still exists at all. It has the old Glide plugin (not GlideN) and some other ancient ones like Rise. These plugins were already obsolete since the Pentium 4 days. If your system is so old that you absolutely need to use such thing then maybe it’s best to not bother emulating the N64 at all.
I remember when Parallel came and was a big thing when it came to accuracy. So its actually not a good N64 emulator anymore? Compared to more recent mupen?
When the Parallel core was released, the big deal was it’s own Parallel RDP graphics plugin, so it was named after that. It’s still “Mupen” though, it’s not a new emulation core. But the Mupen core it’s based on was not up to date, even when it was released i think it was behind. And then, the core was pretty much abandoned pretty fast and all the hype was fizzled out.
After a while, Mupen64pls-Next was released, which had an up to date Mupen core and the latest GlideN64 (not Glide, notice the “N” in the name) fixes. But some time later, this core also got the Parallel RDP/RSP plugins and that re-ignited the hype of accurate gfx emulation of the N64. The Parallel plugins were also improved greatly, even adding upscaling for it.
So now, the Mupen64plus-next core has an up-to-date Mupen core, GlideN64 and Parallel RDP/RSP plugins. It’s the only core that matters.
The Parallel core still has an out of date Mupen core and doesn’t have GlideN64 at all. It has Glide64, Rice and gl64, all 3 plugins were considered dead long before the core was introduced. I mean, GlideN64 was the continuation of the old Glide64 project and it was meant to completely replace it as the later stopped being worked on (that was 15 years ago or something). The Parallel RDP/RSP seems to be up-to-date, i’m not really sure, but even if it is, why use it with an out-of-date Mupen core?
So, all of that mess creates confusion. The Parallel RDP plugin is now the best gfx plugin you can use since it reaches the accuracy of angrylion but with much better speed and upscaling options. But most new users end up with the outdated Parallel core since it has “Parallel” in the name, so it must be the correct one to use for the Parallel RDP, right?
It’s the same confusion with the Glide64 VS GlideN64 plugins that went on for a decade+. The author made the mistake to use the same name with only an extra letter as the difference in it. Dunno why he didn’t just continue updating Glide64 or, if he wanted it to be a different project, use a different enough name. So for all the years that followed, it was a crapshoot whether a new user would end up with Glide64 or GlideN64 (the PJ64 emulator had the old plugin included, for many years). They heard “GlideN64 is the best HLE plugin” but it was so easy to miss the “N” part. I can’t even count the times i had to explain to someone he is using the wrong plugin, after they made a troubleshoot topic or question. Which is something that continues to this day, since GlideN64 is still the best HLE plugin for slower systems that can’t handle Parallel RDP.
And now the same thing happens with “Parallel”. A lot of people just use the core, thinking is the correct one so someone has to explain the difference. And not only that, to make things even more messy, the Parallel core comes with the old Glide plugin, which often becomes the default option… So many people must still think N64 emulation sucks completely then, for no reason other than using the wrong emulators/plugins because of the naming confusion.
I use two cores for each system, one for High-Res or Scaling shaders (if 2d), and another for CRT shaders, so Parallel is still good to me, I’m glad it still exists. IMO RetroArch should have an option to duplicate cores and to rename or nickname it, so people would be able to do what I did with just one core.
Your usage case doesn’t have to do with the quality of the core though, you just need another N64 core so you can save different shaders/settings/etc, due to how RetroArch works.
You can still get rid of parallel and make a clone of the better mupen core, using a utility posted in this forum, so you can rename it and use it as a separate core. I used to do that with the Atari800 core, i was making a clone of it and renaming it Atari500, to use it for the Atari 2500 console and have different settings/shaders with it. Haven’t used it for a while though.
I agree. The core/plugin naming/confusion thing sucks. The main problem is that we don’t have any mechanism to forcibly migrate users when we rename a core, so the old core hangs around in people’s core directory and anyone using it never gets any updates (not that ParaLLEl-N64 gets many updates these days).
We could just rename it in the info file (like we do with the beetle cores), but that also requires everyone to update their info files (which many people never do).
Re: the naming of GLideN64, yeah, it’s unfortunate. However, it does make some sense insofar as it’s a combination of Glide64 and GLN64 (using GLN64 as a base to get away from the Glide wrapper legacy). Very confusing, though.
Kinda messy. I was just so sure parallel was the best n64 emu to use. Well I have tried mupen now with angrylion on several games. And it seems to run exactly like it should 
i just want it to work like on a actual console, I dont upscale or filter anything. I run everything in 240p. The only thing I want is it to be free from glitches!
Just so you’re aware, even with the best plugins, N64 emulation is still not perfect. Several games suffer from timing issues, usually minor ones such as title screen demos running a tad too fast but not affecting general gameplay, or games lagging less than on real hardware (which WOULD usually be a good thing… except some games’ movement physics are tied to framerate, so less lag can mess with that), but a few do impact the game noticeably, most notoriously Knife’s Edge, which runs at warp speed on all emulators and is thus practically unplayable at the moment. But again, most games are not affected all that much.
You could use the Parallel RDP/RSP instead of angrylion at 1x resolution. You will get the same result in graphics, just much faster. You also need to use Vulkan for it to work though.
You are also right. The angrylion and Parallel RDP are just gfx plugins. The are close to perfection but that just means only the graphics are close to perfection. The rest of the emulation is still not great with N64 emulators.
The reason is we are stuck with Mupen for what, 20 years now? It’s either that or PJ64, which is very similar. But almost every other N64 project, like m64p, the old Parallel core and every emulator for mobiles and RetroPie are all based on Mupen. And while Mupen is very mature and nowadays almost every game works, it’s still a hacky/highly inaccurate emulator with tons of timing issues.
Thankfully Ares is a thing. It’s the first N64 emulator in years that has a fresh core and isn’t based on Mupen. And while it’s not nearly as mature and many games still won’t work, it’s a much more accurate core where a lot of timing issues are fixed (like all these intro/demos in many games). It also uses Parallel for graphics so it’s already perfect on that front.
Let’s hope a RetroArch core of Ares (the N64 part of it at least) is going to be made. Because this is the best candidate of a good N64 emulator at last.
Ares is surprisingly compatible. Judging from recent tests, only a relative handful of games straight up don’t work or have major issues. Admittedly, however, there’s often regressions as the emulator develops, and games are leaving and joining/re-joining the compatibility list all the time (Rare games seem to be the most sensitive to core changes). But it’s definitely nice to see an emulator that is actually trying to do things correctly from the very beginning, as opposed to relying on HLE, per-game hacks and other workarounds. Not that I’m ragging on the emulators that do (they’re products of their time, after all, and weaning them off of such will be difficult, I’m sure). It’s just that ares will likely surpass them once all the pieces are in place.
I wonder how far they’re willing to go with its accuracy, though. Unless I’m mistaken, fixing the timing issues completely will likely involve cycle-accurate behavior, and that cannot come cheap performance-wise. It does use a dynarec, so that helps, but still.
Well, as long as they don’t cater to phones, PIs and other lower powered devices, Ares should be fine.
At some point users need to realize that emulation isn’t cheap on performance and consoles like the N64 need decent processing power to be close enough to a real N64. PCs should be the only platform for N64 emulation, IMO.