Getting the best N64 experience on a Pi 4

Ka

One thing I’ve noticed on N64 games on Retropie is that games like Goldeneye and Excitebike 64 run extremely well in-game, but have badly stuttering sound in the menus and title screens. Why is that? I would have thought that the actual game bit of Goldeneye was more demanding than the level select menu.

Nakynaw

@roslof thx!

I will keep testing, and trying your suggestions. But I think I should go back to the default and up to date "mupen64plus.cfg" first. I kept trying stuff since many games became way worst with mupen64plus-gliden64 after some changes I made.

The way to reset it is to erase the file and reinstall the emulator right?

If so, I have to figure out how to erase it, if anyone can spare a minute to guide me, I would be very thankful!

roslof

@Nakynaw said in Getting the best N64 experience on a Pi 4:

The way to reset it is to erase the file and reinstall the emulator right?
If so, I have to figure out how to erase it, if anyone can spare a minute to guide me, I would be very thankful!

Probably best to rename it with the Unix move (mv) command:

mv /opt/retropie/configs/n64/mupen64plus.cfg /opt/retropie/configs/n64/mupen64plus.cfg.bak

but if you really want to nuke the file, do this:

rm /opt/retropie/configs/n64/mupen64plus.cfg

I'm not sure if the file will automatically regenerate, but chances are yes -- you may need to reinstall.

roslof

@roslof said in Getting the best N64 experience on a Pi 4:

I started up an N64 compatibility list, specifically for Pi4B and all of the various supported RetroPie emulators and added a section for emulator default overrides.

The first pass of the RetroPie Nintendo 64 Pi 4 Compatibility List is complete. Even though this is a highly optimized list (primarily NTSC and no prototypes) this took a solid week. Also, I'm human, so there are bound to be typos or missed optimizations. Feel free to share suggestions and opinions. The Compatibility List now accepts comments.

Not sure if the creators of these excellent emulators are working together or not but the list may be helpful in solving a lot of issues specific to the Pi4. Newer emulators have been created and are apparently more compatible on other devices. Not sure what additional love the Pi devices will get.

The vast majority of games are working with RetroPie, albeit some better than others. All observations are noted in the Obervations & Notes section of the Compatibility List.

Will be looking forward to playing with newer optimizations (Raspberry Pi graphic driver updates, 64-bit support, newer emulators and existing emulator enhancements) but for now, at this date in time, this is a pretty good read on where things truly are.

TRENDS:

Oddly, lr-mupen64plus typically outperformed lr-mupen64plus-Next with optimized settings. Not always, but more often than not. In the list, you'll note I recommend "plus" more often than "next". This isn't a personal bias, rather from observation on what provided a better gameplay experience.

For NTSC, the "lr-Next" build struggles with full-screen display that usually require Framebuffer Emulation set to true, which absolutely tanks emulation speed. The older "lr-plus" emulator handles most of these full screen issues without the need to enable Framebuffer Emulation. Not sure why. But this is a major reason why so many games play better with lr-plus than lr-next.

UI behavior seems to be more of an issue with Pi4 emulation than gameplay. For some games, it feels like the emulator will freeze/crash, but if you muscle through... you can usually reach some excellent gameplay. In several cases UI can get so bad that you can't [easily] get to gameplay easily or even exit the emulator properly.

Most Imagineer/Genki games need to change the CPU Core or weird things happen. Not typical to change this for any other game. For any of the bad-behaving games listed below, I tried different CPU Core options, but none would fix the problem(s).

It was remarkable how many times a game played poorly on 3-4 emulators, then worked AMAZING with exactly one. There is no single "best" emulator here. Without the complete collection of emulators, less games would be playable.

Regarding lr-parallel-n64. Such a disappointment on the Pi4B -- but also my hero... in exactly two (2) cases... It actually plays NFL Quarterback Club 99 where other emulators can't even boot it. There is no better, current emulator to play GoldenEye 007. Would LOVE to know why lr-parallel otherwise crashes for 90-95% of the games. It's experimental, of course, but it could be killer of it would just remain stable.

Lastly, here are the games that I could not get to run well with any emulator:

