@retro777
one things,, new report

my emulator.cfg is here

ikemen-go-nightly = "XINIT:/opt/retropie/supplementary/ikemen-go-nightly/ikemen-go.sh %ROM%"
ikemen-go = "XINIT:/opt/retropie/supplementary/ikemen-go/ikemen-go.sh %ROM%"
default = "ikemen-go-nightly"

and, run .mgn on emulation station,display this.

"No config found for system mugen"

Which place do i check and fix??

es_systems.cfg here

<system>
<name>mugen</name>
<fullname>M.U.G.E.N</fullname>
<path>/home/pi/RetroPie/roms/mugen</path>
<extension>.mgn</extension>
<command>/opt/retropie/supplementary/runcommand/runcommand.sh 0 PORT mugen %ROM%</command>
<platform>pc</platform>
<theme>mugen</theme>
</system>

@mitu thanks for the heads up, will do.

@retropieuser555 said in Dolphin - GameID Identifier script help:

Ok dokay, I'll take a look. Is it usually Sony controllers that seem to have the issues? Or am I reading into that too much?

No, it's not a rule - it's just something I noticed at the time with the gamepads I tested.

First thought, it'd need to be done at the configscript point from ES mapping, as that's the point when the controller will be connected. Unless the input configuration script is run without the controller plugged in. Which I think is unlikely from a user perspective.

You can search at runtime and - if found - store it. I'm not sure if there's a rule, but tend to no assume that the device is connected and look only at the values given.

I'd envision searching for keywords to match SDL against evdev name, the only trouble is if the user has multiple controllers connected it may get it wrong.

Arcade cabinets have always controller(s) connected.

You can copy the main inputconfiguration.sh config script and then modify the path where the configuration scripts are, pointing to your own script folder (i.e. the Dolphin mapping script). You can run the script manually so you don't have to go through EmulationStation each time you want to run your mapping script.

To get more details when running a script, use either bash -x <scriptname> to see a step-by-step execution trace or modify the script header (1st line) to use bash -x for execution

@mitu Thanks for digging this up. I will remember it when I am about to fix this.

Great job replacing the kernel driver with the device tree counterpart !

@leonv32 Not sure if you are still working on this or not but I actually created something similar some years ago. All the html code is generated from the latest XML DAT files automatically.

Output lists
https://buildbot.libretro.com/compatibility_lists/

Repo that generates these
https://github.com/libretro/core-compatibility

@mitu thank you. thats a big help

@cyperghost sorry but I obtain error after installing your script:
borpak executive file not found in /opt/retropie/ports/openbor/borpak

Can you help me ?

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

@sleve_mcdichael Thanks for your help with this, you're a star. Oddly $system doesn't want to play ball and reports back empty, so I just changed that to nds directly and it works fine. Have added a PR into RetroPie Extras if anyone is curious to see the end result.

Oh also the core has networking support and works fine playing on wiimmf if anyone fancies a game of Mario Kart

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

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

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