MKDD Tint Issue RPI5

[retropieuser555]

@gvx64 is the speedhack Last Story specific? Or works on other titles as well?

[gvx64]

@retropieuser555 Right now, it's Last Story-specific. I hardcoded the hack in a conditional statement that looks for the presence of "SLS" in the game id (The Last Story's game id).

The hack fixes the invisible clothing problem when the EFBToTextureEnable setting is turned on when playing the Last Story where all you can see are floating heads of characters (the speedup comes from being able to leave EFBToTextureEnable turned on without having rendering problems). Let me know if you come across other games that have graphical glitches due to EFBToTextureEnable = true. If you see this problem come up in other games, and it turns out that this hack can fix it, I can create a more general solution such as an option for the game-specific ini file that can activate the hack.

[TPR]

@retropieuser555 said in MKDD Tint Issue RPI5:

@TPR regarding automapping you can attempt my script but I can't test it with many controllers as I only own 8bitdo ones so YMMV

https://github.com/RetroPie/RetroPie-Setup/pull/3969

Although if you make a profile for your controller how you like it, the script will realise it exists and just use that one, rather than overwriting it, so you could set all your controllers up as profiles then whichever you have connected would be used for that session, similar to mupen64plus

I'm just finally getting back around to this now. Where do I need to put that dolphin.sh at and how do I make this work? I dropped it into:
RetroPie-Setup/scriptmodules/emulators/dolphin/dolphin.sh

But I don't see where this tool shows up in my RetroPie-Setup.

Also, which one of these commits should I be using?
https://github.com/RetroPie/RetroPie-Setup/pull/3969/commits

[TPR]

@retropieuser555 said in MKDD Tint Issue RPI5:

@TPR regarding automapping you can attempt my script but I can't test it with many controllers as I only own 8bitdo ones so YMMV

https://github.com/RetroPie/RetroPie-Setup/pull/3969

Although if you make a profile for your controller how you like it, the script will realise it exists and just use that one, rather than overwriting it, so you could set all your controllers up as profiles then whichever you have connected would be used for that session, similar to mupen64plus

OK so update... I grabbed all three of those dolphin.sh files and put them in the appropriate folders and then I re-installed dolphin and now every time I load, I get the following error:

[TPR]

@retropieuser555 Any ideas what I might be doing wrong here?

[gvx64]

So I finally bought Double Dash because I wanted to try it out on my Pi4 using dolphin-rpi. At first the game speed was really poor (~60% fullspeed). That said, I found this hack that gets Double Dash playing at fullspeed by cutting the framerate from 60fps to 30 and activating the game's internal frameskipping:

I added the following commands to the GM4.ini file in ~/DolphinConfig5.0/GameSettings:

[Core]
EnableCheats = True

[ActionReplay_Enabled]
$Force 30FPS
[ActionReplay]
$Force 30FPS
0448C388 00000002

