@quicksilver that's strange as it now gives out High Res graphics on games whereas it never did before I'm sure of it. It was because of this that I tended to go for the Mupen64plus - GlideHighRes options as on some games it just looked great (No Mercy, Super Mario 64) I'll have a look around for the post and update on this thread. I'm probably just getting confused as they're all called Mupen something or other. Thanks!

Try lr-scummvm from experimental packages maybe is working better with your gamepad

@dingus73 said in Cocktail Arcade Configuration - #retropie:

I've inserted the "display_rotate=1" code (as well as 0, 2, and 3) but no luck.
...

The display_rotate options are not supported on a Pi4 model. You have other options to achieve the rotation - see this topic.

For display flipping, I think this may be supported by emulators natively, but you have to go into game's service mode and enable it (i.e. simulating the machines service DIP switches).

@mitu Weird, I wonder why it does that? Is there a way for Duckstation to not change the audio?

@sleve_mcdichael

OK, I fiddled with it for like two hours and I found the culprit!

I restored backup of my "bad config" and it was lagging and doing 30 frames per second - as expected.
Then I started deleting lines half of the file at a time and after a lot of problems with auto-generated cfg in NES folder, I found that removing this line stops the stuttering:

video_vsync = "false"

To double-check it, I restored the original "retroarch.cfg.rp-dist" and added this line - it's 100% reproducible on my system. Put it on "false" and it's choppy, put it on "true" or remove it and it's not choppy.

Without this line, it is:
-> not choppy with vsync ON and any setting Max Swapchain images
-> not choppy with vsync OFF and Max Swapchain images 3 (default is 3).
-> choppy with vsync OFF and Max Swapchain images 1 or 2

If I put this line in, it's choppy whether the vsync is OFF or ON
-> It's choppy with vsync OFF and any setting Max Swapchain images
-> it's choppy with vsync ON and Max Swapchain 3 (default is 3)
-> it's NOT choppy with vsync ON and Max Swapchain images 1 or 2.

I guess something happens when retroarch.cfg has 'video_vsync = "false" ' line and Max Swapchain images is set to 3, behaviour is the same with Max Swapchain 1 and 2.

Also - why would vsync OFF make it choppy? It should make it less choppy with some potential screen tearing - it makes no sense!

Hm, save states are not portable also between emulators, so as a starting point you should use the same emulators when testing.

But since you're using a Pi 0, the same emulator from the Pi3 may not be available or perform well enough to be a viable alternative on a lower spec system.

@mahoneyt944 good question, I think it is 2003 actually: will try 2003+ and report back. Thanks a lot

@deltagemini Strange but good it's resolved!

@mitu amiga.opt removed and looks like it works with menu widgets enabled,will test it

@mitu can I add this manually?

Not likely, the version used in Batocera is further modified than the RetroPie's fork and it's not a matter of configuration.

Or recommend to developers of retropie/emulation station to add this function?

Sure, you can add a request.

If a hotkey_enable button or key is defined, no hotkeys will function unless the "enable" button is also pressed at the same time.

By default, there is no hotkey_enable keyboard key defined. With only the keyboard connected, the hotkeys will work individually.

But when you connect a USB gamepad, that gamepad's autoconfig is applied. The autoconfig does define a hotkey_enable button on the gamepads (usually Select).

In order to use keyboard hotkey functions when the gamepad is connected, you must either:

