RetroArch on Raspbian: the tutorial

[moocow1452]

Forgive me for asking the dumb question, but what's the difference between something like this and RetroPie, since I know Retroarch based projects on the Pi is nothing new. Is this just a formal guide?

[welshy]

moocow1452
Yes its a Guide/Tutorial for users who wish to build and run their on version of RetroArch on the RPi rather than use the RetroPie gaming Image. RetroPie is indeed based on this platform, however, this ‘custom’ build has a Raspberry Pi specific ‘lighter’ executable which also excludes the Emulation Station Front End resulting in improved performance. Its 'striped down' nature also allows easy integration into a Front End (say AdvMENU) to use the best emulators available on the RPi (e.g. PiMAME4ALL) or any other the user so wishes (it is much harder to intergrade other emulators into the RetroPie package). One specific advantage I have discovered over RetroPie is that there seems to be no issues/problems with game saves in any instance.

[cherrybombuc]

where can I download the ROMS?!!! please

[welshy]

cherrybombuc
Please DONT ask for ROMS or download Links on the Forum due to the legalities of copyrighted material. A simple search in any browser/search engine will locate many sites where they are available, e.g. 'ROMS for SNES' etc.

[Takenover83]

Anyone having trouble building retroarch as of late? (within the last few weeks)
Here is a pastebin of the output. Note the last few lines.

[welshy]

Takenover83
Yup, looks like there is an issue. I compiled it (Raspbian-2013-12-20) and it returned an identical error. However, pulling the previous version from the Git (RetroArch-0.9.9) it compiles and works fine.

[Takenover83]

Thanks for clarifying Welshy. Always so helpful. I will stick with 0.9.9.

[welshy]

Takenover83
No Probs!

[cacophony555]

This first "make" failed for me (for Retroarch). This was on a fresh Raspbian Wheezy image that I just download from the official site.

Here's my full history since first boot of this fresh card image:

I did a "sudo raspi-config" to adjust a few settings (locale, keyboard, timezone, memory split 256/256, etc)
I did a "sudo apt-get update" and "sudo apt-get upgrade" to get the latest software.

And here's the rest of the history with things like "ls" removed :

5 sudo apt-get install libasound2-dev git-core
6 mkdir ~/retro
12 git clone git://github.com/libretro/RetroArch.git
18 cd RetroArch/
20 ./configure --disable-x11 --disable-oss --disable-pulse --disable-sdl --enable-floathard
22 make

