@dankcushions I have many games that run full speed with 4x MSAA and a CRT shader when using lr-mupen64plus-next. The issue I have is the temporary freezes when loading new textures/shaders for the first time. Standalone mupen64plus-GlideN64 runs at native resolution for me, i.e. 320x240, which to my eyes is unbearable on a modern screen.

Still, thanks for pointing me in the right way of the .cfg file - I wasn't sure if this was the one that would be used by mupen64plus-GlideN64 :) I will try experimenting a bit and will report back.

@TPR said in [SOLVED] N64 Mupen64Plus Controller Issue on GPi 2 Case:

SOLVED!

The correct syntax needs to be this in the InputAutoCfg.ini:

X Axis = hat(0 Left Right)
Y Axis = hat(0 Up Down)

Remove the quotes.

I'm not sure if the instructions in the RetroPie doc are wrong or something has changed recently, but that fix worked for me.

Hi! Thank you very much for the contribution, it works perfectly! I have another question… Does the audio work well for you with mupen64plus? Many thanks!

@dankcushions oh sorry here it is with gles2n64:-

https://pastebin.com/ExrPVkqi

@retropieuser555

I would love to, but, I can't seem to get the save file to work between mupen64plus and lr-mupen.

Lr-mupen saves data as a .SRA file, mupen64plus saves it as .SRM . I have been unable to convert the srm to sra.

Any ideas on how to accomplish this? I've tried pj64tosrm and other utilities, carefully checked the directories and names, etc.

@ancapgamer said in How do N64 Hi-Res Textures work now?:

Also, they seem to be written primarily for the "mupen64plus" core - which as of the most recent time that I updated my pi4 is no longer available, having been replaced by the "lr-mupen64plus" and "lr-mupen64plus-next" cores.

lr-mupen64plus is the mupen64pus core (now superseded by lr-mupen64plus-next, I think you're confusing it with standalone emulator (which is named mupen64plus).

Multiple google searches have actually yielded a truly distressing lack of documentation. I haven't found anything remotely resembling a set of useful instructions. Does anyone know how you're supposed to get Hi-Res Texture Packs working now?

Standalone instructions https://github.com/mupen64plus/mupen64plus-video-rice or the docs page, libretro core(s) https://docs.libretro.com/library/mupen64plus/#hires-textures. The N64 opt page (here) has even a video linked with instructions for standalone Mupen64Plus (not the libretro core).

I agree that documentation could be more explicit, but should get you started. Maybe give more details on what have you tried so far and it's not working?

@breadpie said in N64 on a Pi 3B+:

I have my Pi 4 (which is great), but I also have an older Pi 3B+ where the microSD became corrupted and I finally got around to putting in a fresh one. I grabbed the download from the retropie website, put it on a new card, etc. But, I noticed two things: 1) that mupen64plus (not lr-mupen64plus, and not lr-mupen64plus-next which wasn't installed by default) is the default for N64; and 2) that updates were available for mupen64plus. The stock build seems to have mupen64plus current as of Oct 2020, if I recall correctly. Normally I would update a package reflexively, but I also remember concerns about regressions with an N64 update from around last year. So, my questions, specifically for a Pi 3B+:

Should mupen64plus stay as default?

yes. standalone is fastest and most compatible. lr-mupen64plus (NOT -next) or mupen64plus-gles2n64 or even lr-mupen64plus-parallel may be faster in some scenarios, but the best balance is mupen64plus-auto (which i believe is the default for pi3), which selects the appropriate video plugin for mupen64plus-standalone, per game.

Is there any potential downside to installing the latest updates (since the most recent stock install) to these emulators on a 3B+?

not that i'm aware of, but as always, always back up before any updates. do note that n64 emulation is probably only going to get slower with updates, as emulation gets more accurate, compatible, etc.

Could find the solution on my own.

The correct syntax is J0B4/H0VX
where the "X" is set to be 1(up) 2(right) 4(down) or 8(left) depending on the direction.

@web458
Try this two -
https://retropie.org.uk/forum/topic/27542/n64-lr-mupen64plus-next-hi-resolution-texture/4

https://retropie.org.uk/forum/topic/24762/n64-texture-packs-htc/13

u will have the answer ;)

@mitu Yes for PS3 Controllers. I'll update, thanks for reminder.

Parallel-n64 barely works on raspberry pi and it looks like it's having segfault issues again. I would try out lr-mupen64plus-next if I were you as it is much more compatible with raspberry pi and it also offers 64DD support iirc.

@mitu thanks I will try that

@dankcushions nevermind... since i ran into a few other problems with lightdm and pulse which are way beyond my know how, i dropped that build. thanks anyway

