3DS emulator for Pi users based on "Borked 3DS"

DTEAM

@Folly said in 3DS emulator for Pi users based on "Borked 3DS":

Here is my rewrite :
https://github.com/FollyMaddy/RetroPie-Extra/blob/Borked3DS-WIP/scriptmodules/emulators/borked3ds.sh

Thanks, I left a lot of old stuff in there, including too many dependencies. When we have something solid, we should clean it up and change the name to Borked3DS-rpi, like @gvx64 did.

We could also add some presets for a good first-launch experience. I'll share my settings later, and we can discuss the best option for getting started with this emulator on a Pi.

Folly

@DTEAM said in 3DS emulator for Pi users based on "Borked 3DS":

@Folly said in 3DS emulator for Pi users based on "Borked 3DS":

Here is my rewrite :
https://github.com/FollyMaddy/RetroPie-Extra/blob/Borked3DS-WIP/scriptmodules/emulators/borked3ds.sh

Thanks, I left a lot of old stuff in there, including too many dependencies. When we have something solid, we should clean it up and change the name to Borked3DS-rpi, like @gvx64 did.

You're welcome.
Yes sure, some stuff can be removed, I agree.
Changing the name could be done but I created a chameleon script that changes the source upon aarch64 and x86_64.
So not sure if renaming is a good idea then.

We could also add some presets for a good first-launch experience. I'll share my settings later, and we can discuss the best option for getting started with this emulator on a Pi.

Good idea !
First thing first, we need a solution to get it properly compiling first ;-)

DTEAM

@Folly @gvx64

I did sudo apt-get install robin-map-dev and modify my old script a little bit (I added the depends robin-map-dev) and switch for Borked3DS-rpi inside the script and everything works well on the first run! I did the switch before your previous message, if you prefer to keep Borked3DS name for X86_64 build and Pi, and be more versatile, I understand. You don't need the last CMake version.

Here's the script. Feel free to modify it.

borked3ds-rpi.sh

gvx64

@DTEAM @Folly So with the latest changes to the github master the retropie install script provided by @Folly finally built successfully on my Pi4. Note that I made a couple of edits to the build script:

        if isPlatform "aarch64"; then
                gitPullOrClone "$md_build" https://github.com/gvx64/Borked3DS-rpi.git
#               downloadAndExtract https://cmake.org/files/v4.0/cmake--linux-aarch64.tar.gz "$md_build"
                downloadAndExtract https://cmake.org/files/v4.0/cmake-4.0.2-linux-aarch64.tar.gz "$md_build" #gvx64
                mv cmake-4.0.2* cmake-4.0.2
        else

function build_borked3ds() {
        mkdir build
        cd build
#       $md_build/cmake-4.0.2/bin/cmake .. -DCMAKE_BUILD_TYPE=Release
        $md_build/cmake-4.0.2/bin/cmake .. -DCMAKE_BUILD_TYPE=Release -DDYNARMIC_USE_BUNDLED_EXTERNALS=OFF #gvx64 addition
        $md_build/cmake-4.0.2/bin/cmake --build . -- -j"$(nproc)"
        md_ret_require="$md_build/build/bin"
}

DTEAM

@gvx64

Thanks , I’m gonna it with Folly script (borked3ds.sh)

New edit: I confirm, @Folly's script works very well on Pi5 (64-bit)! Well done!

@ExarKunIv The script from @Folly should be the one on Retropie-Extra and not mine

roslof

It's a reliable issue [RPi5] that if I run any stable/decrypted game with OpenGL and GLES extensions checked, I see a black screen with correct game audio, but if I stop emulation and change to Vulkan (in the same session) and start a game, it will render correctly with correct audio... ("VULKAN" displays in lower-left of UI).

...however launching any game with Vulkan initially set results in a crash.

So the only way I can see & hear any game is to launch w/OpenGL, stop and switch to Vulkan in the same session. Trippy.

Wondering if I need to upgrade/install something, like a newer version of MESA, as I'm only using mesa-drm from the RetroPie "depends" option in RetroPie Settings.

