[dankcushions]

anyone actually logged this issue with retroarch?

https://github.com/libretro/RetroArch/issues

[dankcushions]

so use lr-imame4all instead?

[dankcushions]

your file is named wrong – should be .cfg not .cgf :)

[dankcushions]

yeah.. the first 2 actions are already accomplished by the retropie-setup.sh script, so you’d need to copy parts from that. the code is available on the github.com/RetroPie/RetroPie-Setup

setting memory split should be scriptable – see stuff like http://stackoverflow.com/questions/525592/find-and-replace-inside-a-text-file-from-a-bash-command

[dankcushions]

I’d just try via the RGUI. that will prove that shaders work as they should. if shaders don’t work at all then the next/previous stuff is a red herring.

[dankcushions]

if memory serves lr-mupen64plus was originally the default, until it was discovered that the non-libretro version ran everything a lot better, than that became the default, so you have to go out of your way to use the lr-mupen64plus in the latest versions, no?

[quote=116676]3. Emulators like lr-n64 still exist in the project because some games (Only a VERY select few, but some) actually run better on it! [/quote]i’m not sure this can be true? it’s a fork so it will only ever have less changes. i think if it runs better it’ll be because it default runs at 640×480 whereas mupen64plus vanilla runs at 1080 (i think). under the same settings they would hypothetically run equally, but don’t because the lr fork is missing fixes.

interestingly, the lr-mupen64plus fork has seen a load of updates recently. it seems to have glide and gles2n64 now. might be worth revisiting! i would sooner use it as it is easier/more consistent to configure retroarch emus, if it only wasn’t previously so shoddy…

[dankcushions]

/opt/retropie/emulators/retroarch/shader/xsal/2xsal.glslp

does this exist if you look via commandline/ftp?

what happens if you open the RGUI and set up shaders from there?

[dankcushions]

there’s no point mapping the tab key. it won’t save any rebindings. see https://github.com/libretro/mame2003-libretro/issues/11

use the given retroarch cfg mappings to remap your controls.

[dankcushions]

https://github.com/retropie/RetroPie-Setup/wiki/RetroArch-Configuration

Select+Right Shoulder Save
Select+Left Shoulder Load

[dankcushions]

