I had the same idea, I am trying to run RetroPie on my Raspberry Pi with Debian 11 (I can't install RetroPie on Bullseye) on a Docker container, and I am using my iPad as a screen through Remote Desktop, and a Bluetooth controller (8Bitdo Zero 2), and I can use Emulationstation (my gamepad works fine there) but when I launch any game my controller doesn't work (I don't have a wired controller so I don't know if that's the problem). I've tried to change the retroarch controller configuration and changing it to "sdl2" only works one button... I don't know why. If you don't have any issues maybe I could try your Dockerfile because it might be my setup?
Perhaps there's a way to set the location of save states?
As I had no need for it so far, that is beyond my knowledge - if you research it, keep in mind that there are more then one form of save|save-state/memory-dump: once the saves done via the libretro-functionality, then the saves done by none-lr emulators which offer such a feature and (maybe last) saves done from within the games themself (whether that means to insert a writable-image (save-disk, tape-file, whatsoever) or if it will be written next to the game-file may be dependend on the emulator/context (home-computer/console).
If your Pi has a keyboad, you can also press F4 in Emulation Station to get to its command shell, and then enter sudo nano /opt/retropie/configs/all/autostart.sh to edit the file. In the editor, press Ctrl+xfollowed yand Enter to leave and save the file (or press n to not save it). You can leave the command shell by entering exitor pressing Ctrl+d.
Finally, you can also use SSH (Secure Shell) to access your Pi. See the Docs about that.
This is the last game I want to add onto the Ports section before I map the rest of these games to the joysticks I have (8-Bitdo and the Xbox 360). After that, I'll save this image of everything I got working on here. I'll move onto the Pi5 once that is done. If it doesn't work out, I'll just delete Lord of Destruction and add that once that gets ironed out.
I was able to get the Rise of the Triad working (the wrong scriptmodule was in the RetroPie-Setup section for some reason, so I copied the updated one there), but from what I read a few posts ago, joystick controls don't seem to work. The GL port of Hexen 2 also gave me a small problem, but I found a missing pak3.pak file and it works perfectly now.
@mitu since I copied the script contents into a working script file after clearing the previous contents, I have no non working scripts now. I have to recreate this issue to even be able to upload a script. I'll work on it this week and upload it the scripts.
My only problem with this gamelist (zemmix ) is that it doesn't have any videos. On my drive, the concept is to have (most of the time) a marquee, a box (or system) and a video. Here we have a combination of 3 images in 1 file (good for SD card space). That said, I like what you have done and I put it on the drive because I don't have these systems at the moment.
@mitu Thanks, I'll try that. As for the script. It needs to be run to start the lightgun service to get the lightgun working. Only needs to be run once though. I think this is just a work around at the moment. Hopefully, once the sinden lightgun gets established, it will be integrated better with retropie.
@cnoto I'm glad you have found a use for it. I had no idea it would help with the pi zero's performance, but I'm happy it does! Thanks for letting me know about it. I thought having an airplane-mode was a crucial feature that was just missing an option in EmulationStation.
Yes, this should copy all files in /home/pi/.attract/backup to /home/pi/.attract/romlists. Beware that this wouldn't copy any subdirectories in backup, for those you'd need the -R option for recursive copying:
But if there are only files in backup the -R option isn't needed.
To make a script out of this, just put this in a text file. It is common to begin a Linux shell script with the shebang which defines the interpreter that should be used to run the script. Without the shebang, the shell will use its standard interpreter that, depending on the script, may cause problems if it handles some commands differently. RetroPie's standard interpreter is the bash, located in /bin.
Although this shouldn't be an issue with your simple script, let's give it a shebang for sheer sake of completeness:
Put this into a text file (e.g. sometextfile) and make it executable with this command:
chmod u+x sometextfile
u+x means give the file's user (i.e. owner) execute permissions.
Pro tip: If you put this file into a (new) directory /home/pi/bin, it will be found by the shell from any other directory. Otherwise you'd need to invoke it with its full or relative path. If it's in bin in the home directory of the current user, you can run it from anywhere just by its name in the command console.
As for accessing the script from the Settings section of retropie, I will have to look that up myself since I don't know that off the cuff, but I have to go to work now, so I have to put you off for later. But maybe someone else can take over this part.
Great info... I followed your steps and it works like a charm. I created file in notepadd++ - restore.romlists
@XEntombmentX Make sure you understand what that entails - you'll have to maintain the custom configuration manually. Each time a new system is added (you install a new emulator) you'll have to manually copy the new system entries from the system config to the custom one.
... the && cd build part didn't do anything, so it tried to cmake & make from the wrong dir and, predictably, failed.
Don't use && then, just have the 2 commands separately.
.. this one just built it right there in the main tmp/build/module folder. Do I want to leave it in or out? Does it make a difference?
No, but some programs enforce a separate build folder (out-of-tree build) so you may get an error when building directly in the source folder.
Also, it still made the same file, but it put it in the wrong place. So if I were to use retropie_packages.sh <module> install after this, it would be installing the old one from the "build" dir and not the new one I just built in the wrong place, so this isn't a solution.
If you change the build parameters, then do a cleanup first.
I think I could begin the build function with a [[ -d build ]] && rm -rf build to remove the dir if it exists?
I don't think that when building with cmake this step is necessary, so that's why is not enforced. This is an issue only when repeatedly re-building without cleaning up, so it's more of an artifact of re-trying the build with a 'dirty' state.
You should first compile the program separately - not as a scriptmodule - to get the cmake build options right, then add it to the build function and try it from retropie_packages.sh.