Getting the best N64 experience on a Pi 4

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.

AdamBeGood

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

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.

I see too much screen tearing on Mupen64 Plus Next, and sometimes the Night Vision doesn't work, other times it does.... on my Pi at least. I don't have that kms driver like you do though.

George Spiggott

@AdamBeGood I never got any good results out of MSAA before upgrading to the KMS driver. MSAA delivers some nice improvements to low res N64 games for very little overhead, much less overhead than increasing the resolution. I can see why you would want to wait though.

AdamBeGood

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

@AdamBeGood I never got any good results out of MSAA before upgrading to the KMS driver. MSAA delivers some nice improvements to low res N64 games for very little overhead, much less overhead than increasing the resolution. I can see why you would want to wait though.

I don't want to wait as such, my Emulation Station just didn't load when I turned that setting on in the Config!

lvl0: Error creating SDL window!
    Could not initialize EGL
lvl0: Renderer failed to initialize!
lvl0: Window failed to initialize!

akamming

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

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.

ok... this is how i understood it. Anyway i am just a user, so i tried to write it down as how i perceive it. apparently not 100% correct.

but to be factual: these are my experiences with the kms driver / 5.x kernel. I'll try to avoid explaining why i have the experiences.

indeed not everything works with kms (as expected).
but i noticed better framerates on serveral emulators (including N64) as of kernel 5.x (don't know the exact number.) in combination with kms driver. So that's why kept on using it.
as of this kernel in combi with kms i was able to overclock the v3d clock more (now stable at 815. Before that i could not go over 750 without making my system unstable). Not 100% sure if this is caused by this kernel / kms driver: I always upgrade to latests supported versions (sudo apt update && sudo apt upgrade -y). And tried to overclock more at the time i got the new kernel and started using this driver. But ofcourse another upgraded component (e.g. firmware) might be the cause of this. This better overclock of v3d led to better performance of several emulators (including N64).
And when i overclocked my arm clock to 2000 i got even better results. (e.g. no more sound stuttering in cruis'n exotica. When i remove the arm overclock it's back...)

George Spiggott

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

And when i overclocked my arm clock to 2000 i got even better results. (e.g. no more sound stuttering in cruis'n exotica. When i remove the arm overclock it's back...)

It could be that KMS has changed the load on the CPU significantly. I can't test my overclock setting at the moment but I'd like to investigate this when I can.

Pre-KMS Mupen64 definitely did not benefit from overclocking the CPU as the CPU load on a Pi4 was IIRC around 50%.

akamming

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

Pre-KMS Mupen64 definitely did not benefit from overclocking the CPU as the CPU load on a Pi4 was IIRC around 50%.

it is in my config (using lr-mupen64plus-next) around 55%. but in my experience not having 100% cpu does not mean you cannot benefit from overclock. that depends on the how the code is written. if by turn the gpu and cpu are waiting for each other the cpu load coud be 50% and the emulation would still benefit from a faster cpu.

shavecat

Hey
@rufus
i did your over clock
But im still getting this error after im playing some games .
The temp goes no more then 50 deg'.
Its just writing this error on the left top screen non stop.

DRM_IOCTL_MODE_CREATE_DUMB failed: Cannot allocate memory
Failed to create scanout resource

any idea maybe ?

akamming

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

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

weird in that other thread i see a lot of people having a better emulation station performance with that config. On my system emulation station also works fine

Might be that you have omx player enabled in your settings (omx player does not work with kms driver)

AdamBeGood

@akamming Which setting file would that be in?

Edit: Don't worry. I'll have a look for myself, I think I recall seeing it.

George Spiggott

I'm continuing to get good results with Plus Next with MSAA on and Overscan off. It even improved the graphics of Worms Arnageddon slightly though the name bubbles continue to be badly distorted.

Also I used to be able to run Diddy Kong Racing in 640x480 but it seems much slower now, especially on the menus.

Ka

I've been trying out some of the recommended settings on the compatibility list. Some results:

The World is Not Enough: this is down as being too slow to play on 640x480, but I found that the game seems to run perfectly well at 640x480 with the recommended emulator - at least as fast as it does on original hardware (although my memory might be fooling me there).

1080 Snowboarding: this was unplayable for me in lr-mupen64plus-next. The game appears to load up fine, but the title screen and gameplay just show a black screen, with a band of visual noise across the top (although you can hear the game running in the background). Everything seemed to display properly in mupen64plus-GLideN64-highres worked (apart from some black lines across 2d images).

Doom 64: this worked OK on the recommended settings, right up until you die - the blur / fadeout effect seems to absolutely kill the frame rate, and appeared to freeze the game.

Excitebike 64: not really playable for me in mupen64plus-gles2rice. The front end seems to work OK, but in-game the screen flickered so much that it was unpleasant to play.

roslof

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

I've been trying out some of the recommended settings on the compatibility list. Some results

Thank you @Ka

Are these all NTSC ROMs? Sounds like at least some are PAL.

Nakynaw

@George-Spiggott that's the problem for me : when I tweak the Pi to run a specific game, it always seems to screw up another game that was running alright.

By example, I had decent results with Smash Bros, Mario Kart and 1080, but then I worked hard to be able to play Excite Bike. When I succeeded, all the games I previously named were not playable anymore...

I got so mixed up between the many changes I did to .cfg files, that I decided to restore my Retropie to the 4.6 official image and start anew.

That's why I am looking for setting ideas that are good overall, not like "skipframe=true" nor "fbemulation=false".

It seems like an high v3d freq is useful and hybridfilter=false does not seems to have bad repercussions.

You guys have any others ideas that are not a double-sided tweaks?

I have been reading about augmenting audio latency from 64 to 512, but I do not understand why it would help.

thx!

Ka

@roslof As far as I'm aware, they're all NTSC.

AdamBeGood

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

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

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

weird in that other thread i see a lot of people having a better emulation station performance with that config. On my system emulation station also works fine

Might be that you have omx player enabled in your settings (omx player does not work with kms driver)

Nah, it isn't OMX Player - that is set to "Off" in my Emulation Station settings (I guess you were talking about the Emulation Station settings - Main Menu->Other Settings).

Any other thoughts on what it might be?

Edit: I hadn't done Sudo rpi-update. Once I'd done that, KMS line in config worked.

Another Edit: Now my Xbox One Elite controller R-Trigger doesn't work. The lord giveth and he taketh away.

George Spiggott

@Nakynaw You can set individual settings for each game, It's worth doing if you have 'perfected' a game's settings.

I found changing Audio Latency useful when games appeared to run at full speed but the audio stuttered. SotE was a great example of this before KMS. I don't find it so useful any more.

Ka

What does the audio latency setting actually do? What’s the difference between having it at 64 and having it at 512?

quicksilver

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

1080 Snowboarding: this was unplayable for me in lr-mupen64plus-next. The game appears to load up fine, but the title screen and gameplay just show a black screen, with a band of visual noise across the top (although you can hear the game running in the background). Everything seemed to display properly in mupen64plus-GLideN64-highres worked (apart from some black lines across 2d images).

Color copy to rdram needs to be set to async otherwise you will have this issue. This is an accuracy setting and should always be checked if you are having some type of glitch in game.