(source: https://www.reddit.com/r/gpdxd/comments/flq57f/near_fullspeed_double_dash_with_30fps_code/)

Note that my Pi4 is overclocked 2350MHz/940MHz. The games runs a bit choppy at around 23-28fps but the game speed seems to basically be fullspeed. It's very playable on the Pi4 with this hack.

I am not sure how helpful this hack will be for Pi5 users at is sounds like Double Dash runs at fullspeed regardless and I am not sure if this hack will help with multiplayer. That said, I mainly wanted to share this for any Pi4 users out there. It definitely made a huge difference for me playing this game.

[TPR]

@retropieuser555 So I've been messing around with the automapping and controller detecting script, I've now been able to get it to work pretty successfully, and I've tested it with a number of different controllers and it is working fine, except for one..... the 8Bitdo Pro 2 controller.

I think this is the issue. When emulationstation detects the controller it sees it as this:

but it saves it as a file called:
8BitDo Ultimate Wireless Pro 2 Wired Controller.ini

and in that file the ID is this:

[Profile]
Device = evdev/0/8BitDo Ultimate Wireless / Pro 2 Wired Controller

And it doesn't load or work. In fact, it gets confused and loads the profile for whatever the last controller I had.

I think it doesn't like the slash "/" in the ID as it may be looking for it in the file name but the file name cannot have that character in it.

I have noticed that the dolphin script needs to have the exact file name match the controller device ID for it to work.

Do you have any idea what database file emulationstation is pulling those Device ID's from and maybe I can try changing the name from "8BitDo Ultimate Wireless / Pro 2 Wired Controller" to "8BitDo Ultimate Wireless Pro 2 Wired Controller" and I have a feeling that will work.

Anyone have any thoughts? @DTEAM or @mitu

[TPR]

@retropieuser555
So a little update. I can confirm that the script works just fine with at least ten different controllers I just tried. The only trouble I'm having is with the above 8Bitdo controller that puts the "/' slash in the device name.

Any ideas on how to remove that or work around that?

Here's all the devices I have tried so far:

[retropieuser555]

@TPR you might have a problem there as forward slash is reversed by Linux in file names. When using jstest the device has a forward slash in it? Also and the 3 other modes as I know my Pro 2 has 4 modes, so I assume the wired controller is the same

[TPR]

@retropieuser555 said in MKDD Tint Issue RPI5:

@TPR you might have a problem there as forward slash is reversed by Linux in file names. When using jstest the device has a forward slash in it? Also and the 3 other modes as I know my Pro 2 has 4 modes, so I assume the wired controller is the same

Yep. That appears to be the name the Pi sees. And I have tried all four settings on my Pro 2 paired with the 8Bitdo Black Retro Receiver and I get the same results:

Is there a work around for this?

[TPR]

@retropieuser555 Ok so I think I found my own work around. Here's what I had to do...

1. Instead of using the 8Bitdo Retro Receiver I paired it via bluetooth using the X option on the back of the controller. At that point, emulationstation saw the controller as this:

2. Dolphin didn't like that and I got this error:
   

3. What was interesting is that in my GCPad config folder, I did have a file created called Xbox One S Controller.ini but dolphin seemed to think it was looking for 8BitDo Pro 2.ini

4. I renamed the file to 8BitDo Pro 2.ini and it loaded up without getting that error. But the controls still didn't work. I opened up the .ini file and saw this:
   

And noticed that, even though emulationstation displayed one device name, the script was still using the other. So I opened up Dolphin to see what it was seeing.

5. So in Dolphin, the controller was seen as this:
   

6. So I went into the .ini file and changed the device name to match that:
   

7. And that worked! Most of the controllers seemed to be okay, but the exit hotkey didn't work, so I had to go into the .ini files and edit both of them to make sure the hotkeys matched up and the buttons were assigned correctly.

8. Here is what my two .ini files look like now:
   
   

And everything seems to work!

I'll still keep messing around with this, but other than the one controller profile where the script seemed to not like the "/" being in the device name, every other controller I've tried seems to work just fine.

[TPR]

@retropieuser555 Had another minor issue with the Logitech F310 Gamepad.

I configured the controller through emulatationstation and then loaded up Dolphin and everything seemed to be fine except for the D-Pad wasn't working.

So then I went into Dolphin, loaded the Logitech Gamepad F310.ini file that your script had made and then saved it out.

D-Pad now works...

But exiting the game doesn't!

Apparently when I edited the Logitech Gamepad F310.ini file in Dolphin in removed the Hotkey setting when it re-saved it, so I went back in and edited the file manually to add back in Hotkey setting and now that works:

Also, the Logitech F310 has two settings on the controller. On the other setting, it made a file called "Logitech Dual Action.ini" which gave me an error. Dolphin was looking for a file called "Logitech Logitech Dual Action.ini" so I renamed the file to that, followed the same steps I did above for the other controller setting, and now that works!

So at the moment, I have the following four controllers I appear to be able to swap without any issues now that I've made the edits that I did:

1. XBOX 360 Controller (seemed to work without needing any edits)
2. Playstation 3 Controller (worked without edits)
3. Logitech F310 Controller (needed file name edits, re-mapping D-Pad and adding back the Hotkey)
4. 8Bitdo Pro 2 (Did not work with Retro Receiver due to device name having the slash "/" in it. Worked via bluetooth but needed to rename the files and the devices, and also edit the controller settings to add back to the Hotkey)

[TPR]

@retropieuser555 So another little update...

When using the USB Retro Receiver 2 with the Pro 2 controller, PS5 controller, Switch Pro Controller, or an XBOX One X controller, they all identify as "8BitDo Ultimate Wireless / Pro 2 Wired Controller" as a "device." Is there any work around at all for this? Where is emulationstation pulled that device name from and maybe I can change it in that database somewhere?

[retropieuser555]

@TPR not really no. Emulationstation's names are SDL which aren't necessarily the same device names you'd get from evdev. 8bitdo might use the same names as a manufacturer but trouble I've found is SDL doesn't seem to have universal names. So SDL names are different on dolphin compared to emulationstation. Otherwise the script would've been miles easier and could just make a dolphin config for SDL mode when mapping a controller in ES. So I ended up using evdev as that is at least consistent between dolphin and Linux itself.

The names come from /proc/bus/input/devices which you can see for anything connected to the machine using

cat /proc/bus/input/devices

If I have time I'm tempted to use the I: identifier to check the connected devices against the ini files. That way it'd avoid any possibility of a controllers special characters on the names screwing things up. I've got a tribute 64 controller that has a comma in the name so I can test with that

[TPR]

@retropieuser555 said in MKDD Tint Issue RPI5:

If I have time I'm tempted to use the I: identifier to check the connected devices against the ini files. That way it'd avoid any possibility of a controllers special characters on the names screwing things up. I've got a tribute 64 controller that has a comma in the name so I can test with that

Weird... my Tribute 64 identifies as an "XBOX 360 Controller." This one right?

I really do hope there is a fix for this. It's crazy to me that Dolphin doesn't auto detect the connected controller like every other emulator core seems to do!

On the plus side, at least connecting it via bluetooth does seem to help. And I've got a Mayflash USB Receiver on the way so I'm curious to see if the 8Bitdo is assigned a different device ID with that one.

I've managed to get something like 20 different controllers to work with it now swapping them in and out so the script works great for everything but that one Retro Receiver. I'd had to go in and re-configure the D-Pad on some controllers and add back the hotkey but it all works once I re-save the profile!

[TPR]

@retropieuser555 said in MKDD Tint Issue RPI5:

If I have time I'm tempted to use the I: identifier to check the connected devices against the ini files. That way it'd avoid any possibility of a controllers special characters on the names screwing things up. I've got a tribute 64 controller that has a comma in the name so I can test with that

I did just come across one with a comma in it that didn't work. Even though the file name and the ID name are the same, it still didn't load the profile:

[TPR]

@gvx64 said in MKDD Tint Issue RPI5:

@sugarfree m3u (multi-disc) support was added to dolphin in 5.0-9343 (https://dolphin-emu.org/download/dev/1d3e3de44b177eb7bdd07a02afefb83ac9ba5812/ - committed on January 15, 2019). That was about 1.5 years after the commit date for 5.0-4544. So no, dolphin-rpi does not support m3u files at this time.

A couple of questions for you now that I'm coming back to figuring out GC...

1. So RE4 is playable, you just have to manually swap discs in the backend, correct?

2. Where does rpi pull the game configs from? Is it the same /opt/retropie/configs/gc/local/GameSettings folder as the normal dolphin core?

3. I've noticed that RVZ files do run, but they don't appear in my listing of games. Is that normal?

[TPR]

@retropieuser555 Something else I just noticed about the script. If you have two controllers connected, they both work, but only controller 2 has the ability to exit out of a game with the hotkey. Controller 1 no longer does this.

[TPR]

@retropieuser555 The script does not seem to work with .m3u files. Neither Metal Gear Solid or Medal of Honor Rising Sun worked with the controller.

EDIT: Nevermind. Got the M3U file to work. Seems like the discs have to be visible in the same directory as the m3u to work correctly.

I had my disc files as .Metal Gear Solid - The Twin Snakes (USA) (Disc 1).rvz so they wouldn't appear in the listing and then I also tried putting them in a different folder and neither worked.

But if the .rvz file is visible in the same folder as the m3u, it seems to work.

[gvx64]

@TPR

1. Yes, my experience with multidisc iso's in dolphin (Baten Kaitos) is that when you reach the end of disc 1 the save file should get updated, then you can close the emulator and reopen with disc 2. RE4 should be fully playable on a Pi5 using dolphin-rpi.

2. /home/pi/DolphinConfig5.0/GameSettings/ (if you installed using the script or using the instructions in post #42 of this thread).

3. Thanks for letting me know, is this the game-list inside the main dolphin gui window? I will look into it.

Adding m3u support to dolphin-rpi is still on my to-do list.