DTEAM

@roslof

I have no games (many games) issue on my side for Pi5. It's probably un 3d parameter selected in the graphic options menu

If you go in

/home/pi/.config/borked3ds-emu

here's my settings

qt-config.ini

sdl2-config.ini

Game language is set to french. Youwill have to change it

roslof

@DTEAM said in 3DS emulator for Pi users based on "Borked 3DS":

here's my settings

Thank you for providing @DTEAM will check it out (Done).

Got it, thanks to diff'ing qt-config.ini
Needed to deselect "Hardware Shader Acceleration" (from default checked)
Cheers @DTEAM

roslof

@DTEAM said in 3DS emulator for Pi users based on "Borked 3DS":

@ExarKunIv The script from @Folly should be the one on Retropie-Extra and not mine

Might want to fix the small "comma" typo on line 16 that appears as ,cxi instead of .cxi

Current (incorrect):

rp_module_help="ROM Extension: .3ds .3dsx .elf .axf .cci ,cxi .app\n\nCopy your 3DS roms to $romdir/3ds"

gvx64

@roslof Yes, good call I should have mentioned this. Make sure that Hardware Shader Acceleration is ALWAYS disabled. I tried to get Hardware Shader Acceleration working on the Pi but I hit a dead-end. It likely won't make much of a difference anyways since the Pi's GPU is way too slow to take advantage of it.

Also, the Borked3DS-cli binary also currently doesn't work. I came close to getting it working but I stopped when it became apparent (again) that the Pi's GPU won't be able to handle rendering the window and the emulation at the same time without a major loss of performance compared to the QT5.

It's good keep in mind that Vulkan works at least somewhat. Most games have weird rendering artifacts under Vulkan but there may be some games (that I haven't come across yet) that work better under Vulkan than GLES currently.

roslof

@gvx64 said in 3DS emulator for Pi users based on "Borked 3DS":

It's good keep in mind that Vulkan works at least somewhat. Most games have weird rendering artifacts under Vulkan but there may be some games (that I haven't come across yet) that work better under Vulkan than GLES currently.

All very good info. I also noticed that when Full Screen mode is much slower than when the UI is displayed. The opposite is true for Dolphin. Was going to report that some games were slower under OpenGL, but it was just the Full Screen mode. :)

Starting to get used to the nuance now.
Having a ball with this one.

ExarKunIv

@DTEAM open a PR on my repo. I'm not by a computer to do big changes. It will be next week before I'm in front of a computer again

Folly

@gvx64 @roslof
I added both your changes to the script.

I will probably will change the script so -DDYNARMIC_USE_BUNDLED_EXTERNALS=OFF
will only be added when compiling for rpi.
Will have a look later.

DTEAM

@gvx64 said in 3DS emulator for Pi users based on "Borked 3DS":

It's good keep in mind that Vulkan works at least somewhat. Most games have weird rendering artifacts under Vulkan but there may be some games (that I haven't come across yet) that work better under Vulkan than GLES currently.

@roslof With Vulkan, the only playable one tested for now is MarioKArt. Vulkan works well on a computer with that emulator. The Vulkan version under MESA is to low on a Pi for now.

Another thing, I don't remember wich one , but one of the audio settings affect the performance (big impact).

roslof

@Folly said in 3DS emulator for Pi users based on "Borked 3DS":

@gvx64 @roslof
I added both your changes to the script.

I will probably will change the script so -DDYNARMIC_USE_BUNDLED_EXTERNALS=OFF
will only be added when compiling for rpi.
Will have a look later.

@gvx64 does adding the prefix env MESA_EXTENSION_OVERRIDE="GL_OES_texture_buffer" to es_systems.cfg still provide benefit?

I noticed that it's still in the fork README.md, but does not appear in the latest RetroPie script. Specifically:

<command>env MESA_EXTENSION_OVERRIDE="GL_OES_texture_buffer" /opt/retropie/supplementary/runcommand/runcommand.sh 0 _SYS_ 3ds %ROM%</command>

