Mupen64plus (ricrpi branch)

[Anonymous]

In the interest of not clogging the boards with unnecessary new topics I decided to post here to see if I could get some help with some mupen64plus problems.

I have gotten everything installed and running, however it seems that when I run mupen64plus through emulation station, it ignores my configuration in the ~/.config/mupen64plus/ directory and does whatever the heck it wants.

The weird thing is that if I run it straight from command line, everything is fine. The differences are pretty big too. For one thing, when running it from the command line, it has the proper resolution (1024 by 768) which on the tv I run it on, it fills the entire screen. Not only that, but the escape key will stop the emulator and everything is cool/

Now if I run it from emulation station, it runs in 640 by 480, and because of that the aspect is 4:3 and leaves two vertical black bars on either side of the screen (pillarboxed?). And the other big deal is that I can’t exit the emulator with the escape key. Also I’ve noticed there’s a bit of a performance drop when running it from emulationstation. I wonder if that has to do with ram usage or some other such resource issue.

Ideally I would like to have it work like it does from the command line: full performance, full screen, proper resolution, escape key exits back to emulationstation. Although in a perfect world I would love to exit using the L3 button on my Logitech controller as it is never used by the emulator, but as of yet I haven’t found any way of making this happen, even with mupen64plus using the proper configuration.

Any ideas would be greatly appreciated!

[gizmo98]

Don’t know how to fix the escape key problem atm. If it is necessary to quit the emulator with escape or gamepad the only solution is to use mupen64plus-libretro: https://www.petrockblock.com/forums/topic/mupen64plus-not-worth-the-trouble/#post-82350

[ricrpi]

gizmo98

Have you tried using the ‘Joy Mapping Stop’ parameter in the mupen64plus.cfg file? You need to set it to somthing like ‘J0B9’ (for joystick 0, Button 9).

Hat buttons look more troublesome in the code. One must use J0HxVd where x is the Hat axis number and d is the dirction&magnitude.

There is probably a program to find button numbers easily however I usually use:

