Raspberry Pi Forums

Why RetroArch?


Because it offers a common backend for emulators and other ports like native engine reimplementations (scummvm, prboom, cavestory) so they can run as intended:
-No slow X11 protocol involved (wich causes high CPU usage and audio/video/control lag)
RetroArch CAN use a direct EGL backend. Even better, it can use Raspberry Pi native 2D API, Dispmanx! You can't get better than this, really
-Butter-smooth scroll at native phisical monitor refresh rates: for example, if a NES emulator runs at 60.1Hz and your monitor runs at 59.995 Hz, you would get occasional desynced audio OR video frames (jerky scroll not caused by internal emulated system slowdowns). That's UGLY. RetroArch makes it's NES emulator run at your monitor refresh rate, so unless you use some CPU while playing, you'll always get perfect srcoll.
-No need for a specialized GNU/Linux distro: just use your X-less Raspbian system to play these classics!
-Native linux input, no SDL required AT ALL!
-Of course, full screen scaling with adjustable ratio, size and pixed shaders for simulation phosphor crt magic (without the radiation ) or the GameBoy screen.

TUTORIAL ITSELF

Making RetroArch and some cores work on the Pi is very easy! In fact, it's easier than it is on an X86 PC.

First, we are going to install some development libraries an the git utility, wich we need:
Next, we will create the directory where our RetroArch+libraries will go:
We are first building the main executable (RetroArch) and then we will build some dynamic libs (wich are the "libretro ports", ie, emulation libraries for each system, or native source ports):

1) We clone the git repo: 2) We enter the cloned sources directory:
3) We configure the sources for compilation. We disable some features here, to get a lighter executable with just the stuff we need. GLES and VG will be disabled with these. My dispmanx driver the most optimal solution on the Pi:
3.5) Optionally, we can add some optimization flags. We edit config.mk and leave CFLAGS, CXXFLAGS and ASFLAGS lines like this: Then we can edit Makefile.common and comment this line if we're not doing debug work: 4) We compile RetroArch!
5) Now we move it to our RetroArch directory:
Now, let's go for some emulation libraries. What about a fullspeed MegaDrive + MegaCD emulator running fullscreen at a constant and solid 60FPS with NO TEARING and smooooooth scroll as in real hardware? (My Pi is running at 950 MHz)

1) We clone the repo: 2)We make some adjustments to the sources: 3)We configure the sources. 4)We build them: We will get a file called picodrive_libretro.so. That's our sega emulation library
We move it to the same directory where RetroArch is:
Now let's go for PC-Engine emulation!

The process is very similar to the other two: clone, configure, build, and move the resulting *.so file to our retro dir, so I won't be detailing the steps:
Now for the NES core:
....and so on

Now, we go to our retro dir and run some Sega MegaDrive game: We can use joysticks, etc. But that's beyond the scope of this tutorial.

Now let's say we want to run a Nintendo game: ..etc.
Other tested cores wich work perfectly are: prboom, nxengine, gambatte...
You can find their repositories here:

https://github.com/libretro

Have fun!

Vanfanel
Nice one! I will add to the Emulation Thread.

Thanks, Whelsy

Did you find a better pce libretro repository? The one I am using (in this tutorial) results on too slow SuperGrafx games, too.

Vanfanel
I found one elsewhere* and it is the pce_fast module but its approx 48 fps at 900MHz (For CD and SGX), I have Mednafen on another Image built with the pce_fast module and it runs at the same speed. But as mednafen offers 'Frameskip' its not slow! (However, the scrolling is TERRIBLE!). Like I always say emulation it always a 'Compromise'. If you want to try it ill post for you.

*Looking at the folders/files its the same one u have from Petrock's GIT

