Tagged: Setup Script
eltoddoParticipant10/09/2014 at 22:57Post count: 1
I really admire the attempt to organize emulator management through the Retropie setup script, but the lack of good and current documentation and how fragile the Retropie seems at the moment is a bit frustrating.
I wanted to bring up 2 specific problems I’m experiencing with the RetroPie setup script because I have been unable to find documentation or discussion that’s helped point in the right direction.
1) Initially I started from a RetroPie 2.3 image. When I ran the setup script initially, I installed binaries to save time. When I experienced a few performance issues in a couple emulators (SNES, in particular) I wanted to try compiling from source. I re-ran the RetroPie Setup script and installed from sources with the default items selection to compile. This took a long time, as expected, but when finished, I found that most of the emulators were broken. I tried rebooting, but SNES, NES, TG16 and a few others would start to launch a ROM from Emulation Station, but would just return to the ROM list with no indicator of any error. The only way I was able to resolve the issues was a re-run of the RetroPie setup script to install binaries again, and everything worked. I guess what I’m asking here is, has anyone else has had the same issue with source based installs? Is this capability broken? Is there a plans to implement nightly binaries, and opt into Stable vs Nightly binary downloads? I’m a bit confused at the decision to do source based installs anyway since the RPi is such a slow platform and any PC or server could do it once for everyone once a day, instead of everyone downloading all sources and taking the 15-24+ hours it requires on a single-core pi. This seems very inefficient, and is the reason binary packages are far more common in common linux distros. Not everyone needs to tweak sources, right?
2) I know the N64 emulator support is in a poor state at the moment. I’ve read that it currently doesn’t run from Emulation Station. But I can find no way to debug it, and finding documentation that says what command needs to be run to launch it from the command line is virtually impossible. I wanted to try compiling from sources, but the N64 emulator doesn’t appear in the list of modules that sources are available for in the source modules list in the RetroPie Setup script. Do I have to modify a file to enable it in the modules list? Or does the fact it doesn’t show up mean that support for it is being pulled because of it’s non-functionality?
Anyway, just wanted to pass along a little feedback and ask a few questions. Sorry if it’s been covered, but I’m having a lot of trouble finding the “signal through the noise” with all the out of date, incomplete, and irrelevant documentation.Jason WhitemanParticipant10/10/2014 at 23:01Post count: 10
“I feel your pain.” To an extent.
As a general rule, the Pi in its current form does not make the best emulation platform available. The resources are limited – and some of the resource limitations come from the less-than-open source chipset, limited on-board memory, number of cores, core frequency.
I do like that Retropie is a project with two distinct paths – one that downloads binaries (even if not the most up-to-date) and one that compiles source. Although I do not always “need” to compile from source – I like all packages that allow me to. Now Retropie simply facilitates this as the original source can always be found and compiled yourself. However, sometimes patches are made or configurations to run better on Pi – and this is useful.
There are other emulation platforms out there for Pi – it never hurts to take a look at what’s available.
Emulators are mostly installed in /opt/retropie
I agree that the naming convention could be better for the directories to ease finding an emulator. As not everyone knows that “osmose” is a Sega Master / Gamegear emulator (I have to look it up) — and it would be easier to label the directory as the platform(s) plus original name — or maybe just another nesting of the directories so multiple versions can be installed:
Also if there are two different emulators that cover Sega Master/GameGear – they’ll show up here. … just a proposal. Plenty of ways to organize data.
Back to the N64:
Looks like mupen is most likely what’s going to lead to success.
On my system, something must have went wrong because I do not have /opt/retropie/emulators/mupen64plus-rpi/
I’ve previously stated build issues I encountered and this may have been one of them. Actually, looking at my retropie-setup.sh options, I do not see Mupen64 in the build-from-source options although I do see a script for it.
The basic steps in the script:
1) make/enable a 512 meg swap file
2) download (git pull) from https://github.com/ricrpi/mupen64plus
3) run ./build.sh from mupen src destination dir
4) run ./install.sh from mupen src destination dir
The mupen github site has the following instructions:
A set of utilities for automatically installing mupen64plus on the Raspberry PI
Before installation: Set the GPU memory to 64mb in raspi-config.
Set CONF_SWAPSIZE to 512 in /etc/dphys-swapfile and run ‘sudo dphys-swapfile setup; sudo reboot’
Users should run the following to install: git clone https://github.com/ricrpi/mupen64plus cd mupen64plus ./build.sh sudo ./install.sh
mupen64plus will be installed into /usr/local/bin and /usr/local/lib/mupen64plus.
Developers should do the following: git clone https://github.com/ricrpi/mupen64plus cd mupen64plus modify the ‘defaultList’ file to point to repositories you want to use. run ./dev_build.sh to download and build into ./test/. run ./cfg_developer.sh to set username/email for pushing updates, setting ‘upstream’ remotes and creating symbolic links. optionally, run ./cfg_ssh.sh if you want to use ssh keys to push/pull from github
- You must be logged in to reply to this topic.