Cheers!

gvx64

@roslof Yes, THANK YOU for reminding me, I totally forgot about this important point. GL_OES_texture_buffer is a GLES 3.2 extension that the Pi partially supports - well enough for Borked3DS-rpi to take advantage of it. @Folly , can we please replace the addEmulator line with the following on your install script:

    addEmulator 1 "$md_id-roms" "3ds" "env MESA_EXTENSION_OVERRIDE=GL_OES_texture_buffer $launch_prefix$md_inst/borked3ds %ROM%"

This should hopefully get environment variable specified in /etc/emulationstation/es_systems.cfg at time of install and so it should get set whenever users launch Borked3DS-rpi from within emulationstation (please let me know if it does not work). Note that the easiest way to check to see if the environment variable is functioning as expected is to check the log after running Borked3DS-rpi and look for the following message:

GL_OES_texture_buffer is available, utilizing primary code path
present in the log means that it the env variable assignment is working properly while,

GL_EXT_texture_buffer not available, falling back to 2D texture LUTs
means that it is not working and that there is something wrong.

As you can see there is also a fallback path that myself and rtiangha introduced that functions in the event that GL_OES_texture_buffer env var is not specified that seems to work fine but it provides less GPU acceleration. Theoretically, enabling texture buffers should make Borked3ds faster. Practically speaking, I didn't see much a difference enabling texture buffers on the Pi4 but it might make more of a difference on a Pi5 with its faster gpu. In any case, I would just specify the environment variable in the install script, make sure that it is in /etc/emulationstation/es_systems.cfg and then leave it at that - texture buffers are the default functionality for the emulator and it stands to reason that it is possibly more stable than the fallback path which has had less testing.

Folly

Committed improvements can be viewed here.
Script needs to be checked and tested again.

roslof

@Folly said in 3DS emulator for Pi users based on "Borked 3DS":

Committed improvements can be viewed here.
Script needs to be checked and tested again.

Thank you again Folly!

For me, when the emulator.cfg line is prepended env MESA_EXTENSION_OVERRIDE=GL_OES_texture_buffer runcommand seems to have a hard time. Guessing something to do with number of parameters since we're adding one?

Viewing /dev/shm/runcommand.log yields the following error before kicking back to ES:

Parameters:
Executing: env MESA_EXTENSION_OVERRIDE=GL_OES_texture_buffer XINIT-WMC:/opt/retropie/emulators/borked3ds/borked3ds "/home/pi/RetroPie/roms/3ds/Angry Birds Star Wars (USA) (En,Fr,Es,Pt).3ds"
env: â€˜XINIT-WMC:/opt/retropie/emulators/borked3ds/borked3dsâ€™: No such file or directory

So I removed the environment variable from emulators.cfg and added it to es_systems.cfg in this location (which I believe was @gvx64's or @DTEAM's original idea:

<command>env MESA_EXTENSION_OVERRIDE=GL_OES_texture_buffer /opt/retropie/supplementary/runcommand/runcommand.sh 0 _SYS_ 3ds %ROM%</command>

This yielded the correct log information in ~/.local/share/borked3ds-emu/log is specified by @gvx64: GL_OES_texture_buffer is available, utilizing primary code path

gvx64

@roslof OK, that wasn't supposed to happen. Thanks for letting me know. I will need to do some additional investigation to figure out how to get the install script to add the env var to /etc/emulationstation/es_systems.cfg. I haven't seen it done in any other examples scripts and so I will have to do some digging.

Folly

@gvx64 @roslof

I think the runcommand didn't work because it was missing a semicolon.
The env part is a command not an option, by adding the semicolon, I think, it should work now.
The change can be viewed here.
Script needs to be checked and tested again.

@roslof
If you want you can test only the configure part by doing the following commands.

cd RetroPie-Setup
sudo ./retropie_packages.sh borked3ds configure

That should only install the new runcommands.