"make" made it for awhile and then failed with a large amount of output. Here's the tail of the output:
...
/home/pi/RetroArch/gfx/shader_glsl.c:864: undefined reference to `glGenBuffers'
/home/pi/RetroArch/gfx/shader_glsl.c:863: undefined reference to `glGenBuffers'
gfx/shader_glsl.o:/home/pi/RetroArch/gfx/shader_glsl.c:864: more undefined references to `glGenBuffers' follow
gfx/shader_glsl.o: In function `load_luts':
/home/pi/RetroArch/gfx/shader_glsl.c:295: undefined reference to `glGenTextures'
/home/pi/RetroArch/gfx/shader_glsl.c:320: undefined reference to `glTexImage2D'
/home/pi/RetroArch/gfx/shader_glsl.c:326: undefined reference to `glBindTexture'
/home/pi/RetroArch/gfx/shader_glsl.c:309: undefined reference to `glBindTexture'
/home/pi/RetroArch/gfx/shader_glsl.c:311: undefined reference to `glTexParameteri'
/home/pi/RetroArch/gfx/shader_glsl.c:312: undefined reference to `glTexParameteri'
/home/pi/RetroArch/gfx/shader_glsl.c:316: undefined reference to `glTexParameteri'
/home/pi/RetroArch/gfx/shader_glsl.c:317: undefined reference to `glTexParameteri'
/home/pi/RetroArch/gfx/shader_glsl.c:319: undefined reference to `glPixelStorei'
...
/opt/vc/lib/libEGL.so: undefined reference to `glxx_client_BindFramebuffer'
/opt/vc/lib/libEGL.so: undefined reference to `glxx_client_GenRenderbuffers'
/opt/vc/lib/libEGL.so: undefined reference to `glxx_set_error_api'
/opt/vc/lib/libEGL.so: undefined reference to `glxx_client_BindRenderbuffer'
/opt/vc/lib/libEGL.so: undefined reference to `glBufferSubData'
/opt/vc/lib/libEGL.so: undefined reference to `glxx_client_GetFramebufferAttachmentParameteriv'
/opt/vc/lib/libEGL.so: undefined reference to `glxx_client_CheckFramebufferStatus'
/opt/vc/lib/libEGL.so: undefined reference to `glxx_client_FramebufferRenderbuffer'
/opt/vc/lib/libEGL.so: undefined reference to `glxx_client_RenderbufferStorage'
/opt/vc/lib/libEGL.so: undefined reference to `glxx_client_DeleteRenderbuffers'
/opt/vc/lib/libEGL.so: undefined reference to `glxx_client_GenerateMipmap'
/opt/vc/lib/libEGL.so: undefined reference to `glxx_buffer_info_set'
/opt/vc/lib/libEGL.so: undefined reference to `glPointSizePointerOES'
/opt/vc/lib/libEGL.so: undefined reference to `glxx_client_DeleteFramebuffers'
/opt/vc/lib/libEGL.so: undefined reference to `glxx_client_IsFramebuffer'
/opt/vc/lib/libEGL.so: undefined reference to `glxx_client_state_free'
collect2: ld returned 1 exit status
make: *** [retroarch] Error 1

Any help would be appreciated.

[welshy]

cacophony555
If you look at the posts above between Takenover83 and myself, the new commit of RetroArch doesn't seem to compile on the RPi with latest version of Raspbian. However, pulling the previous version from the Git (to do this click on the 'Releases' Tag then download v0.9.9) it compiles and works fine.

[cacophony555]

Ah sorry, missed that. I'll try an earlier version.

Out of curiosity has anyone tried the nestopia core with retroarch?
https://github.com/libretro/nestopia

[Vanfanel]

Don't use early versions just because you can't build the current version: investigate instead and use current version!
The reason to use a Raspberry Pi is learning, not simply gaming

So, cacophony555, look at these errors and try to understand what they mean: they are undefined symbols. If you look at the end, you'll also see it's LD yelling these errors. Ok, don't panic. LD is the linker.
And what could these gl<whatever> functions belong to?
If you look for them, you'll find them in /opt/vc/include/GLES2, where the gles2 headers live in Raspbian. So...the headers are accessible but the linker can't link against the dynamic libs! Ok, ok, easy one. We just need to edit config.mk, look for the line GLES_LIBS and add "-lGLESv2", so the linker now tries to link against the gles2 libs.
We would leave the GLES_LIBS lines like this:

GLES_LIBS = -lGLESv2

You could also supply the GLES_LIBS parameter along with make, I suppose. But well, this way you can build the latest it version. Note that there have been some changes to the audio interface functions so using the latest RetroArch also means using the latest cores.

PD: The fceumm problem causing these dreaded corrupt files is fixed time ago by ALCARO, who also fixed memory leaks and various things like Famicom Disk System support
Enjoy!

PD2: Nestopia is good with games with no custom chips on them, but depending on mappers/custom chips, the Pi won't be able to keep up with perfect rock-solid 60FPS, so don't waste your time and use fceumm instead: it's as good as Nestopia without the absurd CPU requeriments Nestopia has.

[cacophony555]

Vanfanel, this is very helpful and I'm looking forward to trying it out later today. Thanks!

And you're correct, the Raspberry Pi is great for learning. I just needed a little push in this particular case

Have you compared the standalone fceux binary to the retroarch+fceux core version?

[welshy]

Vanfanel/cacophony555
There has been an update at Github addressing/fixing the makefile error on the RPi.

[cacophony555]

Yep, looks like the Retroarch compilation issue was fixed.

So I went through these steps again...

For the configure step of picodrive it says you need to install libpng-dev. I did that and then it said I need to install libsdl1.2-dev. So I did that too which installed quite a few dependencies (I used sudo apt-get install). There don't seem to be options to disable sdl, etc in the configuration step of picodrive.

The other thing I noticed is that the source that got pulled for the fceux doesn't seem to have the save file fix:
https://github.com/libretro/fceu-next/commit/45cca1838

Is that change in a different branch? If so, should I pull that branch instead? Or maybe just make the change myself manually since it looks pretty isolated to general.c ?

This thread is great so thanks again!

[Vanfanel]

Whelsy: thanks for that. Good to know it's fixed now!

cacophony555: You should NOT need ANY external library when compiling LibRetro cores. The cores use Libretro API and only that. If a core asks for anything, it means you're doing something wrong.

For PicoDrive, simply do

ARCH=arm make -f Makefile.libretro

Note we're supplying "Makefile.libretro" as the makefile, NOT the plain "Makefile" file.
It builds fine.

As for fceumm, the changes are in the github version, so you don't have to do anything special, just:

git clone git://github.com/libretro/fceu-next.git
cd fceu-next
cd fceumm-code
make -f Makefile.libretro

And that has to work!

I'm tempted to upload my precompiled cores, just to save some headaches... but try to do it yourself and learn in the process.

[cacophony555]

It was the following step that complained about missing packages, not the make:

Code: Select all

3) ./configure

It sounds like it's safe to ignore the missing package errors but it would be a good thing to mention in the instructions.

But I did already get past the error/warning by installing the packages it complained about, though. All your other instructions were followed exactly. Are my retroarch cores less optimized as a result? I'm wondering if I should try to recompile all the cores again with those packages removed, but I'm a little concerned about removing packages at this point because other items I've installed have had some similar dependencies. For example, emulation station requires libsdl1.2-dev.

I'm looking for the best performance possible with RetroArch, so if there's anything I should do let me know!

Regarding the save file bug, the version of FCEUX I pulled yesterday does seem to have fixed the issue. I was just expecting it wouldn't after not seeing the fix in this file:
https://github.com/libretro/fceu-next/b ... /general.c
(perhaps the fix wasn't the changelist I mentioned above)

EDIT: never mind, I see the fix *is* in that file, at least according to the file history. If I look at the diff of the changelist (https://github.com/libretro/fceu-next/commit/45cca1838), it looks like the following lines should be line 69-70 (line 70 was added):

Code: Select all

 #ifndef HAVE_ASPRINTF
+#ifndef __LIBRETRO__

But in the general.c file above I don't see that change. So clearly I'm not interpreting the diff correctly.

EDIT 2: ah yes, I see there was a second change that same day which makes some more changes. So everything makes sense now!

[Vanfanel]

cacophony555: You don't have to run configure scripts for any RetroArch cores. They come in "ready to build" form!

However, if you want to squeeze the last bit of performance, you can do various things:
-Add specific Rpi CPU CFLAGS to the Makefiles (or Makefile.libretro) you use to compile.
These are:

Code: Select all

-Ofast -march=armv6 -mfpu=vfp -mfloat-abi=hard

-Disable unused processes that are NOT needed for a commandline system aimed at RetroArch: ntp, lightdm, nfs-common, rsyslog, cron, dbus, triggerhappy, x11-common, ifplugd, plymouth, plymouth-log, console-setup and kbd.
You can do so using insserv, for example:

Code: Select all

sudo insserv -r x11-common

-You can also stop unused ttys from being launched on boot. Edit /etc/inittab and comment them.
This won't make RetroArch faster but will save memory. And system will boot faster.

-Use 640x480 video mode for RetroArch: you can use tvservice command to set a 640x480 video mode, use RetroArch + core, and then go back to your planel's native video mode usin tvservice again. This is the script I use to launch my NES emulator:

Code: Select all

sudo /etc/init.d/dropbear stop
tvservice -e "CEA 1"
fbset -xres 640 -yres 480 -vxres 640 -vyres 480 
sleep 1
sync
nice -n -10 ./retroarch -c cfg/nes.cfg "$1"
tvservice -e "DMT 39" 
sleep 1
fbset -xres 1360 -yres 768 -vxres 1360 -vyres 768 
sudo /etc/init.d/dropbear start
clear

All in all, you SHOULD have rock-solid, lag-less, tearing-less, smooth, hardware full-screen-scaled emulation of the following systems using RetroArch on the Pi (if you don't there's something wrong):

-Atari 2600 (Stella core)
-NES + Mappers & Custom chips (Fceumm core)
-Master System (Genesis Plus GX - DON'T USE this core for anything but Master System)
-Sega Mega Drive / Genesis + Mega CD / Sega CD (PicoDrive core: DON'T USE this one for Master System since audio is slightly broken in Master System games).
-GameBoy & GameBoy Color (Gambatte core)

Other cores worth noting are Dinothawr, NX-Engine and PrBoom. Awesome stuff!

[cacophony555]

Wow, a bunch of great optimization ideas. Thanks!

I did end up rebuilding all the cores with those extra compilation flags, and everything is working smoothly. I also grabbed the master system core you recommended.

The fact that I'm getting such great performance from a silent/small $35 device is astonishing.

[Vanfanel]

The fact that I'm getting such great performance from a silent/small $35 device is astonishing.

First you spend some hours, even days, optimizing enviroment and compiling with the right flags, and at the end you get awesome performance... isn't it the most awesome thing to do? For me, it is!! Enjoy!

[cacophony555]

First you spend some hours, even days, optimizing enviroment and compiling with the right flags, and at the end you get awesome performance... isn't it the most awesome thing to do? For me, it is!! Enjoy!

Yep, this is all extremely satisfying.

And I do think that the Genesis Plus GX core does a better job at Master System emulation than OsmOse!

[cacophony555]

Vanfanel, what would you suggest for the memory split? I currently have it split 256/256 on my 512MB model.

Also, what are your thoughts on frontends?

[Vanfanel]

I only have a 256MB Raspberry Pi. I use 64MB for the GPU, and still have a lot of free memory for gcc, gdb, vim, etc... since I have disable all those services I told you about.
I don't think >64MB for the GPU will have any impact on RetroArch performance, really, but I may be wrong.

Osmose is... ehmm... well, stay away from it and use the RetroArch core instead

My opinion is that frontends are for self-limited people. If you are able to use a commandline (most human beings are), then use that to navigate your filesystem and load programs, emulators and rom dumps: you'll do it faster and won't be wasting precious resources!

[welshy]

cacophony555
I have found certain RetroARch Cores on a 512MEG flavour RPi (PicoDrive when using CD based Titles and Pcsx_ReARMed) require 128MEG* applied to the GFX card to prevent display 'flickering', all others are fine with 64. Other programs (omxplayer for instance) appear to require this need for an additional 64MEG applied to the GFX Card when using a 512MEG RPi , but strangely not with a 256 flavoured one where 64MEG seems to be sufficient in all cases. In regards of Front Ends it depends what your application is, sometimes a keyboard is not an option (say for a Cab Build/a 'minimalist' Image for 2 Joypads with no Hub) or creating SD Card Images for friends who are not so computer literate. I tend to run RetroArch using the 'Built In' FE and AdvMENU in other instances if/when required.

* NB: ONLY with older versions of Raspbian, the latest release doesn't seem to suffer this affliction, probably due to new Drivers etc.

[cacophony555]

I have found a few roms that seem to exhibit performance issues for me, but I wonder if some of the problems occurred on the original hardware as well:

- Sonic the Hedgehog on the Sega Mastersystem exhibits quite frequent slowdown and framerate issues. The Genesis version is absolutely flawless, and honestly I'm a bit surprised they were able to do this kind of game on the Mastersystem.
- Golden Axe on the Sega Mastersystem has very choopy animation/gameplay (maybe designed that way?)
- The Legend of Zelda on NES has a tiny bit of stuttering for the up transition to the next screen, and even more choppiness when you go up in a dungeon. The left/right screen transitions are always flawless though.

I wonder if a more optimized Pi experiences these issues?