5th generation consoles on the Raspberry Pi

RetroArch Linux devices
#1

I have been working on building an emulator using the all-too-common Raspberry Pi as the base. The friend who I am building it for is a huge N64 fan, and I would like to add it to the list of consoles which my emulator can run. Unfortunately, although the libretro-core for Mupen64Plus compiles with no errors (albeit many warnings), it fails to load using RGUI and causes a segmentation fault or “Could not use HW Context” when loaded with

./retroarch -L /path/to/core.so

. I’ve tried everything in my arsenal to get it to work, and I am well versed in the ways and workings of Linux.

Has anyone had success with any RetroArch/Mupen64Plus combinations? If so, how are they compiled, what commit did you use, and when did you make it?

If you can help me out, I would be happy to provide any information which you may need, I simply have not included it as I am not sure what to post.

Thank you very much, PyroAVR

#2

I don’t think N64 hits full speed on RPi. Regardless, try going into settings > core > HW Shared Context ON

#3

hunterk, Thanks for the info, but I did try that. It’s a no go. The issue seems to be stemming from which GL implementation the core and frontend are compiled against. According to RetroArch, Mupen64Plus is compiled against OpenGL (even though I specified gles), and RetroArch is compiled against GLES2. Do you know any way to fix that?

#4

Hmm. When you compile mupen, are you passing platform=rpi? You might try compiling using the scripts from the libretro-super repo, as they may include some things that are not immediately obvious from the makefile(s).

#5

Yes, I am passing platform=rpi, and I am using the libretro-super from Github. I work off the latest, usually I pull the latest commits before I start working on a given day. Unfortunately, those scripts don’t seem to help either.

#6

Hello, did you try to remove mesa?

#7

Remove mesa? On the contrary, I had to add it in order for it to compile.

Hunterk, I cleaned everything and passed ONLY platform=rpi when compiling mupen64plus, and now it loads, but crashes with only “Segmentation Fault” after “Failed to create rendering backend: stb” Do you know of any fixes for this?

Thanks again, everyone!

#8

New update: I have attempted to use Clang to compile mupen64plus, unfortunately, although it compiles just fine, after leaving it to link for nearly 24 hours (on a pi 2!) it still had not finished. I gave up and retreated to the GCC world, but am now confronted with the segmentation fault seemingly randomly. It appears most often after the audio backend (I am using OpenAL), and then suddenly crashes after it has successfully initialized the audio. I’m not entirely sure what this means, but I’ll look more into it.

I also pulled in the latest commit from the repo, which may have something to do with the new location of the segfault.

What information would help to troubleshoot this? I am a programmer, but I don’t know much about the inner workings of these emulators, other than the basic ideas.

#9

A backtrace with gdb may help pin things down a bit.

#10

does your retroarch install run other systems ok?

http://blog.petrockblock.com/retropie/ has the retroarch version of mupen64plus working fine (although it performs worse than the none-retroarch version on the pi). if you still really want to make a build yourself (on raspian?), you could have a look at their git to see what their scripts are doing when they rebuild it from source: https://github.com/RetroPie/RetroPie-Setup/blob/master/scriptmodules/libretrocores/lr-mupen64plus.sh

FYI retropie does not run on raspian jessie yet. not sure if there are problems you will run into, but something to bear in mind.

#11

dankcushions, Yes, it runs perfectly on an x86_64 machine running Debian Jessie.

I think the problem may be that I am using Debian Jessie! I’m working on a new install with Wheezy now, and hopefully that will fix it.

hunterk, I will get a stack trace as soon as it is compiled for the “new” OS. Thanks everyone!