NOT WORKING/ NOT PLAYABLE/MAJOR ISSUES:

Disney's Donald Duck - Goin' Quackers
(Game seems to play well, until you learn that you cannot collect stars with any existing Pi emulator)

Glover
(Will not boot with any existing Pi4B emulator)

Hey You, Pikachu!
(Cannot play, since Microphone is necessary peripheral)

Knife Edge
(Game throttle is not working, so it really moves fast... Impossible to play/target)
Note: I tried playing with Count Per Op (from 0 to 5) but could not get solid gameplay.

Masters '98
(Swing meter rendering issue extremely slow, or starts slow the suddenly moves fast.)

NBA Hangtime
Game effectively 'hangs' around 0.5 FPS starting at tip-off.
EDIT here from 2020/09/14. Thank you @Nakynaw

NBA Showtime
(Animations are not throttled, so animations/gameplay speed is terribly fast when performance is good)

Quake II
(Visual particle effects slow game to an unplayable speed)

Top Gear Hyper-Bike
(Actually playable, but the ground texture is not properly mapped, so can't "see" the course.)

Vigilante 8
(Unstable. Will eventually crash/freeze. Broken interface and poor performance)

Vigilante 8: 2nd Offense
(Unstable. Will eventually crash/freeze. Broken interface and poor performance)

Waialae Country Club
(Same engine as Masters '98. Swing meter rendering issue extremely slow, or starts slow the suddenly moves fast.)

All other games are playable with the emulators noted and with the options set.

Hope this is helpful. It helped me complete a pretty solid, clean collection of games.

dankcushions

@roslof said in Getting the best N64 experience on a Pi 4:

Oddly, lr-mupen64plus typically outperformed lr-mupen64plus-Next with optimized settings. Not always, but more often than not. In the list, you'll note I recommend "plus" more often than "next". This isn't a personal bias, rather from observation on what provided a better gameplay experience.

plus is an obsolete emulator. basically it's got an ancient version of the GLideN64 video plugin that may have better performance in some games because it's so old and featureless. it will never be updated (to update it would make it lr-mupen64plus-plus-next) - in fact, it's archived/readonly: https://github.com/libretro/mupen64plus-libretro.

For NTSC, the "lr-Next" build struggles with full-screen display that usually require Framebuffer Emulation set to true, which absolutely tanks emulation speed.

i will have some improvement to this soon. however even more excitingly, there's a new optional video plugin coming for -next which is the pre-GLideN64 video plugin, Glide64. again, this won't be as accurate but was fairly mature when it was abandoned many years ago. in fact, up until recently it was more compatible than GLideN64 (and may still be, in some cases).

More often than not, UI continues to be an issue with Pi4 emulation, more often than gameplay. For some games, it feels like the emulator will freeze/crash, but if you muscle through... you can reach some excellent gameplay. In several cases UI can get so bad that you can't get to gameplay easily or even exit the emulator properly.

for -next (GLideN64) there's definitely some optimization issues with certain 2d scenes. something about texturing. unfortunately i don't know where to start with it.

Would LOVE to know why lr-parallel otherwise crashes for 90-95% of the games. It's experimental, of course, but it could be killer of it would just remain stable.

parallel is an experimental fork of mupen64plus for implementing the pixel perfect video plugin 'angrylion' via compute shaders (part of Vulkan). of course, no raspberry pis have vulkan (and even if they did, wouldn't be powerful enough for this), so parallel on pi doesn't actually use any of that and instead reverts back to whatever ancient videoplugins it has as fallbacks, which again is probably an ancient version of GLideN64, and ancient CPU emulation etc. that it has some benefits on certain games is a happy accident, but personally i wish they would disable such pathways as it muddies the water.

i'm hoping that once -next gets Glide64 support we can retire lr-m64plus, lr-parrallel (on pi), and so on. hopefully all these compatibility lists will become redundant (no offence! :) ).

quicksilver

@roslof Looks like Dank already addressed most of your questions but I had a couple comments.

Have you tried multiplayer goldeneye using parallel? Last I tried split screen didnt work properly so you may want to check that out.

Goin' Quackers and Rayman 2 both run on the same game engine and suffer from similar glitches. I opened a ticket a while back (https://github.com/mupen64plus/mupen64plus-core/issues/724) and I believe the issue was at least partially fixed but not for ARM devices unfortunately.

Glover will "work" but requires a work around. Unfortunately I cant remember exactly what it is. I believe you have to start the game using a certain mode or setting, get to a certain point and then save state. Relaunch the game using the original settings then load state. I know thats not much to go on but you might be able to find the info needed somewhere on the web.

Also you can improve performance on some games when using gliden64 or next by playing with the following settings: Legacy Blending set to on, Background Mode set to one piece, and turning off copy color to RDRAM. Be aware this will reduce accuracy. Conversely, you can enable these settings to improve accuracy in some games that may be broken without them.

roslof

@dankcushions said in Getting the best N64 experience on a Pi 4:

i'm hoping that once -next gets Glide64 support we can retire lr-m64plus, lr-parrallel (on pi), and so on. hopefully all these compatibility lists will become redundant (no offence! :) ).

None taken. What you just stated is the dream. The list only supports people who are looking for the best experience now. The creation of the list was indeed a chore -- literally loading every game 5-6 times just to find out how to squeak out the best experience. Funny that htop F9/9/Enter and ps all/ kill -9 have become my best friends over this past week. I think you know what I mean.

It would truly be great if there was a "Redream of N64".

In the future, if we can truly get what you describe, I'd happily mark the list as "obsolete". :)

I believe as hardware changes too, newer emulators will also become more relevant and compatibility will get even better.

But as the topic suggests, people have been wanting to get the best bang-for-the-buck today. Even the obsolete lr-mupen64plus plays an important role in this. It's featured prominently in the RetroPie Settings well above the experimental emulators, so it is widely used and important at this time.

Appreciate your support as always @dankcushions .

roslof

@quicksilver said in Getting the best N64 experience on a Pi 4:

@roslof Looks like Dank already addressed most of your questions but I had a couple comments.

Have you tried multiplayer goldeneye using parallel? Last I tried split screen didnt work properly so you may want to check that out.

I haven't, but will. Do you have an alternative recommendation for GoldenEye?

Goin' Quackers and Rayman 2 both run on the same game engine and suffer from similar glitches. I opened a ticket a while back (https://github.com/mupen64plus/mupen64plus-core/issues/724) and I believe the issue was at least partially fixed but not for ARM devices unfortunately.

Didn't catch that for Rayman 2, so will update. I figured you of all folks here would know these things. Appreciated.

Glover will "work" but requires a work around. Unfortunately I cant remember exactly what it is. I believe you have to start the game using a certain mode or setting, get to a certain point and then save state. Relaunch the game using the original settings then load state. I know thats not much to go on but you might be able to find the info needed somewhere on the web.

There is a prototype I haven't tried. May have something to do with that? From what I can tell, Glover can't even boot long enough to generate a save game otherwise. Interested to learn more. Googled the heck out of this a few days ago and didn't find the work-around. Will try again.

Also you can improve performance on some games when using gliden64 or next by playing with the following settings: Legacy Blending set to on, Background Mode set to one piece, and turning off copy color to RDRAM. Be aware this will reduce accuracy. Conversely, you can enable these settings to improve accuracy in some games that may be broken without them.

Yes, I found these useful with lr-mupen64plus-Next --
But the one thing I haven't figured out: For gliden64, how in the world do you constrain options to a single game? I tried playing with the .ini files, .cfg files... Figured out MD5 and CRC values and "Good" names, etc. But could never get anything to work outside of the primary mupen64plus.cfg file.

quicksilver

@roslof I use gliden64 for goldeneye. Dont need a special rom for glover it may have had something to do with starting the game using cached interpreter but I cant remember. Unfortunately you cant set per game settings using standalone mupen64plus-gliden64.

roslof

@quicksilver said in Getting the best N64 experience on a Pi 4:

Unfortunately you can set per game settings using standalone mupen64plus-gliden64.

I think you meant can't. And if so:

:O

Wow.

BreadPie

@dankcushions Really excited about the Glide64 option and the other improvements, thanks for the update. I'd noticed a reference to it on Twitter (here: https://twitter.com/m4xwdev ) but didn't know when that might be coming.

I was curious if anyone recalls when -next became the default N64 emulator? Was that the case in the 4.6 image? I realize I can change it to whatever my heart desires, but that's the problem, my heart has desired me to switch between things so many times that I no longer remember how it started out!

roslof

@BreadPie you could always:

Close lr-mupen64plus-next if it is running
Backup /opt/retropie/configs/n64/retroarch-core-options.cfg
Edit the config, removing lines that start with mupen64plus-next
Save your edits
Run Next
Quit Next

That should regenerate and save default options.

dankcushions

@roslof said in Getting the best N64 experience on a Pi 4:

@quicksilver said in Getting the best N64 experience on a Pi 4:

Unfortunately you can set per game settings using standalone mupen64plus-gliden64.

I think you meant can't. And if so:

:O

Wow.

well, i think fundamentally mupen64plus options don't really work that way, and never will. that's why libretro exists - to fork these various standalone emulators and interface them with an API that allows more sophistication.

however i'm hoping that this kind of option micro-management won't be needed shortly:)

Nakynaw

Can't wait to set this one up and see if there is any perceptible improvement in speed with the 8G of ram. But I've read that the difference would be very small, right?

dankcushions

@Nakynaw no difference. it will be the same as a 1GB pi4. ram is hardly used at all

roslof

@quicksilver said in Getting the best N64 experience on a Pi 4:

@roslof I use gliden64 for goldeneye

Hey @quicksilver, I spent some time with GoldenEye & lr-parallel. As expected, you were right about a multiplayer issue. Here is what I found:

GFX Plugin: Auto (glide64)

640x480:
2 window split screen is perfect.
4 window split screen yields flickering for P3 and P4.

320x240
All multplayer is perfect (albeit lo-res)

GFX Plugin: rice
Too much wrong with this. Don't waste your time ;-)

GFX Plugin: gln64
"Works" at 640x480, but with terrible wall and floor textures.

I still would recommend 640x480 glide64 here for 1P/2P gameplay, and advise lowering to 320x240 glide64 for 3P/4P -- or use stand-alone GLide-N64 as you mentioned. Wish "hires" was a bit faster. Can't quite get to a clean game without stutters.

AdamBeGood

Sorry to bang on about Perfect Dark again, but are other people able to run it happily with mupen64plus-GLideN64-highres? My Pi will run it, but I wouldn't say it was as playable as the normal mupen64plus-GildeN64.

I just want to know if my Pi is an outlier or not. An easy test is on Mission 2 - Carrington Villa. After the initial section with the negotiator, my music is a bit choppy as I move through the level. It doesn't make for a pleasant playthrough really. I would just stick with normal mupen64plus-GlideN64 but as the game looks so much better in the high-res core, I feel I have to ask the question. I love Perfect Dark.

I also tried Lr-Mupen64plus-next because of the previous suggestion, but the Night Vision section doesn't work for me on that. My screen just stays black. Edit - I am talking bobbins here. It works fine.

George Spiggott

I run it in Mupen64 Plus Next in forced widescreen at the lowest screen resolution (640x360 iirc). It runs well in that resolution.

quicksilver

@AdamBeGood you're asking too much of your pi 4. Gliden64-hires is basically doubling the original resolution, that's a tall order to fill for a $35 ARM computer. Unfortunately in this situation you won't be able to have your cake and eat it too ;). Some N64 games can run well with hires mode but that should just be viewed as a bonus not the norm.

For mupen64plus-next you need to make sure color to rdram is set to async otherwise the camspy etc will not work properly. I expect performance to be considerably worse than standalone mupen64plus-gliden64.

AdamBeGood

@quicksilver Fair enough! I'm sorry... It just seems fairly close in the high-res version, it isn't miles away from being playable. When I saw that core was noted on the spreadsheet as the recommended emulator, I just wanted to make sure I didn't have some dodgy setting in my config.