@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.

So I just wiped InputAutoConfig.ini and started again.

When it's this:

; Keyboard_START [Keyboard] plugged = True plugin = 2 mouse = False DPad R = key(100) DPad L = key(97) DPad D = key(115) DPad U = key(119) Start = key(13) Z Trig = key(122) B Button = key(306) A Button = key(304) C Button R = key(108) C Button L = key(106) C Button D = key(107) C Button U = key(105) R Trig = key(99) L Trig = key(120) Mempak switch = key(44) Rumblepak switch = key(46) X Axis = key(276,275) Y Axis = key(273,274) ; Keyboard_END

the game works perfectly, but keyboard only - WASD and cursors and a few others.

When I add this:

; usb gamepad _START [usb gamepad ] plugged = True Start = button(6) A Button = button(1) B Button = button(2) X Axis = "hat(0 Left Right)" Y Axis = "hat(0 Up Down)" ; usb gamepad _END

the keyboard stops working and the Start, A and B buttons all map to the proper buttons on the arcade joystick, (and button 5 quits back to EmulationStation) but the stick itself does absolutely nothing.

Those X and Y axis lines are taken from some semi-gibberish here:

https://retropie.org.uk/docs/Nintendo-64/

where it says *"Note for configuring Arcade Joystick or non analogue controller to use N64 correctly.
Changing the below inside /opt/retropie/configs/n64/InputAutoCfg.ini

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

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

But none of those lines, with or without quote marks, make the joystick do anything at all.

If I change it to:

; usb gamepad _START [usb gamepad ] plugged = True Start = button(6) A Button = button(1) B Button = button(2) DPad D = hat(0 Down) DPad U = hat(0 Up) DPad L = hat(0 Left) DPad R = hat(0 Right) ; usb gamepad _END

nothing changes. The stick still does nothing, whether I put quotes round the hat commands or not.

What in blazes do I need to do to make the dumb emulator recognise the stick?