this is a good idea! right now lr-mame2003 has a few issues:
– the hotkey (typically ‘select’ button) conflicts with insert coin (typically ‘select’ button) meaning the latter often doesn’t work (see https://github.com/libretro/mame2003-libretro/issues/8)
– it is impossible to rebind buttons without also rebinding the core retroarch gui buttons. eg, if you change the A button to do something else than the default, then it will no longer be the ‘confirm’ button in retroarch (see https://github.com/libretro/mame2003-libretro/issues/10), which makes using the RGUI difficult.

in theory you could use per-game .cfg files to correct the key mapping for those games, and also disable the hotkey, and just do without save states/the RGUI (neither or which i need), solving both problems.

but then i’ve thought of a problem – you’d not be able to exit the game without a hotkey :( i think you can bind exit to a single button, but i don’t like that either (easy to do it by accident). dang…

[dankcushions]

when do you have the black border? around the initial emulationstation GUI or only during games?

[dankcushions]

i get the same thing with PSX files.

i know the fix, but i was thinking – are there any reasons to have things like .cue files in the list of file extensions? as if you a .cue, it would need a .bin to be work anyway, so having .cue and .bin in the extension list will always mean you get 2 images (or can .cues can be linked to a binary file of ANY arbitrary extension?)

as in, are there some of these extensions that could be treated as “pairs” – as long as you had one, you must have the other, so only one needs to be in the list?

just a thought :)

[dankcushions]

do the same peripherals work fine if plugged in directly to your pi? none of these ‘sound’ like hub issues, especially if it’s externally powered.

there’s a compatibility list on http://elinux.org/RPi_Powered_USB_Hubs but that’s more aimed at people powering their pis from the powered USB hub. i wouldn’t expect the hubs themselves to have issues just powering USB devices, if they are externally powered, but maybe it’s possible.

i use a belkin slim 4 port powered hub. works fine.

[dankcushions]

this retroarch input issue is known to retroarch but they don’t want to fix it: https://github.com/libretro/RetroArch/issues/2230

[dankcushions]

i have a feeling mednafen will be sub 1 frame a second. it’s a dog on high spec PCs. pcsx rearmed is optimised to the hilt for arm CPUs.

you could try logging an issue on pcsx_rearmed’s github page – https://github.com/notaz/pcsx_rearmed/issues – i had a search and couldn’t find anyone else asking. i’d like the old logos too :)

[dankcushions]

/opt/retropie/roms/snes isn’t the right folder. it shouldn’t even exist!
if memory serves, the /opt/ directories should just be
/opt/retropie/emulators (the actual executable files for the various emulators)
/opt/retropie/configs (the config files for the same)

all roms are transferred to and run from /home/pi/RetroPie/roms – the contents here should match what you see in emulationstation.

8. not sure, sorry :(

[dankcushions]

[quote=116249]1. Tonight I built a splash screen, put it onto my USB stick and put it into the Pi. I booted up, the Snes option is still missing and the RetroPie sub-menu is back to single words – see attachment.

Restarted without USB stick in, same. Ran RP setup – binary installer… then after a restart it is now behaving. This seems really strange. Am I getting something wrong or does the SD card seem faulty? I still have rom files deleted in File Manager that appear on the menu’s. I’m selecting them, F8 – ok and when I finish I press F10 to exit. Hmmm.[/quote]
looks like there’s an outstanding issue with the USB transfer here: https://github.com/RetroPie/RetroPie-Setup/issues/1211

i can’t explain your other issue. i’ve never deleted roms from the file manager, but you can use command line to find out exactly what is in these folders. just go

cd /home/pi/RetroPie/roms/snes
ls

then you should get a list of everything in the snes folder (change snes to whatever system you’re deleting from). if file manager isn’t deleting things properly then i guess it has a bug, assuming you’re deleting them from the directory above?

8. try it with someone elses splash video (eg one of the ones you’ve seen working online). if that works then it must be how you’ve encoded it.

[dankcushions]

1) what does it say when you navigate into the Roms folders via command line? I’m guessing they didn’t transfer properly or are in the wrong format. I’m not clear on how you’re copying files. you don’t need to leave USB the stick in using the USB transfer method – just long enough for them to transfer

7) this is normal. you can see what games run well (and using what plugin) looking at the n64 compatibility spreadsheet on the wiki.

https://github.com/RetroPie/RetroPie-Setup/wiki/nintendo-64

[dankcushions]

[quote=115931]Ok, so I can’t do the first USB method as I’m in Windows (So, as you said, there’s only the 56MB partition available)[/quote]
i’m not sure i understand this. you don’t need to see the SD card file structure on windows if you’re doing the USB method – (reiterating the video) you put the USB in the pi whilst retropie is running, and it will create a folder structure. connect the USB to your pc then put the roms in the relevant directories on the USB, and then you put it in the pi and it will transfer everything to your SD card. you never need to access the SD card on your PC.

[dankcushions]

/tmp/runcommand.log will have information in it after a successful OR unsuccessful rom load. you must be looking in the wrong place. try running a rom that does work and checking for it.

are you reinstalling your system and then doing all this USB drive mapping before you actually get a neogeo game to run? it’s difficult to see where your problems are because you seem to be doing lots of things at once. a fresh retropie install will run a correctly sourced neogeo rom, if it has the right bios installed. there’s no configuration needed.

[dankcushions]

each rom should be a .zip with several files inside. the bios should be another .zip called neogeo.zip. both of these should be in your neogeo folder.

what’s the runcommand.log say?

[dankcushions]

the runcommand.log resets every boot i think. to get it to popualate you need to run the game that doesn’t work, and then look.

to check a rom matches the romset you require: https://github.com/RetroPie/RetroPie-Setup/wiki/Managing-ROMs – scan romset

i’d sooner start afresh – it’s probably going to be a nightmare downloading odd roms as you never know where they’re from. just download a complete set.

[dankcushions]

try going into https://github.com/RetroPie/RetroPie-Setup/wiki/runcommand – to find out the exact emulator you are using. there are a couple of versions of mame4all, and 5 different mame emulators total!

i’d also try another system to (NES/etc) which have a less variables to see if they work fine, which would rule out a system-wide problem.

[dankcushions]

I’ve also tried lr-fba-next but it automatically quits, even when using the right romset.

Does anyone have any suggestions? It seems like everyone loves PiFBA and they do say that they work fine in the list so I must be doing something wrong. I’m putting the .zip files in the FBA folder. My Pi2B is overclocked to the Pi2 setting. I am using the latest update of Retropie. This seems to be limited to Capcom as games from other companies work fine.

first things that spring to mind:
– Pi2 overclock setting is incredibly aggressive in terms of SDRAM speed. I wouldn’t be surprised if it’s causing issues. there’s issues logged against this but the raspi-config project seems dead.
– i use fba-next fine. you must be using the wrong romset or some other issue.
– i personally run all those games fine in lr-mame2003 (needs a different romset, of course), so i can’t confirm if they work in pifba, but at least some of them are confirmed as ok on https://docs.google.com/spreadsheets/d/1OZioLrz16ptaNbjQUDP5hhVzQDTOTn9Nz46Hbj3-06k/edit#gid=906957951

[dankcushions]

what emulator?
what game? (is it all games?)

[dankcushions]

this work has been done already:
https://github.com/RetroPie/RetroPie-Setup/wiki/Managing-ROMs

scroll down and there’s datfiles for working/no clone sets for most of the mame emulators in retropie, and instructions for how to use them.

[dankcushions]

the es_system.cfg change is one way of doing it, and the symlink way is another. you appear to have done both and that will just make both not work :)

