Getting the best N64 experience on a Pi 4

[Zering]

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

Definitely not a problem with my settings. I'll share them shortly.

It's not with mine either, I just thought I'd point that out. Ogre Battle was notoriously faulty on the Pi 3 as I recall.

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

Right? Not too bad, but most UI still seems to struggle and there are graphic anomalies here and there... Overall, better over the last year as the software continues to improve.'

It's leaps and bounds ahead of the Pi 3. When I bought a Pi 4 I expected a jump in performance but I certainly did not expect to play games that did not even play past the logos (Conker, Banjo-Tooie) at full speed on a stock rig. Not to mention 2D Saturn games at full speed, etc...

It's incredible work.

[roslof]

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

@roslof My roms are primarily NTSC, however I'm using a PAL screen, would that affect performance?

I never used a PAL monitor before, but you have me wondering about how an NTSC game may run on a PAL monitor. If it's a CRT, I would suspect animations would look off. If it's modern, could I handle 30/60 FPS displays? If not, wondering if V-Sync would be a problem.

[roslof]

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

Roslof:
Definitely not a problem with my settings. I'll share them shortly.

Zering:
It's not with mine either, I just thought I'd point that out. Ogre Battle was notoriously faulty on the Pi 3 as I recall.

Oh, sorry, I meant that the Ogre Battle doesn't crash with my default settings. I can make it past the questions without the crash you described. I'm working to export my settings to the compatibility chart. Will just be a bit.

[Zering]

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

Oh, sorry, I meant that the Ogre Battle doesn't crash with my default settings. I can make it past the questions without the crash you described. I'm working to export my settings to the compatibility chart. Will just be a bit.

Then I'd be very interested in your settings. My overclock is close to yours according to your chart, but I don't think that factors into whether or not the game crashes.
I can play it on lr-mupen64 with no problem, however as I play with a Dragonrise N64 pad my controls are tailored for the stand-alone version of the emulator, and they get a bit screwy on libretro, so Glide would be ideal.

Edit : How do I modify the setting for Framebuffer emulation in Glide?

[roslof]

I exposed all of my default test settings for N64 emulators. Same Google Sheet as the compatibility list, but separate tab/sheet.

These worked well for me for a primarily NTSC ROMset. Your settings may vary. It doesn't mean one is right and one is wrong... It means that this was the baseline for my testing, and overrides listed in the compatibility sheet override (or enforce changes) based on the exposed list.

Hope this helps folks.
Cheers,
Ros

[Zering]

@roslof Thanks to you here is what I have managed tonight , and all I have done is disable Framebuffer emulation :

