I can't edit my post (understandable, im a newbie). But if I could, it would say

Edit: I figured it out- I had become error. I was trying to be fancy with my file pathing, and I forgot the adage- keep it simple

@opa said in (Test wanted) EmulationStation : Directory interpreted as file:

Commonly known method is to make ES recognize .m3u/.cmd/etc. and, since it would be inconvenient if individual media were displayed in the game list, to give them extensions that ES does not recognize, such as .cd1 .cd2.

NB: the .cd1, .cd2 hack is still something emulator dependent, only supported by pcsx-rearmed .

I followed es-de's Directories interpreted as files and tried a simple fix to treat one folder as one game. It seems to work well in my environment.

I found this solution a bit 'gimmicky' or 'hacky', which ties the structure of the ROM/Game folders to a particular front-end. Nevertheless, this does solve the issue of displaying the individual 'playlist'/'command file' components when they should be not.

I haven't tested your patch (and I think @Lolonois has a point there), but isn't it just a launcher fix, without actually hiding the 'main' folder's contents ?

@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.

@mitu From what directory do i do the
apt install libsdl2-net-2.0-0?

It doesn't matter.

and then from what directory do i do the standalone
installation and extraction from https://buildbot.scummvm.org/dailybuild ... 6e6.tar.xz ?

and in which order?

Not sure what you mean here, your post indicated that you've already done this and you get an error when you're executing the new scummvm. Just extract the archive obtained from the ScummVM Buildbot using site with tar, i.e.

tar xJf /path/to/<archive_file>

and you'll be getting a new folder containing the ScummVM installation. You can then rename/move the folder as you like.

@mitu thanks for such a swift reply. I thought that might be the case...oh well!

@duglor I think it is not working because the emulator does not do Midi and the text in this game as i have read says that is it piped thru midi. text rather than sound.

@kokokool As I mentioned before, I have the following test report

Peripherals and Bluetooth devices (Using a BT dongle)

