N64 performance question

Zering

@lostless This is a question that keeps coming back.
N64 emulation on the pi is complex, each game functions much better or much worse depending on which plug in of mupen64 you use. As a rule the libretro version is generally slower although it works better for some games provided you use NTSC roms and disable Framebuffer emulation.
I would search in this forum for the N64 thread, roslof has posted a pi 4 compatibility list that covers every game and what configuration to use for each.

DreamcastKid

@zering said in N64 performance question:

I would search in this forum for the N64 thread, roslof has posted a pi 4 compatibility list that covers every game and what configuration to use for each.

I have to google spreadsheet bookmarked to link for others who don't want to trawl through a 300+ post thread :)

https://docs.google.com/spreadsheets/d/1Rq4shU1RUSdcc7cTVWeORMD-mcO6BwXwQ7TGw8f5_zw/view#gid=1983504515

DreamcastKid

@lostless said in N64 performance question:

My question is it the GPU or drivers for the CPU?

GPU

Overclock your Pi's GPU, stick with 640x480 or lower resolution for N64 and select the best N64 emulator per rom .

sirhenrythe5th

I remember 20 years ago i had better results with Nemu, Daedalus & UltraHLE on a Pentium 2. Later "Project64" was the way to go.
Maybe it is also the emulator itself: during my PC-Aera (1994-2007) "Mupen" allready existed, but was the weakest of all N64-Emulators for the PC.
However: i tested the most popular games "Mario64" and "MarioKart64" with the RP4 and was very dissapointed.
As i own a real N64 i can compare it on the fly, the gaming-experience is by far not 1:1.
I really had better results back in 1999 with Windows-PCs, but i guess there will be better perfomance/emulators in the future.
IMO it is not the Pi concerning all these errors and lack of perfomance, it is the bad software (Mupen).

dankcushions

@lostless n64 hasn’t been cpu-bound on the pi since the pi 2. run ‘top’ via ssh whilst a game is running and you’ll see cpu usage barely creeps up to 50%. the reason being is that mupen64plus has an ARM dynarec.

it’s also not necessarily gpu-bound; in my experience it’s system bandwidth that’s the main issue. have a look at RAM and core/cache overclocks.

quicksilver

Make sure you are using mupen64plus-gliden64 as your default emulator. This is easily the best plugin and should be used for 80-90% of the games. After some updates this past year I'd say that the vast majority of the n64 library is playable on the pi 4. I have overclocked my pi's cpu and gpu (v3d block) and it does help for some games though I'll need to do some additional testing to see how necessary it truly is. What specific games are giving you issues?

lostless

@quicksilver it’s not any game specifically, just an general question of where the bottleneck is. With all this extra power in the pi4, many other games on other emulators that slightly struggled on a pi3 systems, perform excellent now, and I can see they are using the pi4s cpu to the max. But n64 wasn’t taking advantage of that extra cpu power, no matter what emulator I chose, it slightly performed better than a PI3b+.

luckyluca

@quicksilver

do you mean that updates to gliden64 specifically has made it now 80-90% compatible with n64 games?
Also, are you referring to the ntsc romset specifically?

asking because the google doc mentioned in this thread points to several emulators and cores, wonder if it's not that up to date anymore.

thx!

Drdave79

@luckyluca I would assume since it's a live link that it's current by his last update. I could be wrong. Would be nice if he had a date on the spreadsheet somewhere.

quicksilver

@luckyluca I'm saying that gliden64 should be the default option for 80-90% of the N64 library.

The problem with the compatibility charts is that you have to trust whoever made it to have the same preferences as you do. Sometimes you have to choose between good performance or accurate emulation. Gliden64 is currently the most accurate and most performant for the vast majority of N64 games. The other plugin options are old and inaccurate but still have a few use cases.

luckyluca

@quicksilver thanks, I'm interested in compatibility and speed, I'll try that emulator first then.

On my installation both the lr-mupens and mupens core and emulator are from 29/10/2020.
Have there been more updates recently that would warrant updating?

One more thing, which I find confusing: the n64 emulators.cfg lists some gles2 options.
However under retroarch/cores/mupens I can see gles3 folders (rather than gles2), why is that?

Thanks again
Luca

dankcushions

@luckyluca

One more thing, which I find confusing: the n64 emulators.cfg lists some gles2 options.

mupen64plus-gles2n64? that's just a video plugin name.

However under retroarch/cores/mupens I can see gles3 folders (rather than gles2), why is that?

what are you specifically looking at? please show a screenshot or paste it.

luckyluca

@dankcushions
Thanks!
Regarding core and emulator versions, they're from the 29th Oct 2020.

Regarding that specific point, I was wondering where the GLES3 in the retroarch/config/ Mupen folders come from, considering that there is no mention of GLES3 in the n64/emulators.cfg file.

