@Lolonois said in Run Spelunky and other Android Game Maker games on Pi5 / arm64:

On a Pi5 with 64bit RaspiOS AFAIR the SDL2 scriptmodule installs also the 2.26.3+1rpi_arm64 (from sources). Thus I assumed this RetroPie SDL2 version is needed also on the Pi5/arm64 for some reason.

On non-X11 platforms, RetroPie always tries to install its custom SDL2 version. You can bypass this if you want, but you'll be missing the kms bits which allow runcommand's resolution settings to propagate to SDL2 applications (emulators).
You can bypass this by setting own_sdl2=0 in retropie.cfg.

My question is like this then:
When a RetroPie SDL2 lib is found on a Pi5/arm64 do also install the counterpart on armhf?

Technically I don't think you'd be able to have different versions, one for each arch. But things are no so simple, see this issue and the discussion around it.

-or-
Whatever version of SDL2 is installed (or even if it is absent), replace it with the one from the upstream package for arm64 and armhf?

You override the install flag (own_sdl2) so you can use the distro's packages, but with the caveats explained above.

@Jesuszilla thanks for the reply, hadn't seen it until just now. i'll be patient then. been running mugen with wine :)

@Lolonois said in Adding console Vircon32 to RetroPie:

Other than that I think your virtual console fits in well into Raspberry Pi and RetroPie universe as it allows everyone learning by inspecting and adapting the code.

That was my intention. The console is designed to be very simple and it is fully documented. All my programs and games are open source too. (And games are free, so no problem to distribute the roms).

About the Pi versions, this core has only been tested from Pi 3. I don't think the Pi 1 is powerful enough to run Vircon32. And I have no idea about the Pi 2.

My core builds for Pi 4 have always been done with flag -DENABLE_OPENGLES3=1, so that is what the binary at GitHub release v1.3 should be. In fact, if you try to build the core without GLES3 it will succeed, but it won't run (in my system at least). With GLES3 it does run the games.

EDIT: Still, if you need me to generate some other binaries from the Pi's I have (3 and 4), I will try to do it.

@retropieuser555 said in Dolphin - GameID Identifier script help:

What's interesting with EmulationStation is when it's entering the controller into es_input.cfg the SDL Device name isn't the same as Dolphin's Device naming convention. Possibly because they use different SDL versions.

No, they don't - how would they ? SDL is provided by the OS for both applications.

If it did, I would've followed mupen64plus.sh's process that using the mapping of EmulationStation as the basis from which to enter into Dolphin. But it doesn't seem possible as the Device Name isn't consistent it appears.

It's not always consistent, SDL applies some normalization to the gamepad name or straight out renames it - differences may appear in some cases.

I think the evdev Linux input-event naming is documented here:- https://github.com/torvalds/linux/blob/master/include/uapi/linux/input-event-codes.h#L379 Which does appear to show that the controller will be mapped to a BtnSouth etc, which Dolphin is interpreting with it's own naming (Dropping the Btn and capitalising the SOUTH for example).

Maybe, but that's not so relevant.

I'd need more controllers to test this with, but based on the input-event-codes above, every device mapped to a js Handlers will conform to this.

Not quite - the user is free to map their controller how they wish, you can't assume a certain mapping based on the gamepad ModelY. They can even change the mapping as they wish (use B as 'A' and vice-versa).

It'd be a shame if it's left on the backburner, anecdotally Dolphin does seem to be the most consistently queried system on RetroPie recently due to the pi5

Yes, the 'noise' is certainly bigger right now for Dolphin because of the Pi5, even though the results are not as expected. But itsn't it enough to map your controller in Dolphin GUI once to have it configured ? I don't see as a big issue to be honest.

@amtimes546 RetroPie doesn't develop daphne neither any other emulator, meaning your triple-post suggesting daphne's future developments is entirely meaningless.

@Lolonois said in Quake 2, 3D accelerated in any Pi model, 60+ FPS:

Nice. So does it also qualify for a PR to RetroPie-Setup? (I assume as the scriptmodule is from the experimental section and the change is not large the bar to get it accepted might not be that high.)

I don't know? RetroPie guys prefer to work with official releases, even for experimental, so we may have to wait for YQ2 version 8.50.
@BuZz, @mitu, would you accept a PR pointing to a specific commit, as a temporary thing, waiting for the next big release?
It's just to make this project visible, and it's not like numbered releases are a guarantee for stability.

@shift

