Just to note the binaries for the RPI have been updated.

@zebanon said in I’m having a chromium problem in the pixel desktop from the port section of retro pie:

As the title suggests I’m having a problem with chromium on the pixel desktop that is located in the ports section on retropie, and if that explanation is too confusing it’s just the pixel desktop that you install from the raspbian related tools in the retropie setup section in the retropie consoles and stuff menu.

Anyways the problem I’m having with it is the entire tab appears diagonal, aside from the outer box that defines the boundaries of the tab itself, the problem doesn’t appear with anything except chromium. Note that this is the pre-installed form of chromium that is already there when you first start up the pixel desktop, and not a form of chromium that I installed later, also note that this problem persists even when re-installing the entire retropie image.

Thank you in advance for any and all help.

(Heck it won’t let me remove the “pixel” tag

I had the same issue and resolved it by manually installing rpi os, then retropie on top of it. A 3rd person has reported the issue in this thread but the way to solve it is there until its solved on the developer end.

https://retropie.org.uk/forum/topic/30627/pixel-desktop-no-taskbar

@mitu said in PS4 Arcade Encoder Disables Audio on Pi3 B+:

Please add some info about your setup, as detailed in https://retropie.org.uk/forum/topic/3/read-this-first.

This info is missing.

@mitu Yep, exact same name, cut and pasted to avoid any errors. I think this is a hopeless case tbh, the saves I'm using behave extremely weirdly and I suspect there's just no chance of transferring them over but it never hurts to ask in case someone knows of a conversion tool or the like.

@bberlin1 This kind of functionality would be provided by the emulator (RetroArch with lr-pcsx-rearmed or lr-duckstation), but it's not present at the moment.

RomCenter and Crlmamepro doesn't run on RPi, not without wine or mono at least, and even then they require xorg. While it's unlikely people will get their games on their Pi without using PC, there might be some instances where a user has copied the files off of another SD card or USB, or is trying to restore the roms from backups, and didn't do any validation/comparison between the two before moving the files. Or they did, but the comparison came back the same, despite the source files being corrupted.

At the very least if the games don't match the checksums, they could be made aware that the dump isn't clean, got corrupted when transferring, or the source was corrupted and copy matched the bad source. I've been updating my µSD card a lot, getting larger sizes, and as such I've been copying the games from one SD to another, not using PC, and as such have to a ton of extra steps to try and make sure my games didn't get corrupted, either on the source device or through a bad transfer. While it might be easier to just save everything to a USB thumb drive that can be read on Windows, the problem there is constantly knocking into the pi and potentially breaking or disconnecting the USB stick.

I've found that one can use the RetroArch DB files to verify many games, including Dos CD games, with a command line program they provide with their source. However integrating it either into emulation station, rom scrapers, or some browser based gui is something beyond any skill I have. I'm learning and trying to figure out how, but I doubt I'd get anything close to PoC soon.

@ashpool LOL -- great minds think alike! I tried the virtual keyboard, too, and it works PERFECTLY! For some reason, S, Z, and a couple of other keys don't work on the hardware keyboard, but honesty as long as everything works on the virtual keyboard, I don't mind.

Thanks for helping me figure this out! Off to save Skara Brae...!

@mitu yes, that is the file. Unfortunately I don't recall if I configured it with the Forced option during my install, but if you say that script is used only in the Force mode then I very likely did. Let me go back and reinstall to see.

Regardless, if that mode is available, some people will use it, and will run into this issue, even if as you say it is not recommended. In such cases hopefully their search will turn up this post.

Based on this output, I think you'd need to set in EmulationStation the Audio Card to Device.

To get the name of the mixer (volume control), run

amixer scontrols -c Device

and choose the 1st entry and set it as Audio Device. For instance, in my case, the USB audio card is named 'Controller':

amixer scontrols -c Controller Simple mixer control 'PCM',0 Simple mixer control 'Headset',0

I would use PCM as the AudioDevice settings in ~/.emulationstation/es_settings.cfg:

<string name="AudioCard" value="Controller" /> <string name="AudioDevice" value="PCM" />

This should fix the audio not working (or the volume slider rather) in EmulationStation.

For Amiberry, I'm not sure why it's not working - maybe it's trying to use the 'default' card and it's not working ?

Try following the advice here and create a /home/pi/.asoundrc file containing

defaults.pcm.!card 1 defaults.ctl.!card 1

@iandaemon Mainly the file size that I'd save in using Gifs rather than a video format - oh and I could make my own backgrounds and animations easily myself too.

alt text

@mitu said in N64 Controller Setup - Inconsistent Documentation:

@busywait said in N64 Controller Setup - Inconsistent Documentation:

If you don't have a 'retropad A' button defined, of course it's not going to work in the menu . My remark was:

How the button is mapped to the underlying core doesn't matter for the menu (RGUI or otherwise).

I agree, but the reason that I don't have a retropad A button defined is because the core doesn't use it for it's logical function in the mapping. I could have had both [N64 "A" and RGUI "A"] if the core used different bindings.

Obviously this is a minority problem for people trying to use pads without the full set of retroarch inputs, and I can still navigate the RGUI using a keyboard in my case :)

@venkman383 please provide more information

See https://retropie.org.uk/forum/topic/3/read-this-first

Please give an example of a file that doesn't work. A logfile will be useful. Which ROM files did you install and to where? Which lha files are you trying?

@g30ff YES! That was the best advice someone could give me at this moment! It worked! Big thanks!

Edit: Regarding the shell script. Should have quoted...

@dankcushions
Yeah, I checked the sites myself and had no issue. I don't see how it could be the connection on the Pi, though, since the wifi works for anything I do via the GUI - both the main Retropie interface and the setup interfaces. Scraping, updating, etc, all works until I go into the terminal. I'll probably have to seek help elsewhere as I suspect that's still outside of your ability to assist.

Thanks for the help, though. I at least now know some stuff to look at should other problems arise in the future.

@fadangalini had one as a kid as well. Virtua racing and Virtua fighter are worth checking out.

Another option:

I use a bezel that I made. Get asteroid.png and asteroid.cfg from here if you're interested. https://github.com/busywait/retroboxes/tree/main/overlay/Asteroids

I've tried lr-mame2003-plus and lr-fbneo. They need different ROMs, get the correct one from a relevant romset.

lr-mame2003-plus has more control over vector lines, but the screen is slightly squashed in height (black unused space at the top and bottom). The screen shot below shows that problem.
asteroids game with a bezel running in RetroArch

You can scale the picture to be a little taller, but then motion doesn't look as smooth. So, I use lr-fbneo.

With either core I used with the "normal" resolution, and integer scaled 2x to fit my bezel in the retroarch video options.

I don't use a shader. I do run with video_threaded = "false" to reduce latency by a frame. (I can't remember if I tested if that actually made any difference! I assume that it's taken away 16mS of lag).

@ericsnis said in Remapping buttons for runcommand.sh:

Is there a way to remap the buttons used for runcommand without messing up the mapping for games?

runcommand will use the RetroArch configuration file of the gamepad. If you didn't generate one - it's automatically done when you configure the input in EmulationStation - it doesn't which buttons are A/B to enable them in the launch menu.
Since you copied the ES configuration for input, and didn't run the input mapping dialogue, the RetroArch configuration file hasn't been generated - hence the missing mapping in the launch menu of Runcommand.