@mitu I sincerely apologize I assumed my message was clear. The buttons were mapped but they were mapped to the joystick and the D-pad, etc. However, I was able to figure it out this morning. I keep trying to change the controller config under Quick Menu and then Controls but it is actually under Settings and then Input. I sincerely apologize for the confusion. I really appreciate your time.

@krystalis I thought it might be more than just that diagram. I did have to do a minor edit to the config file for the controller, but I can't remember what it was. I hope you get it sorted.

@retrochip said in Mupen64Plus problems (audio + video):

The only option I see so far is to use the 'Mupen64Plus SDL Audio Plugin' v2.5.9 plugin, but how do I do it? The script mupen64plus.sh should set it (am I wrong?), but if use the old one, it does not change anything and the 'Mupen64Plus SDL Audio Plugin' v2.5.9 plugin is still used.

it should. after a launch, what is the contents of /dev/shm/runcommand.info please?

@buzz @mitu I have a VirtualBox's Virtual Machine set to Debian (64 bits) running Raspberry Pi Desktop (https://www.raspberrypi.org/software/raspberry-pi-desktop/), which may be 32 bits?

Then I followed the guide on how to install RetroPie on Ubuntu/Debian https://www.raspberrypi.org/software/raspberry-pi-desktop/

@rip I had the very same issue and could not find any good solution posted already so I will post mine here (Z button was never an issue for me , Z button is also my hotkey)

Once configured as screenshot above and after first launch with n64 emu the following configuration was generated into /opt/retropie/configs/n64/InputAutoCfg.ini

; SWITCH CO.,LTD. Controller (Dinput)_START [SWITCH CO.,LTD. Controller (Dinput)] plugged = True plugin = 2 mouse = False AnalogDeadzone = 4096,4096 AnalogPeak = 32768,32768 Mempak switch = Rumblepak switch = C Button U = button(9) L Trig = button(4) C Button D = button(1) button(0) #C Down gets mapped to button(1) which is really B Button and button(0) is the actual C Down button DPad U = hat(0 Up) DPad L = hat(0 Left) C Button L = button(3) Y Axis = axis(1-,1+) X Axis = axis(0-,0+) DPad R = hat(0 Right) Z Trig = button(6) C Button R = button(8) R Trig = button(5) DPad D = hat(0 Down) Start = button(12) A Button = button(2) # Lack of mapping for button B at all ; SWITCH CO.,LTD. Controller (Dinput)_END

I then used jtest to actually view which button was what hence my conclusions above with jstest /dev/input/js0 then I edited the file nano /opt/retropie/configs/n64/InputAutoCfg.ini with the following

; SWITCH CO.,LTD. Controller (Dinput)_START [SWITCH CO.,LTD. Controller (Dinput)] plugged = True plugin = 2 mouse = False AnalogDeadzone = 4096,4096 AnalogPeak = 32768,32768 Mempak switch = Rumblepak switch = C Button U = button(9) L Trig = button(4) C Button D = button(0) DPad U = hat(0 Up) DPad L = hat(0 Left) C Button L = button(3) Y Axis = axis(1-,1+) X Axis = axis(0-,0+) DPad R = hat(0 Right) Z Trig = button(6) C Button R = button(8) R Trig = button(5) DPad D = hat(0 Down) Start = button(12) A Button = button(1) B Button = button(2) ; SWITCH CO.,LTD. Controller (Dinput)_END

Hope this might help someone else with same setup, cheers

/a

@sade even if you manage to build emulators, expect crash and/or black screen nearly everywhere, most emulators provide no support or only partial support for big-endian cpus

@peggytam009 said in why does mupen64 run better on my old phone, even though it has same specs as the pi3?:

@dankcushions said in why does mupen64 run better on my old phone, even though it has same specs as the pi3?:

what RDP (video) plugin is your phone mupen running?

i'm guessing your phone's GPU is GLES 3.x (pi3 is GLES 2.x), so it can run yabasanshiro, which is a good android saturn emulator. we're yet to get it running great on even pi4, but it won't run on pi3 at all, due to GLES version.

i managed to find the driver that mupen64 uses on my phone, its "GLES2N64"

mupen64plus-gles2n64 is available on retropie, however it's not very compatible and there's an issue with pi4: https://github.com/RetroPie/RetroPie-Setup/issues/3118

as for the saturn emulation, i think i was running the experimental package one called "yabause"

yeah, as far as i know this is good for android, but the linux gles versions are lacking. yabasanshiro is a promising fork, but has issues right now, and no-one to lead development on the pi side.