That's strange. PCE CD shouldn't cause any additional CPU load! (unless you're using ISO+MP3 for the games, a VERY bad idea).
And "plain" PCE games are rock-solid 60FPS here. Have you compiled RetroArch with the EXACT configure optiones I specified or are you using X11 graphics?

Vanfanel
No, I just did a 'default' build for testing purposes (with of course the obligatory NO X11!). ROM games are fullspeed SGX and CD games (I'm using standard .bin & .cue files) are not, as Mednafen produces similar (although not as impressive/fast) results I assumed it was normal (i.e. the extra processing required to stream the Red Book Audio). I am going to compile it again using some of your enable/disable features for further testing. Just one point (for others using the Tutorial including myself) are you using Arch as typing 'git clone git://github.com/libretro/RetroArch.git' etc. in Wheezy produces a bash error? (I don't tend to do this relying on downloading the zip file from the website).

Update - Sussed it you require the git dialog to be installed! May be advisable to add that to the Tutorial.

Vanfanel
Added to the 'Emulation on the Raspberry' Pi Thread.

Doing 'git clone git://github.com/libretro/RetroArch.git' works here without any problem. What's the error you're getting?

Vanfanel
A bash error, it doesn't understand 'git'.

You don't have it installed, it sounds like. Try running the following;
Once that's done, I believe that part of Vanfanel's instructions should work fine.

I successfully compiled the pcsx_rearmed Core which works fine but its 'Flickery' RetroArch is giving the following error -
Failed to create image for buffer
[GL] Failed to create EGL image
I added the submodule updates and then compile with -
1. make -f Makefile.libretro platform=armv6e
and
2. make -f Makefile.libretro
Same results. Does anybody know what the issue is?

I only test/use emulators that will offer a perfect experience (rock solid 60FPS) on the Pi.
Why try to emulate something that's going to be slow and buggy on the Pi as the PSX? Better try PrBoom (Native), NxEngine (Native port also) or the INCREDIBLE Gambatte.

Vanfanel
I'm only testing to see which cores work effectively performance wise, no doubt people are going to ask!

Cores Tested with Image 2013-02-09-wheezy-raspbian on a 256 & 512MEG RPi with a 64MEG GPU Split and 900MHz OverClock -

Stella (Sound 'Delay' Issue identified by Vanfanel, See Below)
QuickNES (No Issues)
Fceu-next ('Clone' Save file Issue identified by Vanfanel, See Below)
iMAME4ALL (No Issues)
Mednafen-pce (No Issues PC Engine Hu-Cards, SGX and CD games not 100%)
Picodrive (No Issues ROM and CD, 32X not 100%)
PocketSNES (SuperFX games not 100%)
Pcsx_ReARMed (Not 100%, use Frameskip (Core Options))
TyrQuake (No Issues)
Prboom (No Issues)

I compiled RetroArch following the instructions and when I launch it I get: I tried adding audio_driver = alsa in the cfg file but it still doesn't work.
Could it be because I'm using analogue audio and video?

EDIT:

Fixed it by installing libasound2-dev, running make clean and recompiling.

@kalehlr:

run "./retroarch --features"

You should see:
somewhere in the output.
If you don't then you haven't ALSA support compiled in, so you should do:
re-run the configure script and make again. It should work then
If not, ask here again.

(Instructions updated to reflect what LemmeFatale and Kalehr have reported)

@whelsy:

-Don't you get an incremental sound delay when you play Stella?
Load a game, and start playing: Take Pitfall for example. Play for a while, like 3-4 minutes. Then jump and observe the jump sound lags way behind the video. Can you reproduce that?

-As for fceumm (fceu-next), have you noticed it creates files with illegal names in the directory containig the RetroArch executable?
Load a game wich has saveram support (Zelda, for example), and make a simple ls of the directory with the retroarch exe.

Vanfanel
Its probably due to the firmware bug again (as with the Stella Binary, mine seems fine as it was Built with 2013-02-09 (Pre Fix)), it has been verified and fixed

See Here - http://www.raspberrypi.org/phpBB3/viewt ... 78&t=57035

Edit - Yup, same issue here! Although there is nothing on close to identify it like a pcm_underrun warning?

@whelsy: No, there's nothing to identify the problem this time.
It has nothing to do with the old, now fixed Stella problem, don't worry. It's a libretro port oroblem I believe. I will run some tests and report to the libretro porter.

Can you replicate the fceumm issue, too?

Vanfanel
fceu-next Core
Yes same thing, it saves a Legend of Zelda.srm file in the roms folder and a 'gibberish/symbols' named file in the retroarch exe folder with the same information on it. I have edited the 'Core Test' post above identifying these issues.

I have run into an issue running these instructions and don't know what to do, here is the error I get :


pi@raspberrypi ~/RetroArch $ make -f Makefile.libretro platform=armv6e
make: Makefile.libretro: No such file or directory
make: *** No rule to make target `Makefile.libretro'. Stop.

fivealive
A problem with the RetroArch executable or one of the 'Cores'? Please be a bit more specific and I will try to assist. From the output you may be trying to execute the command in the wrong folder where the isn't a makefile, was it PicoDrive you were trying to Build?

I was running this command


make -f Makefile.libretro platform=armv6e



Also of note I was copying and pasting the instructions into the terminal

fivealive
Yes I read that, but which folder were you in and what 'Core' were you attempting to Build? You can do all this in XWindows via a Terminal if your not used to command line through Console, then its easier to asses where your going wrong.

Be honest I have no idea, I was just copying and pasting the instructions, exactly as the order they are in, so I would imagine what ever directory I was supposed to be in. I know nothing about Linux.

fivealive
Ok, no probs, Vanfanel is very experienced so predominantly uses command Line. All the steps can be done in XWindows by simply making folders then transferring the contents (as you normally would in Windows systems) but I would have to rewrite the process! Perhaps a simpler Build would be advisable until your more confident in Linux, or start with a 'Fresh' wheezy Image and follow the steps EXACTLY! (if you have missed a step it will error). Was there a particular emulator you wished to use?