Getting the best N64 experience on a Pi 4

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.

quicksilver

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

Fair enough! I'm sorry... It just seems fairly close in the high-res version

No need to be sorry, it's all a learning experience. Yes it can be frustrating when the performance is almost there but not quite.

George Spiggott

@AdamBeGood If you haven't already tried it, lowering the screen resolution in Retropie (down from 1080p) and lowering the audio latency (down from 64) can both have beneficial effects for emulators that are nearly fast enough.

@roslof Great work on the emulation guide. One tiny omission, I only run SotE in 320x240 with MSAA, not widescreen. AFAIK the game has no widescreen support.

There's a list of games that have widescreen support here: https://www.racketboy.com/forum/viewtopic.php?f=2&t=41744

I imagine that they all look better with widescreen enabled. I will attempt to find out with as many as I can.

Banjo-Tooie
Donkey Kong 64
GoldenEye 007
Perfect Dark (tested, yes it does)
The World is not Enough

Nakynaw

Hey Guys, until the N64 emulators get a major update, have we reached some consensus on anything about the tweaking of our Pi 4?

Its seems like the only consensus is about hybrid filter off and overclocking with hdmi_enable_4k60=1, v3d_freq=800ish and arm_freq+2000ish...

Speaking of which, I wondering, is «v3d_freq=830» really better than «gpu_freq=750»? Cause, I thought ISP, H264 and V3D were all on the same PLL and that ISP and H264 could not go higher than 750... So, when we set V3D at 830, does it really do that or it just max at 750 with the rest?

Also does everyone agree on «color to rdram is set to async»?

Skipframe, FBemulation, FXAA all seems like we are not all of the same opinion.

I am looking for a setup that would run most games with either Next or GlideN64 without making specific configs other than the emulators .cfg

George Spiggott

@Nakynaw You don't need to overclock the CPU at all to run N64. V3D overclocking is the only part of the GPU that a Pi4 needs for any emulation currently. My V3D is set very high, perhaps too high for some. It is stable on MY Pi, in the sense that I Have not encountered games won't work or any instability generally. However I have never run my Pi through a genuine stress test.

lucaparzival2022

@George-Spiggott I overclock my pi4 to 2.0 Ghz and every game I've tried works great.

George Spiggott

@lucaparzival2022 I have too but it really has no effect on N64 emulation. Don't take my word for it, take the overclock off and test it for yourself. CPU overclocking isn't even needed on a Pi3.

Ka

I have to say I’m really impressed by the performance of Goldeneye on Parallels. It runs so much better than on any other emulator; you can even run it at 60fps! It’s not perfect at full speed like that - it slows down a fair bit, and you get a lot of screen tearing. But it slowed down a lot on original hardware anyway, and Goldeneye looks and plays wonderfully at 60fps. It feels incredibly responsive, and the animation is fantastically smooth.

The only real issue is that some of the textures have huge black lines across them, like tramlines. It’s particularly noticeable on the open Siberian levels, where the black lines cover the snow textures, but it’s not too distracting.

AdamBeGood

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

Its seems like the only consensus is about hybrid filter off and overclocking with hdmi_enable_4k60=1, v3d_freq=800ish and arm_freq+2000ish...

I thought there was some controversy around 4k60=1 also, I am sure someone questioned the benefit of that.

It's really good that you are asking the questions though, it would be good to have this stuff nailed down to some degree.

Also does everyone agree on «color to rdram is set to async»?

Where is this option? Is this in the standalone mupen config, or is this a Retroarch menu setting? Not sure what I have mine set as.

ReadyPlayaWon

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

Where is this option? Is this in the standalone mupen config, or is this a Retroarch menu setting? Not sure what I have mine set as.

you can find it in ... /opt/retropie/configs/n64/mupen64plus.cfg

if you search within the mupen64plus.cfg file for rdram you'll find multiple references, but the one relating to color is this one ...

# Enable color buffer copy to RDRAM (0=do not copy, 1=copy in sync mode, 2=Double Buffer, 3=Triple Buffer)
EnableCopyColorToRDRAM = 1

or just disable in the menu

alt text

Nakynaw

@George-Spiggott said in Getting the best N64 experience on a Pi 4:

@Nakynaw You don't need to overclock the CPU at all to run N64. V3D overclocking is the only part of the GPU that a Pi4 needs for any emulation currently. My V3D is set very high, perhaps too high for some. It is stable on MY Pi, in the sense that I Have not encountered games won't work or any instability generally. However I have never run my Pi through a genuine stress test.

And what frequency is that, if you do not mind sharing?

(I just received my second Pi4 (extreme kit) will soon run some test for sure on my side!)

AdamBeGood

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

And what frequency is that, if you do not mind sharing?

(I just received my second Pi4 (extreme kit) will soon run some test for sure on my side!)

@Nakynaw It is in his signature at the bottom of his posts! I thought about asking this question too, before I checked there.

@ReadyPlayaWon Thanks for the info!

akamming

@George-Spiggott said in Getting the best N64 experience on a Pi 4:

@Nakynaw You don't need to overclock the CPU at all to run N64. V3D overclocking is the only part of the GPU that a Pi4 needs for any emulation currently. My V3D is set very high, perhaps too high for some. It is stable on MY Pi, in the sense that I Have not encountered games won't work or any instability generally. However I have never run my Pi through a genuine stress test.

I have a different experience. I had some sound stuttering in games like cruis'n exotica which were solved by overclocking the arm to 2000. (in combination with the kms driver and v3d overclock to 815).

AdamBeGood

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

I have a different experience. I had some sound stuttering in games like cruis'n exotica which were solved by overclocking the arm to 2000. (in combination with the kms driver and v3d overclock to 815).

I hate always being the guy with these questions, but what is "kms driver"?

akamming

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

I hate always being the guy with these questions, but what is "kms driver"?

it's discussed here quite a lot

basically a different display driver for the pi which offloads some work from the gpu to the cpu, which comes in handy when the gpu is the performance bottleneck, like in n64 emulation.

you can enable it in boot/config.txt. This is my config:

[pi4]
# Enable DRM VC4 V3D driver on top of the dispmanx display stack
#dtoverlay=vc4-fkms-v3d
dtoverlay=vc4-kms-v3d-pi4,noaudio

be aware: not all software (e.g. kodi, omxplayer) will work with this driver.

AdamBeGood

@akamming Cool, I'll try it out! I only use the Pi for gaming.

Edit: Emulation Station wouldn't load with that in the config, so I've taken it out now.

mitu

Note that this configuration - pure KMS driver - is going to remove support for the emulators relying ondispmanx and they'll not work.

The driver is still marked as experimental right now by the RPI engineers - though it's in a fairly usable state.

basically a different display driver for the pi which offloads some work from the gpu to the cpu, which comes in handy when the gpu is the performance bottleneck, like in n64 emulation.

That's not 100% correct, while the pure KMS has some advantages over the F(irmware)KMS driver, the CPU will not be boosting the GPU performance.

From: https://www.raspberrypi.org/forums/viewtopic.php?p=1507622#p1507247

Kinda offtopic but what is the difference between vc4-fkms-v3d and vc4-kms-v3d?

It's down to what actually drives the video scaler (HVS), pixel valves, and output display blocks (HDMI/VEC/DSI/DPI).
With vc4-fkms-v3d this remains with the firmware, and the firmware still allows DispmanX or MMAL to add extra layers.
With vc4-kms-v3d, the Linux kernel is driving all that lot, and DRM prohibits multiple clients adding layers at the same time.

George Spiggott

I seem to be having a bit of luck with turning off overscan on Mupen64 Plus Next. It doesn't seem to affect screen size on my TV and both SotE and Perfect Dark seem to run faster, Perfect Dark runs fast enough to run in 16:9 640x360 with MSAA without too much slowdown.

@Nakynaw It's in my sig, thanks @AdamBeGood.

dankcushions

@George-Spiggott the overscan option is a bit of a misnomer. you have to adjust the various overscan left/right/etc settings to see an effect. the overscan setting on its own just turns the VI emulation on, which is the part of the n64 that converts the game image to a TV signal. as part of this, it forces it to certain resolutions, sometimes different from the game resolution, which can cause scaling artefacts/blurring. also, i suppose it's an additional graphical operation that could cause some performance issues.

i'll look to getting it disabled by default.