@louiehummv Thank you so much for this. Still works today! Was having the same issue with my 8bitdo SNES30 controller. Interesting considering said controller does not have any analog sticks…

EDIT: i maybe didn't test enough -- the "remaining values are filled" in the .conf, only when run the +Start Amiberry.sh. When launch by one of the .lha roms instead, no values are filled, but the game still seem to work. They load and play anyway, did not test saving. But it's late and I've shut down for the night. Will test saving tomorrow.

Yes, saving works:

pi@retropie:/opt/retropie/configs/amiga/amiberry $ cat conf/amiberry.conf rom_path=/home/pi/RetroPie/BIOS/amiga floppy_path=/home/pi/RetroPie/roms/amiga harddrive_path=/home/pi/RetroPie/roms/amiga cdrom_path=/home/pi/RetroPie/roms/amiga lha_path=/home/pi/RetroPie/roms/amiga pi@retropie:/opt/retropie/configs/amiga/amiberry $ ls -l whdboot/save-data/Savegames/ItCameFromTheDesert/ total 16 -rwxr----- 1 pi pi 12444 Dec 20 11:36 ICFTD pi@retropie:/opt/retropie/configs/amiga/amiberry $ file whdboot/save-data/Savegames/ItCameFromTheDesert/ICFTD whdboot/save-data/Savegames/ItCameFromTheDesert/ICFTD: data

...save file exist, and I can quit and restart amiberry, then re-load the save in-game.

It's the same with either github/retropie version binary: no values are written (and file NOT created) when loading from .lha rom, saves still work at default location. Values are written (and file is created, with github version) when launch from +Start Amiberry.sh.

Edit: Launch from .lha rom, then open amiberry config and change eg. Rom path: all values are written to file (for both RP version with minimal conf, or github version with no conf.) But, if open config then quit with no change == no write values.

@Jezzer said in Compiling drivers for Deskpi:

I tried to install cmake from buildessentials but it appears that you need buster / bookworm / whatever it's called. I wasn't sure what I should be installing here... Anyone know how to do this?

cmake is already installed on the RetroPie image for the Pi4 and the buildessential metapackage is installed aswell, so compiling shoudn't be an issue. Did you try compiling and got an error - if so, can you post the actual error message here so that we can help fix it ? Do you have a link to the instructions/documentation of the drivers where the installation/compilation is explained ?

You can try adding the mali flag to your system flags, but if your system has the gles2/gles3 flags and the installed libMali also adds the proper symlinks to the default GLES library names, then it shouldn't be an issue. More details with what system/os/modifications added to RetroPie-Setup would be helpful to solve this.

----- SOLUTION FOUND -----
Posting a solution here for any CTRL+F heroes

Retroarch Quick Menu > Core Options > HLE BIOS = ON

I don't know what the setting even does, I'm just glad autoload actually works now.
Gonna put some tags below for search engines to pick up on:

lr-flycast, flycast, autoload, auto-load, auto load, crash, savestate, black screen, saves, saving, loading, loads

Use an X11/Wayland desktop session and rotate the display via xrandr/wlrandr.

@mitu No, not about something else. This game ran with a simple n64 controller, but it did also have support for another. I am only talking about running this through my xbox controller.

Older devices (GL2/OpenGLES2) cannot use glcore, since it needs at least GL3/OpenGL3 to work.

Can you elaborate on that sentence above, though?

Some cores need a specific OpenGL and/or Vulkan version to work and if the front-end driver (i.e. RetroArch's) does not support that version, the core won't work.
For instance, Flycast can be compiled for Vulkan and when started will request a Vulkan context from RetroArch. But if RetroArch doesn't support Vulkan, the core cannot start and the emulation stops.

You could just get rid of the symlink-ed Kickstarts and keep them as files in the whdboot/save-data/Kickstarts folder. Amiberry should still work and the files would be backed-up like regular files.

@mitu awesome thank you for your responses.

@retrodroid Figured out recently that filling in a 16:9 Ratio worked for me. It adjusted the 4:3 in the center of the screen.

Fill in your 16:9 screen res instead of 640:480 in the mupen64.cfg

1280 720
1600 900
1920 1080

@sleve_mcdichael Great, thank you. I’ll give it a try☺️.

@mitu said in Why is Pulseaudio no longer an option in Settings > Audio > Output?:

Is there a way to get it back?

Modify the buld script and enable it if you wish.

I was able to update using the instructions you gave me (along with that other error I was having) and all seems to be working well now!

I have NO IDEA why lr-dolphin seems to be more stable using pulseaudio (any ideas?) but I feel I get emulator core crashes by far less often when using pulse than using any other sound driver.