press the gamepad's hotkey_enable button while you press the keyboard hotkey key, or define a keyboard hotkey_enable key and use that, or remove or #disable the hotkey_enable function from your gamepad's autoconfig (you'll also need to remove or disable all other hotkey functions that share a button with any game action buttons), or unplug the gamepad.

Hotkeys only work on the keyboard or on P1 gamepad. If the gamepad is anything other than P1 it won't work, but it still defines the hotkey_enable so you still have to use it, one way or another, while the pad is connected.

@standarsh14 said in RetroArch won't distinguish between two controllers:

It seems like either controller will work with one registered bluetooth connection - which confuses me because I thought that with separate Serials, only the one registered would work.

That's unexpected, the controllers should have different MAC addresses (they appear in the pairing dialog) so the OS would be able to tell them apart and some pairing info to be also stored on the device itself. Deleting the device from the list of paired Bluetooth devices in RetroPie should force the gamepad to be re-configured.

With both devices connected, can you run

cat /proc/bus/input/devices

and post the output ?

You can also test with jstest if the controllers are acting separately. Run:

jstest /dev/input/js0

and press the buttons on 1st, then on the 2nd controller. Only one controller should yield any events/output on the test.

@dankcushions

Ah!

I'm not working with the best screen and, with black on gray, that's just looked - well it was unclear to me. 2 years ago I'd have probably remembered it, from the other system I've mentioned, but on the screen I'm using now (usually devoted to something else), it's hard to see. (I have to change terminal settings on most of my systems to use something like green on black that look like the old phosphor monitors so there's good contrast.)

Okay, I'll use that later today when I'm at over where I have that system.

(This is a temporary environment for it - I'm setting it up to send to a relative who has just moved out of his house, so this is something for him to do when he's stuck in his apartment at night, alone, without a wife or kids anymore. He has some game consoles, but has never had anything like RetroPie.)

Just wondering - is there a reason that notification is in something lower contrast like black on gray instead of something like red or green for the text? (I realize it's on a black screen, so you can't use black as a background.)

@mitu Thanks, I found it.

@mitu thanks for all you help and tuition on command line earlier. FYI the recently purchased Retoflag Controller IS detected by Retopie and it allows me to set this up. Two buttons aren't being detected in the configuration but are in jstest so one for me to delve into but think I have half a clue what I'm doing now thanks to you.

Morale of the story here is make sure you purchase a recognised, compatible gamepad first....

@GreenHawk84 which version of Emulationstation are you running?

There has been a corner case [1], which escaped my mind in the first place, but then has been corrected by @pjft .

If your ES is below 2.10 (which I assume):

Either update to 2.10 onwards If you don't want to update use this workaround: Edit your ~/.emulationstation/es_settings.cfg while ES is not running and check the value of SlideshowScreenSaverCustomImageSource. Make it read false (you can also do it during ES is running in the Screensaver Options Menu).

Rationale: Your behaviour can happen on ES < 2.10 if you set your slideshow screensaver to use a custom image source and then switch to video screensaver (without disabling the image source flag).

Please report back if it solves your issue. And if it does, mark this topic with [solved] in your initial posting header.

[1] https://github.com/RetroPie/EmulationStation/commit/a8ccd0a75ba81b3e4af88ed3ebcfe08e57520ab6

@deskjobo

@deskjobo said in SAVE STATE STUCK AT 0% ISSUSES:

@theotherdan Thank you so incredibly much for your response. I followed both sets of steps you gave, and my results are as follows:
After using df -h my available storage is shown to be 785M out of 3.3G size.
For the command ls -al /home/pi/RetroPie/roms/ all the emulators appear to have 'pi' in both the user and group, as well as all the correct modebits.

Is 785M enough of an available storage or could that be the cause of the problem?

ps. All my roms are stored in a usb drive instead of in the sd card with the image.

@deskjobo
785M will be 785 Megabytes, so a decent amount of space. For save states, I would say that space is not an issue..
Now, since you are not using the default location for saving, you will need to adjust the process a bit.
You can look at /opt/retropie/configs/all/retroarch.cfg by running 'cat /opt/retropie/configs/all/retroarch.cfg'. This file should show you where the save states and saves games are stored:

#Save all save files (*.srm) to this directory. This includes related files like .bsv, .rtc, .psrm, etc ...
#This will be overridden by explicit command line options.
savefile_directory = "/media/usb0/savefile" <--

#Save all save states (*.state) to this directory.
#This will be overridden by explicit command line options.
savestate_directory = "/media/usb0/savestate" <--

Based on the output, and where the USB device is loaded, you will have to append the command to meet it:

sudo chown -R pi:pi /media/usb0/<emulator>

Let me know how that turns out.

Use the Show IP entry in the RetroPie system and it will show you the available network adapters, with their MAC:

...
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DORMANT group default qlen 1000
link/ether dc:a6:mm:aa:cc brd ff:ff:ff:ff:ff:ff

The apidocs are also available at https://retropie.org.uk/api/.