Added m5 with cassette support loading basici :
https://github.com/FollyMaddy/RetroPie-Share/commit/0bc737c3c2c8389ea8f29370f1f1263038284404

@rfinnie I guess the min/max values are not a strict specification, thus I said "should". It depends on brand/model as I learned (mine Logitech Rumblepad and a knock-off Switch/XBox controller report in the "should" range).

On a tangent: The Arcade'81 looks nice and gives you at least enough space to add a subwoofer. I added an external subwoofer 6.5" later to my custom bartop which made the games even more fun to play. In any case: Happy tinkering!

But back to your initial request/idea. Maybe @pjft can comment on that, if a or which suggested change (see first post) would be accepted in the ES source tree.

@jose1711 said in Tesla PMD-85 computer in RetroPie?:

multi-game tapes (such as games-1.ptp) are lacking information about the position of the game on the tape - is trial&error the only option

Pretty much, combined with using savestates.

What I do is, if I've got a tape with (say) five games on it, I make five copies of it and give each one the name of a different game.

Then I load the first one, note the tape count, and make a savestate at the start of the game.

Then I go to the second file, start it at the tape count I just noted, load the second game and make a savestate at the start of the game. And so on.

Now I've got five files in the EmulationStation menu called GAME 1, GAME 2 etc (even though they're all technically the same file), and all I have to do is boot them up then load the savestate to play them instantly.

Found it. I was misled by the official Rpi documentation.

rpi_config_txt_video_option.png

The solutions below only refer to the display rotation, see notes.

Solution 1: Legacy video driver config.txt: Neither dtoverlay=vc4-fkms-v3d nor dtoverlay=vc4-kms-v3d enabled, but display_hdmi_rotate=2 cmdline.txt: No video=... option

Note: The RetroPie Image for a Rpi3 ships with the legacy driver enabled. The EmulationStation binary is compiled against that driver and works out-of-the-box. This should also not affect any precompiled emulators.

Solution 2: (fake) KMS and Kernel option config.txt: Either dtoverlay=vc4-fkms-v3d or dtoverlay=vc4-kms-v3d cmdline.txt: Add video=HDMI-A-1:1280x1024@60,rotate=180. Note the use of HDMI-A-1 and not HDMI as the documentation (see above) states currently. (I have a PR filed for that.)

Note: You will have to source build emulationstation with that config to make it use the video driver. I did not testdrive any emulators with this solution.

@mitu Thank you for testing!

I'm happy to see results that my fix worked without breaking anything.

I also created a minimal dataset to make it easier for others to reproduce and test the problem.
Extract this and replace the emulationstation folder with your ~/.emulationstation. (Backup is needed)
When you start EmulationStation, (if you have DroidSansFallbackFull.ttf installed,) it should look something like this:
EmulationStation_screenshot.jpg
There are 100 dummy ROM files, so try scrolling through them by pressing the down arrow key⬇.

In my environment, the results were as follows, depending on the screen resolution:

emulationstation --resolution 720 480
→ no problem emulationstation --resolution 1366 768
→ Scrolling through the game list works fine, but then the main menu appears broken emulationstation --resolution 1920 1080
→ Crash when pressing ⬇ 43 times emulationstation --resolution 2560 1440
→ Crash when pressing ⬇ 21 times emulationstation --resolution 3840 2160
→ ES won't start

And when I included my fix in the binary, all of them were displayed without any problems.
We hope that this will encourage more people to test it and get good results.

@ecto @Folly I was speaking to a guy that fixed Etoile Princess and added some MIDI enhancement in the Core. The changes are already uploaded to px68k core. So update the core :)

And another by Sega which can now be played in 2003+

A B COP
abcop.png

@phillip_benoit I've been doing PRs to a respectable number of open source projects for a few years now, and from all of them, only one of the projects has consistently reviewed my PRs in under 3 weeks. If the project is popular and is handled by few people, you should be accustomed for them to take several months to look at your PR.
I would rate RetroPie as one of the most decent projects I've contributed to, in terms of pull requests accepted and time taken to evaluate them, especially considering the small number of people working on it.
My point is: you can change projects, but it's no guarantee that you won't be ignored on the other side as well. "Occupational hazards" I guess.

@Lolonois said in Skyscraper is back! (v3.12):

Implementing a batch of community suggestions, all details here

Hm, here points to localhost, probably should be https://gemba.github.io/skyscraper/CHANGELOG/#version-3120-2024-07-01 ?