-Full speed (without having to wait) on Bangaii-O with lr-mupen64plus
-Full speed on F-Zero X with lr-mupen64plus (it was very slow on Glide)
-Speed on Goldeneye in lr-mupen64plus without FBE is almost comparable to Glide. The menus and intros run significantly better in the lr core. Performance seems highest on parallel, which is very surprising (thanks for the tip).
-Jet Force Gemini : Speed outside of gameplay is on par with Glide. I have not tested the intro but the menu etc run full speed for me. More surprisingly, the game runs VERY FAST in lr-mupen64plus (it ran slow in Glide), unfortunately the video has a strobe effect of sorts, it blinks to black every couple of frames. If you have any ideas on how to sort that, then JFG could well be playable on my end. It runs fine on next and does not have the glitch, however I have spotted some minor slowdown in and out of gameplay. (But I'm just glad I can finally replay this freaking game!)
-Mischief Makers runs a lot better in the libretro core on my end. It slows down during the invasion although nowhere near as much as in Glide. There's a bit of scratchiness to the sound but nothing major. Gameplay is still slow however, and I would not call the game playable. I may tinker with it more.

Some weird quirks I have noticed :

-On lr-mupen64plus, I cannot run and shoot in Goldeneye with my Dragonrise N64 pad. If I press Z, I cannot move. That never happens on Glide.
-I have tried disabling FBE in mupen64plus under the Video section for Glide in mupen64plus.cfg and obtained adverse effects. Bangaii-O was a slideshow.
-I can't get any video in Resident Evil under both libretro cores, even with your instructions. I'm wondering if my rom is different?
-Full speed gameplay for Super Smash Bros under Glide, but the sound is two times too slow. I've had much better results with lr-mupen64plus

Anyway, that's it for now. Thanks a bunch for your input! Is the fact that FBE is a massive gamechanger anywhere in the RetroPie documentation?

[roslof]

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

Edit : How do I modify the setting for Framebuffer emulation in Glide?

You might not have to, but if you do, it's something like this:

1. Navigate to /opt/retropie/configs/n64/
2. Make a backup of the file GLideN64.custom.ini
3. Edit GLideN64.custom.ini
4. Search for your ROM

If you think you've found your ROM, you can add parameters. You can reference other ROMs found in the .ini file for the correct syntax.

If you don't find your ROM, you'll need to make a new entry.

It's a little tricky... but if I understand it correctly, for each entry, you'll see brackets with text inside, and a "Good Name". I believe the brackets contain ALL-CAPS reference to the in-ROM identifier found at 0020h... Although I admit, this is not 100% clear me, since I've seen Japanese entries that don't match (ex. Extreme-G 2).

...but I know I'm mostly correct, since I was able to fix Army Men: Air Combat.

To do that I followed these steps:

1. With a hex editor (found in many text editors these days), open the uncompressed ROM
2. Look at the string at 0020h:

With that, I was able to create this entry:

[ARMYMENAIRCOMBAT]
GoodName=Army Men - Air Combat (U)
graphics2D\EnableNativeResTexrects=1

...and that entry works fine, fixing the 3DO logo and title screen, since the default for EnableNativeResTexrects is typically 0. The bracketed information matches what's in my NTSC ROM. Any change to the bracketed text results in a mismatch and the change won't take effect.

From what I can tell, the bracketed text must be in ALL-CAPS, regardless of what's inside the ROM. Spaces should be substituted with %20... You should never end a string with a space (ignore any trailing 20s found) and probably a bunch of other rules I don't know about.

But the fact is, you CAN make per-game changes with GLideN64. I can't speak to the other plug-ins.

[roslof]

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

Is the fact that FBE is a massive gamechanger anywhere in the RetroPie documentation?

No, but we should be careful, it's required in order for many PAL games to work properly, so I don't think it's good advice to have people turn it off, unless they know what they are doing.

I set mine off by default, and turn it on only for games that require it to fix rendering issues. Otherwise, I use the stand-alone emulators, whose performance isn't completely degraded.

@dankcushions has communicated this concern and maybe at some point issues with slowdown w/Frame Buffer emulation will be resolved, but at least for today, you can opt for NTSC ROMs and decide whether it's on-or-off per-ROM.

[Zering]

That makes sense. I think, at this point, the N64 catalogue runs well enough on lr-mupen64plus and Glide that I can depend on both of those to match different needs and different games, so I don't think I'll be modifying roms individually, I'll wait for a fix instead instead. In the meantime, just knowing about the effect of FBE has had a huge influence on my Pi's capability to emulate the N64, and the results are excellent. Goldeneye is almost as I remember it, and now that I can play all the games Rare released on the system I'm a happy man! ^^

Thanks for all your help and suggestions!

[dankcushions]

i didn't even previously know about the PAL thing. FBE is such a fundamental part of n64 emulation that i can't entertain turning it off, under any circumstances. so many games have issues without it - maybe not obvious, but at some point it's likely things won't work right.

it's like using lr-mupen64plus, or gles2rice/gles2n64, etc. those are abandoned, broken and inaccurate cores/plugins, so even if they give good performance for some games, on some hardware... eh, i just forget about those. i would sooner just stick to gliden64 standalone and work within its capabilities, or help optimize it.

each to their own :) but the documentation should generally be aimed at most-compatibility, especially when n64 emulation is under such heavy development. what is slow today may be fast tomorrow, but no-one is going to touch those other emulators again.

[Zering]

@dankcushions Hey you do you, you guys are doing awesome work ^^
For what it's worth in my experience Gliden64 is far more reliable, so I'd be happy to stick to that if it came to it.