the symlink instructions posted by @smartroad are exactly how i did it and a perfect tutorial for that method IMO. you can’t get it any simpler because it needs all those steps. it’s not particularly easy because you’re trying to get around the fact that linux assumes USB is temporary storage, and make it treat it like a static drive.

the es_system way is just to edit the es_system.cfg to point to the relevent directories on the USB drive. there’s videos on this:

note you also need to turn off the USB rom service in the retropie setup menu, for both methods.

[dankcushions]

i go one step further and symlink the entire roms directory, so i just have to do it once if i reinstall. i copy all the ‘default’ roms to my USB stick beforehand, and use the same filestructure

[dankcushions]

[quote=115321]
Just like you, all four of my DS4 controllers work perfectly fine in EmulationStation. Then you load up a PSX game, it says the Sony Computer Entertainment Wireless Controller is Configured to Port #X” where X is 0 to 4 respectively for each controller. However I cannot for the life of me seem to get the 3rd and 4th controllers to respond in RetroArch emulated games.
[/quote]

this isn’t libretro/retroarch issue. pcsx-rearmed (the playstation emulator) does not support 3/4 player controllers: https://github.com/notaz/pcsx_rearmed/issues/43

your controllers should work fine in libretro mame cores. consoles like the snes need a special configuration to support 3/4 players (it’s in the wiki/forums)

[dankcushions]

why not use the non-libretro version? it works much better and it’s easy to use a specific video plugin with the runcommand. i think it’s the default on current versions of retropie

[dankcushions]

https://github.com/RetroPie/RetroPie-Setup/wiki/MAME

Controls

AdvanceMAME and Mame4all-Pi have the same method in setting up controls, imame4all-libretro utilises RetroArch configurations

AdvanceMAME and Mame4all-Pi

While in a game press Tab to open the menu to set up controls

[dankcushions]

that was great – cheers florian, jools and herb!

[dankcushions]

if the libretro version is slower you should add a comment to this issue: https://github.com/libretro/libretro-ppsspp/issues/12

it must be some relatively simple config issue, but it won’t get fixed unless we raise it :)

[dankcushions]

it’s /tmp/ you need to go right to the root and then access /tmp/. most ftp clients will have a text box where you can just type that in

[dankcushions]

there’s an open source graphics driver headed to the pi in march 2016 (hopefully) which supports opengl 2.1. not sure if that will help…

[Author]

Posts