2.4 Ghz Gamepad = Zero input lag detected. BT Earbuds = Had to pair it via ssh, instead of BT GUI, as well as I had to install pulse audio bluetooth. However, since my dongle es BT 2.1 I sense a bit of audio delay, but no audio crackling or popping. I'll test Wiimote pairing (it takes a bit of coding before) if theres a lag to report. Video = I'm using HDMI output on a DELL LED 1080p at 50 hz. No signs of signal delay. Games/systems Tested 8 bit consoles = full speed, no sound glitches 16 bit consoles = full speed, no sound glitches (perhaps, I might test games such as DKC or Super Mario RPG to check max performance. Arcade systems ( MAME 2003 romset, FBA)= runs 100% accurate (KOF 2003, SF. Today I'll connect a spinner or a analog dice to test mapping in racing games such as pole position, etc. PORTS = Quake3 Ill runs 100% full speed (including Multiplayer-internet) if you change settings to "fastest" and set resolution at 1024x768. Impressive.

Hexen and Heretic = 100% fullspeed, no flaws

additionally I want to install retropie-Extra script modules in this machine. Wanted to try GMloader and try some apks as droidports.

32 bit= Tested heavy GPU PS1 demanding games such as, Tekken 3 or Wipeout. Both run at full speed without glitches. I'll test two more PS1 heavyweight titles to confirm this point

Sega Saturn = tested with lr-yabause. 20-30 fps max.

64 bit = this is interesting. I had bit of trouble trying to run Mario Kart 64. somehow my system reports two mupen64plus-glide64 as standalone (not libretro), which one of them worked directly, but with two issues: sprites missing at the beginning of the game (for those who know, the spinning nintengo logo appears completely and very detailed), but the menu whe you choose a car, lap, cc, etc, shows random squares so I had to guess pressing accept until I get to the racing part. the system works but at 20-30 fps.

PSP = I had trouble to compile ppsspp (standalone and libretro) on my machine.

Dreamcast = I will compile reicast today.

Kodi from Retropie-extras runs ok. Haven´t load a avi/mkv file yet
That's all for now

@Ashpool (memo to self & @Folly FYI) some notes/details I've encountered during the manual setup of the Desktop Environments (Debian 11).

some are (pre-)populating their panels/menus with icons to applications which aren't installed by the minimal DE setup itself (e.g. webbrowser in xfce) [note: removing orphaned start menu entries]. even if the network itself works fine, cinnamon integrates the network-manager into the desktop but that one is only managing interfaces not setup in /etc/network/interfaces and therefore always showing not connected/no connection [which may irritate most users] (?options?: any way to remove the network-interface from cinnamon? comment out the interface in above config and let the network-manager handle the connection?) some Desktop Environments aren't preinstalling a display manager (lxqt, mate). Stick to lightdm (as all other installs are using it), or is lxdm for lxqt a reasonable alternative?
At least configuring an autologin for lightdm is pretty easy and sticking to it would eventually avoid the need for different (2be documented) approaches towards that option. weird issues with the soundcard/sound-device: on most(/all manual installed) DEs it is muted on 1st startup and with the exception of mate simply unmuting it and raising the volume solve the no sound issue. For mate, the install of the package mate-media was neccessary [edit: and raising pcm value slider in alsamixer afterwards]: Further research needed why installing alsa-tools wasn't sufficient. Any benefits by using VMWares "shared folders" capability? IMHO SSH and RetroPies Samba shares are far more convinient ways of transfering files between host&guest. (VMWare Tools copy&pase somewhat the worst option as it is leaving most of the time its junk within the hosts temp folder(s).

Pushing needs an remote repository.

pi@retropie:~/RetroPie-Setup $ git remote -v # output cmitu git@github.com:cmitu/RetroPie-Setup.git (fetch) cmitu git@github.com:cmitu/RetroPie-Setup.git (push) origin https://github.com/retropie/RetroPie-Setup (fetch) origin https://github.com/retropie/RetroPie-Setup (push)

If you haven't added your own repository as a remote, add it first (make sure you set-up SSH keys authentication for the repository, Github doesn't allow pushing over HTTPS anymore with user/pass). Then, when you create a branch and want to push it to your repository, just

git push --set-upstream mine test

where mine is the name of your fork's remote repository.

pi@retropie:~/RetroPie-Setup $ git push --set-upstream cmitu amiberry-5.2 Enumerating objects: 45, done. Counting objects: 100% (43/43), done. Delta compression using up to 4 threads Compressing objects: 100% (5/5), done. Writing objects: 100% (5/5), 871 bytes | 37.00 KiB/s, done. Total 5 (delta 4), reused 0 (delta 0), pack-reused 0 remote: Resolving deltas: 100% (4/4), completed with 4 local objects. remote: remote: Create a pull request for 'amiberry-5.2' on GitHub by visiting: remote: https://github.com/cmitu/RetroPie-Setup/pull/new/amiberry-5.2 remote: To github.com:cmitu/RetroPie-Setup.git * [new branch] amiberry-5.2 -> amiberry-5.2 Branch 'amiberry-5.2' set up to track remote branch 'amiberry-5.2' from 'cmitu'.

@mitu i dont think its a dependency. it is something that the guys who made OpenMW, built to help with the running the game

this is what quicksliver said about in on the forum page about installing OpenMW

Also a couple notes about running OpenMW on the raspberry pi. You cant use open scene graph from the apt repository, it has to be manually compiled against OpenGL NOT OpenGL ES otherwise the game will not run. OpenMW devs recommend using their fork of OSG for better performance though that is not strictly necessary (I used their fork and it works great https://github.com/OpenMW/osg). The following cmake arguments can be used to prevent building unneeded OSG plugins and prevent bloat

Thanks!

I never played fighting games much - always liked the spaceship games - so that explains why I didn't even think of that.

@mitu

I don't know why that error occurs, I don't think RetroArch uses directly this env var - may be a Wayland/screensaver warning.

So I fixed that error regarding XDG_RUNTIME_DIR, maybe RetroArch does use it after all. I was mistaken when I said it flashed up when launching, it actually flashes up when exiting! Same for the CD-ROM warning.

To solve it, I did the following:

run:

sudo sudo -V

scrolled up a bit to see which environment variables are preserved. XDG_RUNTIME_DIR is not one of them.

I then had to edit the sudoers file (sudo visudo) and add the following in:

Defaults env_keep += "XDG_RUNTIME_DIR"

Save and exit, you can then run 'sudo sudo -V' again and you'll see XDG_RUNTIME_DIR is in the list of environment variables to preserve. Reboot the system and the error should go away when quitting Retroarch.

For whatever reason, sudo does not preserve this environment variable, and i'm guessing because Retroarch launches from the Retropie menu with root privileges, it cannot see or have access to this environment variable. Adding the above in preserves it, suppressing the error (after a reboot).

The CD error still pops up though, but not much that can be done about that at this time it seems.

FYI, this error only pops up when you quit Retroarch after launching it on its own from the Retropie menu - it doesn't come up when quitting out of a game. I guess this is because games are launched as the 'pi' user, rather than with root privileges.

My question would be, is there a reason Retroarch needs to be launched with root privileges from the Retropie menu? Maybe I am misunderstanding how it launches, but that is what it looks like to me.

Cheers!

@ExarKunIv try to use dos2unix scriptfile.sh
I think you've wrong line endings.... Because for me the script runs flawless and if it spit out errors then there is likely something wrong with the interpretion of the script caused by wrong LE.

Edit:
Okay nevermind!

@joharibk The official theme downloader in retropie-setup

@ziggurat I've managed to install ok, but login doesn't seem to work. Could you advise on how to login with usr/pqd or with code? Thank you!

Well found another bug not sure when this one crept in but the midway games need fixed again as this was changed during the refactoring.

its broke in plus as well with if you turn off bypass audio skew.

unfortunately the bypass audio skew needs fixed in mame2003 and its off by default. Since you are syncing the cores ill let you decide what you want to do with it.

Hello all, a quick PSA :)

The lr-mupen64plus-next core got updated some days ago and now is defaulting to 640x480 resolution for new installs. This resolution is a bit taxing for humble devices such as the RPI3 or less, so is strongly recommended that you set the rendering resolution to 320x240 (as it was previously the default) for these devices. Perhaps this is not necessary for RPI4, you have to see for yourself.

This can be done after starting any game and going to the core options menu in RetroArch.

It is important to note that this is not a RetroPie change, but an upstream change. We decided to not change the upstream defaults therefore it is your responsability to change this setting for your own setup.

If you had the core previously installed, the new defaults will not apply because you already have the previous resolution set in your core options.