[roslof]

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

-Jet Force Gemini : Speed outside of gameplay is on par with Glide. I have not tested the intro but the menu etc run full speed for me. More surprisingly, the game runs VERY FAST in lr-mupen64plus (it ran slow in Glide), unfortunately the video has a strobe effect of sorts, it blinks to black every couple of frames. If you have any ideas on how to sort that, then JFG could well be playable on my end. It runs fine on next and does not have the glitch, however I have spotted some minor slowdown in and out of gameplay. (But I'm just glad I can finally replay this freaking game!)

Stoked for you, @Zering Seriously, it does feel good when this stuff works well.

Ironically, the flicker you mentioned is fixed when Framebuffer Emulation is True. :) But then you get the performance hit.

Not sure why the stand-alone GLideN64 is slow for you. Feels pretty good for me (even with hires). Not perfect, but certainly playable. No issues keeping Framebuffer Emulation on there, either.

[Zering]

Ironically, the flicker you mentioned is fixed when Framebuffer Emulation is True. :) But then you get the performance hit.

Not only did restoring FBE not alter the flicker in the least, it also did not affect performance at all on my end. Curious.

Have you got any ideas what could cause this little controls conundrum I'm having with the lr cores?

Edit : Your overclock is a touch higher than mine, perhaps that's why performance in Gliden is better for you?

[roslof]

@Zering I'm right with you. lr-mupen64plus handles Framebuffer Emulation better than lr-mupen64plus-next currently. This is what I believe will eventually be enhanced.

Edit : Your overclock is a touch higher than mine, perhaps that's why performance in Gliden is better for you?

I don't believe so. Is there a particular part of the game that runs slowly for you? I don't play each game for too long during the test (too many games). After the intro, I make it past the colorful gremlin-looking guy near the lagoon, enter the tunnel and can run around the world without much of an issue.

Also, you must restart either of the lr- cores in order for Framebuffer changes to take effect. I saw the flicker you mentioned. Enabled FB Emu, restarted and the flicker went away. Performance slightly degraded.

[Zering]

The whole game is significantly slower on Gliden than on lr-mupen64plus, as soon as I get off the shuttle the framerate dips, not in an abrupt sort of way. It's still smooth, but in contrast to the cinematics you can tell about half the frames have been lost along the way. In lr-mupen64plus it's silky smooth ; except for the flickering.

[Yobiwan]

Is there a way to lock aspect ratio to 4/3 and video mode to 640*480 @ 60Hz with rice plugin ? Everytime I connect the Pi4 to another monitor, I have to set video mode again and check TV options in order to force 4/3 aspect ratio. I would like to avoid runcommand configuration.

[roslof]

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

Is there a way to lock aspect ratio to 4/3 and video mode to 640*480 @ 60Hz with rice plugin ? Everytime I connect the Pi4 to another monitor, I have to set video mode again and check TV options in order to force 4/3 aspect ratio. I would like to avoid runcommand configuration.

I have never found a way to do this, unfortunately. It doesn't mean it's not possible, but it might be. Are you aware if there is a runcommand command-line option w/Rice?

[Yobiwan]

@roslof I don't know but it could be possible I think. I don't have enough knowledge to do it by myself for now.

[retropieuser555]

Hey, can we get @roslof's spreadsheet added into the documentation for N64 in the Docs please?

As I feel a lot of the info on there is based around the pi3, which is fine and we should keep that information too. But as more and more new users buy a pi4 instead of a pi3 they might be put off trying the n64 based on the Docs when really the pi4 does have some significant improvements over the pi3. But the Docs page at the moment don't seem to reflect that.

[dankcushions]

@retropieuser555 as discussed before, the docs should always reflect most compatibility, and especially now they're no-longer a quick-to-edit wiki, we don't really want such bleeding edge info. the current n64 "optimization" page is IMO an example of how the docs can lose their way when they are filled with overly specific, anecdotal information.

i think this kind of info is too granular for the docs, but perfect for the forum.

that said, the n64 docs pages do need some changes. i'll see if i can get to it.