Raspberry Pi OS Bookworm Released
-
@mitu said in Raspberry Pi OS Bookworm Released:
@retropieuser555 said in Raspberry Pi OS Bookworm Released:
Are you using the audio over HDMI or the analog output ? The analog output works without any settings, for HDMI the audio menu in RetroPie should be able to configure it (but it's not yet automatic).Just using the HDMI audio that's output from HDMI0 with the video output, nothing unique in that regard.
-
@retropieuser555 Audio works for me in both Bullseye and Bookworm with RPi4 after i set it manually from audio settings to HDMi0 and restarted the Emulationstation.
-
@retropieuser555 said in Raspberry Pi OS Bookworm Released:
Just using the HDMI audio that's output from HDMI0 with the video output, nothing unique in that regard.
That's strange, since the default ALSA audio output is Headphones if not configured.
EDIT: which Pi model are you using ? -
@mitu said in Raspberry Pi OS Bookworm Released:
@retropieuser555 said in Raspberry Pi OS Bookworm Released:
Just using the HDMI audio that's output from HDMI0 with the video output, nothing unique in that regard.
That's strange, since the default ALSA audio output is Headphones if not configured.
EDIT: which Pi model are you using ?Just a standard raspberry pi 4 b model, can't remember the RAM size off hand.
Each time I just installed the 64 bit lite /no desktop version off raspberry pi imager, then run through the steps in RetroPie Docs Manual Install. It doesn't matter a great deal really each use case there is a solution, was just surprised the Audio worked without changes on bookworm whereas it didn't before under bullseye
-
Had issues with eduke32 on Bookworm.
It would compile OK, but would not load at all, Log showed issues attempting to set any/all Video Modes.
I tried a few different versions/branches and was able to get this one working on Pi4 32/64bit:~/RetroPie-Setup/scriptmodules/ports/eduke32.sh
rp_module_repo="git https://voidpoint.io/sirlemonhead/eduke32.git master 3191b5f41670ee9341f0298e155172c0ef760031"
I also #commented# out all the patches/diffs in the applyPatch section.
Ion Fury (in Exp Section) fails building, eduke32 fails to compile when attempting FURY=1 using this branch.
But I don't think it's needed anymore, as I can load Ion Fury just fine with this version of eduke32 mentioned.Everything I tested seems to work, skyboxes, Ion Fury, and Duke Forces.
-
@RapidEdwin08 Isn't the new commit
3191b5f41670ee9341f0298e155172c0ef760031
the master anyway that was last updated 2 years ago? RetroPie seems to point to
dfc16b0882fe6ed03aa3e9c7d4948a9ad309f23a
that is 4 years old itself.
I'd be curious if the new master works on 32bit buster anyway and could just be updated -
@retropieuser555 I tried several branches that I had luck with on other builds/devices, including the latest, and they all had same issue on Pi Bookworm, fails to set any/all video modes when loading.
#rp_module_repo="git https://voidpoint.io/terminx/eduke32.git master a9c797dcb60d4dfa2e21aed09e498132e59282ba" #rp_module_repo="git https://voidpoint.io/terminx/eduke32.git master d890364d76e1553ae7d8b5b2fbef5e333c6d6123" #rp_module_repo="git https://voidpoint.io/terminx/eduke32.git master 17844a2f651d4347258ae2fe59ec42dc3110506e" #rp_module_repo="git https://voidpoint.io/dgurney/eduke32.git master 76bc19e2e55023ea5a17c212eab0e1e5db217315"
dgurney was the only one that actually works/loads after compile, but skyboxes are broken,
The rest do not load, feel free to try yourself, may be there's a newer version will work.Edit: I did not try "3191b5f41670ee9341f0298e155172c0ef760031"
I thought "17844a2f651d4347258ae2fe59ec42dc3110506e" was newest commit... -
@RapidEdwin08 Ah you're right, I didn't notice you were looking at different user's forks, that makes sense. I'll mess around tomorrow at home, but we could just use the https://voidpoint.io/sirlemonhead/eduke32 fork if that's what works?
-
@retropieuser555 Exactly, just replace with sirlemonhead fork, and #comment# out all the patches/diffs.
Don't bother trying to build Ion Fury from Experimental Section, it fails with FURY=1, but it will play just fine with this fork of eduke32.
Ion Fury .sh
_PORT_ "duke3d" "-gamegrp /home/pi/RetroPie/roms/ports/ionfury/fury.grp -game_dir /home/pi/RetroPie/roms/ports/ionfury"
-
@RapidEdwin08 said in Raspberry Pi OS Bookworm Released:
It would compile OK, but would not load at all, Log showed issues attempting to set any/all Video Modes.
It seems to start with a strange video mode, but after changing it from the game menu, it works for me. I'll take a look later on to see why it's not working right from the start.
-
@mitu said in Raspberry Pi OS Bookworm Released:
It seems to start with a strange video mode, but after changing it from the game menu, it works for me. I'll take a look later on to see why it's not working right from the start.
Please elaborate, what setting did you change where?
I couldn't get the game to load at all to access the game menu?
I ask because this 0ld branch is still the only one that plays BloodCM for me. -
Please elaborate, what setting did you change where?
The video resolution, under the Display -> Video Mode menu.
-
ppsspp/lr-ppsspp fail to compile using v1.13.2, but both build fine using v1.16.6, plays well too.
~/RetroPie-Setup/scriptmodules/emulators/ppsspp.sh:
~/RetroPie-Setup/scriptmodules/libretrocores//lr-ppsspp.sh:rp_module_repo="git https://github.com/hrydgard/ppsspp.git v1.16.6"
mupen64plus fails to compile without libvulkan-dev, just added it to depends (thanks @mitu for the info).
~/RetroPie-Setup/scriptmodules/emulators/mupen64plus.sh:
local depends=(cmake libsamplerate0-dev libspeexdsp-dev libsdl2-dev libpng-dev libfreetype6-dev fonts-freefont-ttf libboost-filesystem-dev libvulkan-dev)
dxx-rebirth failing to compile, x4 Errors in the log:
DxxRebirth_rps_2023-10-14_031312.log -
@RapidEdwin08 Ah I got mupen64plus to function by adding in this:- https://github.com/RetroPie/RetroPie-Setup/pull/3576 I didn't touch or add anything Vulkan related.
Any differences noticed btw? Compared to 32bit Buster RetroPie on pi 4, 007 Goldeneye definitely has a small speed boost. Couple of stutters playing Dam, before I'm sure the Dam was basically unplayable it was so slow.
Facility and Runway solid 60fps, no stutters.
Also was able to get Super Mario 64 upto
UseNativeResolutionFactor = 3
inmupen64plus-GLideN64-highres
and it still played at the 30fps it runs at. Don't think that is possible on 32 buster. Was running with an overclock on both systems if memory serves. -
@retropieuser555
I did try PSP BlazBlue Continuum Shift II + Prinny Can I Really Be The Hero, and man they were both Flying out-of-the-box not touching any Settings.
I actually have not tried anything for N64 yet, but if you really want a test try out Dinosaur Planet.For mupen64plus, I got the fix from here could-not-successfully-build-mupen64plus.
I had the same error mentioned there, and same resolution.
I did not touch the swap settings, and upon looking it's already set to a static 750.lr-dosbox fails to compile instantly with multiple errors:
ISO C++17 does not allow dynamic exception specificationslr-mame2015/lr-mame2016 fail to compile with this error:
error: Cannot read opcodes file src/emu/cpu/mcs96/mcs96ops.lst [invalid mode: 'rU']Appears to be due to issue with referencing 'rU' with Python 3.11.
For a fix I got lazy and just decided to stream edit on the fly and replace 'rU'with 'r' in all the *.py scripts in the source I found that referenced 'rU'
Note: They are the same *.py scripts for both, but in different locations.~/RetroPie-Setup/scriptmodules/libretrocores/lr-mame2015:
function sources_lr-mame2015() { gitPullOrClone sed -i 's/rU/r/g' $md_build/src/emu/cpu/mcs96/mcs96make.py sed -i 's/rU/r/g' $md_build/src/emu/cpu/tms57002/tmsmake.py sed -i 's/rU/r/g' $md_build/src/emu/cpu/m6809/m6809make.py sed -i 's/rU/r/g' $md_build/src/emu/cpu/m6502/m6502make.py }
~/RetroPie-Setup/scriptmodules/libretrocores/lr-mame2016:
function sources_lr-mame2016() { gitPullOrClone sed -i 's/rU/r/g' $md_build/src/devices/cpu/m6809/m6809make.py sed -i 's/rU/r/g' $md_build/src/devices/cpu/tms57002/tmsmake.py sed -i 's/rU/r/g' $md_build/src/devices/cpu/m6502/m6502make.py sed -i 's/rU/r/g' $md_build/src/devices/cpu/mcs96/mcs96make.py }
-
The strange thing that i have saw with Bookworm Lite is that is missing overscan settings and resolution settings in config.txt file. I don't know if this is intented or a bug of Pi OS devs.
-
Glad to hear Retropie sort of already works right out of the box -- but I presume you all are testing this on a Pi 4, and not a 5?
-
@RapidEdwin08 said in Raspberry Pi OS Bookworm Released:
@retropieuser555
I actually have not tried anything for N64 yet, but if you really want a test try out Dinosaur Planet.Just gave Dinosaur Planet (02-05-23 enhanced version) a quick 10 min go this morning. The framerate counter is very low but given it's an unfinished game from Rare where they went as close to the max of the N64 without the console falling over that's not surprising.
The audio didn't stutter at all; it's probably running how the game is supposed to run as far as I can tell. I don't have an n64 or flashcart anymore to test that.
@dodonpachi yup, 64bit Bookworm Lite built on a pi4. I have preordered a pi 5 so will for fun have a go. Assuming anything will build at all, we'll find out
@windg I saw this in the
raspi-config
and thought it was strange, but then I don't have a TV or display that needs overscan changes so I'm not sure if it's just something that fixes itself or will be a problem for people who need to make that adjustment -
@windg said in Raspberry Pi OS Bookworm Released:
I don't know if this is intented or a bug of Pi OS devs.
It's intended, resolution options have been removed some time ago from
raspi-config
. The Underscan should still be available, though it's possible it's not shown in all configurations (i.e. 64bit/wayland/etc.)EDIT: to set manually the resolution, you have to edit the
cmdline.txt
file and add the options there - https://www.raspberrypi.com/documentation/computers/configuration.html#command-line-options. -
It looks that overscan settings will not work atleast for now :
From official announcement:
Compensation for displays which use overscan is tricky under Wayland, and we haven’t quite got it working yet, so this has been removed for now. The vast majority of displays nowadays don’t need it, but we will be putting it back when we have worked out how best to do it!
Contributions to the project are always appreciated, so if you would like to support us with a donation you can do so here.
Hosting provided by Mythic-Beasts. See the Hosting Information page for more information.