`cat /dev/[joystick0?] | hexdump -e ‘8/1 “%02X ” “\n”‘

If you think the code is broken then could you raise an issue on the repo.

[ricrpi]

Actually I recall seeing issues with the sdl_filter api function, used in the core, to detect events so I don’t think my comment above will work (although the code does support joystick events).

I’ll have a look through the libretro version tonight to see how they have worked around the issue.

[gizmo98]

Hi ricrpi,

your mupen64plus fork works fine standalone. But started from emulationstation there is an issue with the escape key. Every mupen64plus-core key-mapping is not working. Joystick is working fine. There are other SDL2 emus/games which have some keyboard issues with emulationstation like darkplaces quake. I don’t know how to debug emulationstation or mupen64plus.

BR
gizmo

[ricrpi]

A year ago I found that SDL keyboard input did not appear to work without the desktop so I quickly threw something together using raw keyboard inputs for console use.

I’m revisiting this code since the official mupen64plus has now moved to SDL2 and I’ve found some missing information I need for SDL2 graphics and input on the pi.

[Anonymous]

So I’m not sure why this works suddenly but I installed the libretro core version of mupen and changed my memory split to 128 gpu and 384 cpu.

Now the controllers work (haven’t tested 2 player yet) but the performance is pretty bad and the graphics in menus and such are sometimes scrambled. Otherwise the games are for the most part playable (if you know the menus by heart like I do). Any ideas how to fix the graphics and performance?
I haven’t touched the config file at all since last time. And it might be default. I don’t know how libretro handles these things.

Thanks for your previous help in solving these issues!

[powerpoint45]

So I’m not sure why this works suddenly but I installed the libretro core version of mupen and changed my memory split to 128 gpu and 384 cpu.

Now the controllers work (haven’t tested 2 player yet) but the performance is pretty bad and the graphics in menus and such are sometimes scrambled. Otherwise the games are for the most part playable (if you know the menus by heart like I do). Any ideas how to fix the graphics and performance?
I haven’t touched the config file at all since last time. And it might be default. I don’t know how libretro handles these things.

Thanks for your previous help in solving these issues!

same here except arrow keys don’t work for me and My split is set to 255

[gizmo98]

As somewhere else stated mupen64plus-libretro needs at least 1GHz OC. If you have graphics issues try to use another video plugin (rice or gles2n64). Open RGUI with “F1” and select “Core Options/Video PlugIn”.

Mupen64plus standalone needs less CPU power but has other issues (emulationstation + escape key).

Both emulators are still under development, so hopefully there will be some fixes and speed improvements.

[Anonymous]

Yeah I hope so too. I would love to contribute to the project but I’m not sure if I have enough time to really get much done. I’m pretty sure most of it is written in C++ and I have some experience in that language.

As for my setup, I have the Pi over clocked to 1ghz so that can’t be the problem. I’ll try messing with the plugin settings as suggested. Thanks!

[ricrpi]

I am pleased to confirm that Joystick events are now working.

Just set the event e.g. Joy Mapping Stop = “J0B1”.

Note that the ‘J’ and ‘B’ are case sensitive and make sure you change the correct .cfg file.

[raoskidoo]

For a weird reason , I have the latest source-based installation of retropie and mupen (N64 emulator ) is not installed , I can’t even find it in the Retropie Setup . Help me please :(

[ricrpi]

It was in the experimental section last time I checked.

Retropie uses the script github.com/ricrpi/mupen64plus/build.sh. I’m currently in the process of updating it though but should be finished by friday. The script is not wholly compatible with Retropie at the moment. You could hack the script by removing –disable-video-x11 on line 37 to get it working before friday.

[sbr0309]

@ricrpi Thanks again for all your work. It doesn’t look like you made it by Friday, near as I can tell from the github site. if you could post here again when things are ready to go to try to make it work through retropie, that would be great!

A bit of back story: total noob here trying to put together a n64 emulator on a raspberry pi for my boyfriend for christmas since he’s getting all nostalgic about n64 games. I gave up on retropie (for now, perhaps) and currently waiting for just mupen64plus to install on my pi with wheezy. it’s been quite the wild ride!

In the mean time, I’m not really sure what you mean by hacking the script. How would you do that?

Thanks!

[ricrpi]

On friday my testing of mupen64plus with SDL and X11 failed. I have updated the build script though as I think it is a core related issue that I am looking into.

Mupen64plus will compile and work if you build without X11 support but it would break retroPi as the script will require one to update the SDL library (it will then be missing X11 support).

Within the build script there is some commented out commands in the SDL section that would statically link SDL into mupen64plus (near line 285, look for SDL_CFLAGS=…). I have not tested the binaries though.

[gizmo98]

Is there a issue with X11 or without X11? It should be possible to start X11 and mupen64plus from RetroPie with “xinit mupen64plus %rom%”.

[ricrpi]

mupen64plus throws an error on SDL_CreateWindow() in api/vidext_sdl2_compat.h when SDL2 is compiled with X11 support. Hopefully its just a flag/attribute issue.

[ricrpi]

I’m getting a little confused now, can anyone tell me if RetroPie or other emulators require SDL/X11 support? I can’t get an X11 window using SDL2 with GLES2 support.

To test, supplementary/sdl2.sh, line 22 would need to be changed to ./configure --disable-video-x11 --disable-video-opengl

[gizmo98]

I cannot test now. You can try to run EmulationStation from X11. The binary can be found under /opt/retropie/supplementary/EmulationStation.

I am only aware of three SDL2 applications now:
EmulationStation, RetroArch (don’t know if SDL2 video driver can use shaders(GLES2)), mupen64plus.

[Anonymous]

has anyone got a working .img they can host for retropie with a working n64 emmulator. I libretro is too slow even with max overclock etc and I cannot make the ricrpi versions work at all.

I’m nowhere near the level of most of the chat in this thread but ddidnt want to clog up the board with another post.

[gizmo98]

Hi 7lucky7,

Please update your retropie setup script and install the experimental mupen64plus module. Mupen64plus standalone should work now.

[Anonymous]

Thanks. the emulator runs really well on the new rpi

My only issue is with controller mapping. I have two generic N64 USB controllers. Unfortunately the mapping of the keys is wrong. A and B map to the right hand down and left. and A&B map to the shoulder buttons. I cant quite figure out where this info is stored, and i’ve tried to set it up using retroarch but assume that mupen doesnt use retroarch because the mapping has no effect.

Can anyone help me with this??

[gizmo98]

You can edit key mappings in /opt/retropie/configs/n64/mupen64plus.cfg and /opt/retropie/configs/n64/InputAutoCfg.ini.

[clone206]

Got the 2.5 image running on my raspberry pi 2. It was a breeze to get up and running, so thanks for the great work! The problem I’m now having is I can’t get 2 player to work in Mario kart 64 with mupen64plus. The bottom screen is blacked out so player 2 can’t see what they’re doing.

Here’s the interesting part. The 2nd player can still control their character. For fun, I (as player 1) followed closely behind player 2 for an entire race so they could use me as a camera man and so they finished in 1st place. Then, when the next race started my (the top) screen was blacked out and theirs was now functional. We tried this scenario again with roles reversed (camera man vs lead player) and whoever came in 1st would always have the functional screen on the next race.

To me, multiplayer Mario kart 64 is the holy grail of raspberry pi game emulation, so I’m really hoping to find a workaround. I suppose I could give the libretro version another shot, but the performance was horrible on the rpi 1.

According to the below thread, ouya users were able to get around this by using a different video plugin in mupen64plus. Is there a straightforward way to change plugins in retropie? Does it require recompiling mupen?

Emulator multiplayer?
byu/duracellchris inouya

[clone206]

In case anybody is interested, I figured out that it’s actually quite easy to switch video plugins. mupen64plus has a –gfx switch that allows you to specify which plugin to use. Retropie 2.5 comes with two customized plugins, which happen to also be the plugins used in ouya, which is why ouya users also face the mario kart 64 issue. These plugins are named gles2n64 and gles2rice.

In retropie 2.5 gles2n64 is the default plugin used by mupen64plus. It actually looks quite a bit nicer – at least for composite video out – than gles2rice, which I believe used to be the default in previous versions. The problem is that gles2n64 tends to lock up on a lot of roms, and in the case of mario kart 64, it can only display one of the players’ screens.

In order to use the gles2rice plugin only for certain n64 roms, I created a separate folder in the roms directory. Then I created a new system in es_systems.cfg, and specified that plugin using the –gfx switch within the command tags. Note that you also have to explicitly set the gles2n64 plugin using the –gfx switch within the command tags of the original system, or the other system will cause gles2rice to be written into the main mupen config file as the default plugin. I’m guessing there’s a more elegant way to accomplish this, so sorry if I’m leading anybody astray, but it was the best I could do with the knowledge I have. I know you can also edit plugin settings on a per-game basis via config files too.

Below is the relevant config code for using my method. The path to the roms directory has also been changed from the default because I keep all my roms on a usb stick, so you can’t just copy and paste this into your /etc/emulationstation/es_systems.cfg file. Also, I added a “sudo” before the commands as I also store save data on the usb stick, and if the commands aren’t run as root, mupen can’t write to the fat32 formatted usb stick. I’ve also read that running as root can give performance gains.

  <system>
    <fullname>Nintendo 64</fullname>
    <name>n64-mupen64plus</name>
    <path>/media/usb0/r0ms/n64-mupen64plus</path>
    <extension>.z64 .Z64 .n64 .N64 .v64 .V64</extension>
    <command>sudo /opt/retropie/supplementary/runcommand/runcommand.sh 1 "/opt/retropie/emulators/mupen64plus/bin/mupen64plus --gfx mupen64plus-video-n64 --configdir /opt/retropie/configs/n64 --datadir /opt/retropie/configs/n64 %ROM%" "mupen64plus"</command>
    <platform>n64</platform>
    <theme>n64</theme>
  </system>
  <system>
    <fullname>Nintendo 64</fullname>
    <name>n64-mupen64plus</name>
    <path>/media/usb0/r0ms/n64-mupen-rice</path>
    <extension>.z64 .Z64 .n64 .N64 .v64 .V64</extension>
    <command>sudo /opt/retropie/supplementary/runcommand/runcommand.sh 1 "/opt/retropie/emulators/mupen64plus/bin/mupen64plus --gfx mupen64plus-video-rice --configdir /opt/retropie/configs/n64 --datadir /opt/retropie/configs/n64 %ROM%" "mupen64plus"</command>
    <platform>n64</platform>
    <theme>n64</theme>
  </system>

Now I’m going through all my roms, and when I find one that doesn’t work with the default plugin, I simply move it over into the alternate folder (specified with the above config code) and relaunch emulationstation. Now there are two nintendo 64’s listed in emulation station, one for the default plugin, and one for the rice plugin. Of course, some roms don’t work with either plugin, but sometimes I get lucky. Majora’s Mask and Banjo Kazooie are two notable examples of roms that only work with the rice plugin for me.

I haven’t been able to test 2 player mario kart 64 with the rice plugin as I need my friend to come back over with his controller (unless I can figure out how to specify player two as using the keyboard), but I’m hopeful it’ll work, as it seems to work for ouya users based on the reddit thread in my previous post.

All in all, n64 games run much better on my raspberry pi 2 than they did on my b+. And I finally have working doom, duke nukem 3d, and quake III arena. I’ll post my overclock and memory split settings as well. It’s been pretty stable at these settings, but if I try to go up to 1140 the pi seems to freeze up and I get locked out. And I believe it was also the cause of sd card corruption, which is why I store roms, save data, and backups of config files on a usb stick now.

gpu_mem=64
arm_freq=1100
core_freq=500
sdram_freq=500
over_voltage=6

UPDATE: I got two player mario kart 64 to work with the rice plugin! I had to tweak some settings in /opt/retropie/configs/n64/mupen64plus.cfg to get it to work. With the default config both players’ screens just freeze before the race even starts. This seems to have to do with when the screen is redrawn. Under the “[Video-Rice]” section of the file I changed the following parameters. This also had the effect of making things look nicer too (smoother frame rate)

ScreenUpdateSetting = 7
...
SkipFrame = False
SkipScreenUpdate = False

Edit: Lowered gpu memory to 64 for better performance.

[gizmo98]

If you recompile both emulators you can test if neon optimizations speed up anything. Update RetroPie-Setup and open it with “sudo __platform=rpi2 ./retropie_setup.sh”. Select mupen64plus and mupen64plus-libretro under source based installation.

[clone206]

Thanks, @gizmo98!

In the past I’ve preferred to use the retropie packages script for source based installs, so I can catch any errors that come up. The setup script frustratingly goes back to the splash screen after any errors and then you can’t see what they were.

I take it I can use that variable at some point during usage of the packages script too?

[chdez77076]

Thats Awesome!

Somebody should definitely set up a “working n64 roms” database with the specific video plugin + individual changes to the config.

As more people try this emulator those setting could then maybe be setup as a default config for future releases.

Win!

Just a shower thought.

[clone206]

@chdez77076 – Looks like the beginnings of one are here:

https://github.com/ricrpi/mupen64plus/wiki/Game-Compatibility-List

I’ve gotten a ton of roms to be very playable now between the default plugin and rice with these updated settings. I’m seriously neglecting important things in my life because of this!

Also, I’ve gotten the default plugin to show both players’ screens in 2 player Mario kart 64 by setting “update mode=3” in gles2n64.conf, but the screen flickers so much it’s not really a workable solution. It’s a shame because it’s noticeably laggier with the rice plugin, to say nothing of the textures frequently being rendered incorrectly as black squares. There doesn’t seem to be much documentation out there on configuring the gles2n64 plugin. At least with the rice configs there’s heavy commenting.

I have no idea what the numbers for “update mode” even correspond to!

UPDATE: I figured out how to make the vast majority of the black boxes go away in mario kart 64 when using the rice plugin. This, in combination with the earlier changes to the settings I made, have got the rice plugin running pretty much on par with gles2n64 on the rpi 2. The trick was turning on texture filtering and using the “Sharpen” filter in /opt/retropie/configs/n64/mupen64plus.cfg under the Rice settings. So all of the relevant settings from that file are:

[Video-Rice]
...
# Frequency to write back the frame buffer (0=every frame, 1=every other frame, etc)
FrameBufferWriteBackControl = 1
...
# Control when the screen will be updated (0=ROM default, 1=VI origin update, 2=VI origin change, 3=CI change, 4=first CI change, 5=first primitive draw, 6=before screen clear, 7=after screen drawn)
ScreenUpdateSetting = 7
...
# If this option is enabled, the plugin will skip every other frame
SkipFrame = False
# If this option is enabled, the plugin will only draw every other screen update
SkipScreenUpdate = False
...
# Force to use texture filtering or not (0=auto: n64 choose, 1=force no filtering, 2=force filtering)
ForceTextureFilter = 2
# Primary texture enhancement filter (0=None, 1=2X, 2=2XSAI, 3=HQ2X, 4=LQ2X, 5=HQ4X, 6=Sharpen, 7=Sharpen More, 8=External, 9=Mirrored)
TextureEnhancement = 6
# Secondary texture enhancement filter (0 = none, 1-4 = filtered)
TextureEnhancementControl = 0

I am one happy camper :)

[chdez77076]

I’ve got to try this!!

I just got my pi2 yesterday so I’m definitely going to try this as soon as I get home from work.

[chdez77076]

Since this is in “Ideas For Further Enhancements” section of the forums, what about adding this –gfx switch in the video options (press x or m) that way they can be saved per individual roms?

[gizmo98]

Please post settings for different games. So i can add game specific settings in a ini file and games will run out of the box if the next RetroPie SD card image is released.

[chdez77076]

Sounds awesome!
Will start testing and posting!

[clone206]

As I was first looking into the mario kart 64 two player issue I submitted an issue for mupen64plus. Just today I got a reply that might be useful to the ricrpi maintainer(s). See the reply from today (Feb 20) at the below link.

I wonder if the rpi 2 is powerful enough to handle the vanilla mupen64plus-video-rice and mupen64plus-video-gln64 plugins. I get the sense they’d be compatible with more roms.

https://code.google.com/p/mupen64plus/issues/detail?id=641

[gizmo98]

Already checked. mupen64plus-video-rice runs as good as mupen64plus-video-gles2n64. I haven’t tested the gln64 plugin now.

Vanilla core, input, audio and video-rice are running atm.

[Author]

Posts