Tall Order 64? Using RetroArch for paraLLEl RSP + RDP and Nothing Else

General
#1

Hi. New to RetroArch, but not new to emulators.

While I’ve been emulating for well over a decade, I’ve never been particularly fond of N64 emulation simply because all the talk of increasing IR, texture replacement, plugin management, and HD 60fps widescreen hacks are a bit overwhelming for a guy that just wants to play N64 games as they actually looked and sounded. To be honest, It’s the same reason I’ve been reluctant to really sit down and figure out RetroArch. GlideN64 mostly gets there, but I’ve come to dislike the way it puts compatibility fixes alongside optional enhancements in its settings without always being clear about which is which - I sure as hell was not thinking about “EnableCopyAuxiliaryToRDRAM” or “FBInfoReadColorChunk” when I was playing Ridge Racer 64 in 2003. angrylion-rdp-plus looks amazing, but my laptop, with its middling i5-6300U and integrated graphics, is nowhere close to being powerful enough to handle it.

Which brings me to this forum. Ideally I’d like to set up RA in such a way that it can act as a reasonably accurate N64 emulator without the fluff. This entails the following:

  • Native resolution, 4:3 aspect ratio, V/I blur, integer scaling if applicable (not sure if it is for N64 games), etc. Basically what the N64 is “supposed” to look like. It sounds like I need Mupen64Plus-Next with paraLLEl RSP + RDP, but I’m less than certain about how I’m supposed to set that up.

  • Transfer Pak emulation (for Pokemon Stadium)

  • Two-player support

  • Some kind of CRT shader - I think crt-geom-flat was the one I wanted - and some kind of S-Video filter if my hardware can handle it.

  • Maybe a way to run it from a batch file if possible. All of the UIs make my head hurt.

I would also like to know which folders and .dlls in the standard Windows install I can safely discard without compromising the above goals, because I’m seeing a lot that I don’t expect to use. Do I need all the GUI assets? What about the overlays? Do I need both GLSL and slang shaders? Why are there so many .dlls? Can I turn off the Retropad and map my controller buttons directly, or am I stuck with it? I have emulators that suit my needs for other systems, so I’d really just like this to do N64.

#2

AFAIK, you can’t discard any of the DLLs without breaking RetroArch because it links against them. You could recompile it without the features that require those deps but it’s not something you can do on the fly.

You can toss a lot of the assets if you don’t mind using the RGUI menu instead of the flashy “ozone” and/or “xmb” menus. If the only thing you’re going to run is mupen64plus-next with ParaLLEl-RDP/RSP, you can get rid of the GLSL shaders, as you’ll be using vulkan/slang.

Here’s the documentation for the core, linking specifically to the transfer pak info: https://docs.libretro.com/library/mupen64plus/#using-the-transfer-pak

You can’t take the retropad out of the picture, as that’s the way the frontend (RetroArch) communicates about input to the backend (the core).

You can launch from a script/CLI, sure. It’s just:

.\retroarch.exe -L path\to\core.dll …\path\to\game.z64

If you load RetroArch and the core with default settings, it will start out using the “gl” video driver and GLideN64 with HLE RSP. Load some game and go back into the menu and go to “options”. Most of these will refer to GLideN64 for now, but go ahead and change the RDP and RSP to ‘parallel’ and then back out of that menu and ‘close content’. When you launch the core+content again, it should be using those plugins and should automatically switch to Vulkan as needed. If you go back into quick menu > options, you should no longer see the GLideN64 options and should see the ParaLLEl-RDP options instead.

1 Like
#3

Thank you so much! Your thorough reply saved me a world of pain. As of today, ParaLLEl-RDP + RSP is running beautifully on my machine with crt-geom. Seeing the red dot in Pokemon Snap render correctly after all these years is simply unbelievable, truly a dream come true, and I can’t tell you how much of a godsend it is to be able to play at native res without constantly wondering whether I was actually seeing native res.

The command-line script you gave me is just wonderful as well, letting me jump seamlessly into a game in seconds. And discarding the files you recommended along with some ROM databases for systems I won’t be using allowed me to reduce the size of the main installation by more than 50%! It’s difficult to overstate how helpful you’ve been.

I just have two more questions.

  • I see two options for cropping overscan, “video_crop_overscan” in retroarch.cfg and the ParaLLEl-RDP’s own “Crop overscan” setting. I left the latter off because it was messing with crt-geom’s vertical scaling, but should I be leaving the former off as well? That is to say, will it also interfere with the shader? I have integer scaling on, of course.

  • When using the keyboard, the standalone version of Mupen64Plus allowed you to modify the position of the analog stick with RShift and RCtrl so that you could get 25% and 50% analog - and + with the arrow keys. Is there a way to get something similar in RA? It’s not an absolutely essential feature since I can always just use a mouse, but it is nice to have if I am ever stuck with keyboard input for one player.

#4

np, glad I could help.

The frontend-based overscan crop option is sort of a vestigial organ. We started moving to core-based cropping options because a single option just wasn’t flexible enough to cover all of the variations that some cores need. We kept/keep it around, though, for the handful of cores where a one-size-fits-all option is adequate.

We do not have any less-than-100% digital-to-analog mapping, unfortunately.

1 Like