/opt/retropie/configs/all/retroarch/config
drwxr-xr-x 2 pi   pi    69632 Oct 31  2020 'Mupen64Plus GLES3'
drwxr-x--- 2 pi   pi     4096 Apr 13 00:21  Mupen64Plus-Next
drwxr-xr-x 2 pi   pi     4096 Jun 15  2020 'Mupen64Plus-Next GLES3'

mupen64plus-auto = /opt/retropie/emulators/mupen64plus/bin/mupen64plus.sh AUTO %ROM%
lr-parallel-n64 = "/opt/retropie/emulators/retroarch/bin/retroarch -L /opt/retropie/libretrocores/lr-parallel-n64/parallel_n64_libretro.so --config /opt/retropie/configs/n64/retroarch.cfg %ROM%"
lr-mupen64plus-next = "/opt/retropie/emulators/retroarch/bin/retroarch -L /opt/retropie/libretrocores/lr-mupen64plus-next/mupen64plus_next_libretro.so --config /opt/retropie/configs/n64/retroarch.cfg %ROM%"
lr-mupen64plus = "/opt/retropie/emulators/retroarch/bin/retroarch -L /opt/retropie/libretrocores/lr-mupen64plus/mupen64plus_libretro.so --config /opt/retropie/configs/n64/retroarch.cfg %ROM%"
mupen64plus-GLideN64 = "/opt/retropie/emulators/mupen64plus/bin/mupen64plus.sh mupen64plus-video-GLideN64 %ROM% %XRES%x%YRES% 0 --set Video-GLideN64[UseNativeResolutionFactor]\=1"
mupen64plus-GLideN64-highres = "/opt/retropie/emulators/mupen64plus/bin/mupen64plus.sh mupen64plus-video-GLideN64 %ROM% %XRES%x%YRES% 0 --set Video-GLideN64[UseNativeResolutionFactor]\=2"
mupen64plus-gles2n64 = "/opt/retropie/emulators/mupen64plus/bin/mupen64plus.sh mupen64plus-video-n64 %ROM%"
mupen64plus-gles2rice = "/opt/retropie/emulators/mupen64plus/bin/mupen64plus.sh mupen64plus-video-rice %ROM% %XRES%x%YRES%"
default = "lr-mupen64plus"

P.s.
@quicksilver @dankcushions I'd love if you could share your configs/all/emulators.cfg file guys, to take a peak at your n64 per-game settings, whether possible.

dankcushions

@luckyluca said in N64 performance question:

@dankcushions
Regarding that specific point, I was wondering where the GLES3 in the retroarch/config/ Mupen folders come from, considering that there is no mention of GLES3 in the n64/emulators.cfg file.
/opt/retropie/configs/all/retroarch/config
drwxr-xr-x 2 pi   pi    69632 Oct 31  2020 'Mupen64Plus GLES3'
drwxr-x--- 2 pi   pi     4096 Apr 13 00:21  Mupen64Plus-Next
drwxr-xr-x 2 pi   pi     4096 Jun 15  2020 'Mupen64Plus-Next GLES3'

i am not sure why you have both Mupen64Plus-Next and Mupen64Plus-Next GLES3 config overrides, but the name of the file is pulled from the library name and it looks like this was changed from the latter to the former after some refactoring, so i guess you have used it before and after the relevant update.

GLideN64 (the video plugin which both mupen64plus-GLideN64 and lr-mupen64plus-next use) has GLES3 code paths. it's nothing of note. the plugin is compiled to use GLES3 as appropriate in both contexts.

the ancient gles2n64 and gles2rice video plugins do not use GLES3.

VictimRLSH

I'm probably going to get rotting fruit thrown in my general direction for this, but I've actually found the best way to play N64 games on the Pi 4 is to run WoR with the latest 64 bit Win 10 ARM build and just use Project64. Getting Windows 10 ARM running on WoR (Windows on Raspberry) is a daunting task but well worth the effort considering how much it opens up.

lostless

@victimrlsh 🍅🥥🍅🍋🍎🍋🍋🍌🍅🍅. Might as well just plug my laptop into my tv at that point. Kinda defeats the ease of pick up and play of retro pie. 😂

luckyluca

@dankcushions
yes cores were updated at some point, which would explain the config folder naming switch.

@dankcushions
So that I understand correctly, the config folders
"Mupen64Plus-Next GLES3" and
"Mupen64Plus GLES3"

are not used anymore, so all per-game overlay configs should be copied to

"Mupen64Plus-Next"
and
"Mupen64Plus", respectively.

Am I getting it right?

dankcushions

@luckyluca what's an "overlay config"? do you mean override config? in which case, yes, in the case of Mupen64Plus-Next. I am not sure about Mupen64Plus - you'd have to check the code like I did for -Next.

it seems like it would be pretty trivial to figure this out, though. just load a game you have overrides for and see if they're applied via the RGUI, when they're in the wrong(?) folder, and whether they become applied when you move them to the right(?) folder.

luckyluca

@dankcushions

you're right, that's a quicker way of checking :-)

to answer your question, I was referring to per-game override configs that only contain a one line pointing to the overlay config (which in turn points to the graphics), if that makes sense.