Freezing on Kirby 64 w/ Mupen

Libretro Cores
#1

Trying to play Kirby 64 on the Mupen core (Windows 10) When reaching the 1st boss - the black ball lookin’ enemy in the cabin - As soon as I deliver the final blow, the game freezes (though music continues).

Tried it initially with Angrylion and ParaLLEl. ParaLLEl-RDP just crashes retroarch on this computer. Guessing I’m lacking something it looks for. I also tried using G64 and HLE, as well as Angrylion with CXD4… all of them result in this same freeze.

I’m fairly sure I’ve gotten past the first boss before with this core, so I’m not sure if this game just has some weird problem or what.

Anyone get the same issue with Kirby 64 on Mupen?

#2

Do you have a save file we can use to test this?

Edit: I downloaded a complete save file but i can’t find that boss you mention.

#3

I took a screenshot to better explain. It’s within the first minute or so of the game. Freezes the second I kill this guy.

Kirby 64 - The Crystal Shards (USA)-210119-232944
Kirby 64 - The Crystal Shards (USA)-210119-2329441920×240 175 KB

#4

Ahh, super resolutions…

Kirby 64 - The Crystal Shards (USA)-210119-232944

#5

Ok but it would help if you told where to find this guy. Which level should i select?

#6

It’s in Level 1 “Pop Star”

#7

Yes, i can confirm the issue.

However, you can fix this if you change the CPU core from “Dynarec” to “pure Interpreter” in the core options.

This option seems to fix a lot of freezes and crashes in other games too (most notably, both Zelda games). It’s too demanding though (i assume that’s why it isn’t the default option) and using it in combination with mupen+Parallel plugins will be too much. So maybe it’s better to use GlideN64 for any game that need interpreter to function correctly.

1 Like
#8

That’s good to hear. I’ve been tinkering with this little PC I bought specifically for a RetroArch + CRT setup for so long, and I finally sat down to play something (Kirby) and just felt so discouraged haha. I know N64 can be spotty though, so I’m glad it’s something that’s known and not on my end.

I was thinking about switching to GlideN64 for RDP anyway since it’s runs pretty well on this machine. Do you know if it’s recommended to use HLE instead of ParaLLEl for RSP? I feel like I’m used to seeing an either/or situation there.

Either way, I really appreciate you helping me confirm this.

1 Like
#9

GlideN64 is very mature and highly compatible. It’s recommended for most computers.

Parallel RDP/RSP is LLE and more accurate, but it’s slower.

IMO here’s how it works: N64 emulation can either give you graphics bugs or core/cpu bugs. The Parallel plugins or Angrylion pretty much have you covered graphics-wise so you only have to deal with core bugs. This Kirby bug is a core bug.

With GlideN64 you will have to deal with both core and graphics bugs. Most of the time you can fix the graphics bugs yourself but there are too many graphics options to test. Parallel/Angrylion don’t need all that.

So my recommendation is, if your PC can handle it, use Mupen-next with the Parallel plugins as default. This way if you see a bug, it’s most likely a core related bug. If it needs interpreter to function then see if it’s too much for the computer to handle. If it’s slow then for that game alone make a core option override so it uses GlideN64 + interpreter. This should get you through at least 95% of the N64 library (i bet 100% of it but i’m playing it safe).