Dolphin - GameID Identifier script help

mitu

In Bash, the 1st parameter of the script is retrieved with $1, thus the %ROM% parameter becomes $1 in your script.

RapidEdwin08

@retropieuser555 I think you just forgot to set the $rom variable, which should be $1 the way you are passing the %ROM% Parameter...
Try to Add this before anything $rom in script:

rom="$1"

I'm intrigued, are you just trying to pass the game ID to the runcommand log for reference?

retropieuser555

@RapidEdwin08 so I'm testing an idea I had.

You can only edit or change controls using the gameID saved as an ini file. So I'm thinking of making something that can identify the game and apply the correct controls profile I've got setup for classic controller, sideways Wiimote etc

Anyway that works so far, thanks for the explanation

Edit:-

So here's what I have so far. I couldn't quite get my head around a consistent way to make profiles for each controller for sideways Wiimote, classic controller, nunchuk + wiimote etc. So I'm just focusing on gamecube for now.

This script I've created, can you take a look, have a test and give me some pointers please. At the moment I find the js0 controller and generate a pretty raw and guesswork based controller profile ini for a gamecube controller. Then find the GameID of the rom and create an .ini file to map that controller for that playthrough.

https://pastebin.com/gMtfUeiG (updated pull request version)

That attached script I'm just running it from emulators.cfg with something like:-

dolphin-trace = "XINIT-WM:/opt/retropie/emulators/dolphin/bin/gameid.sh %ROM%"

Further edit:-

I've adjusted this all further and have added in checks for m3u and adding in a start+select hotkey exit. Have created a pull request and will continue the discussion on this topic there

mitu

I don't think the script is correct, since it hardcodes the inputs into the .ini. While those inputs may work for your controller, other controllers have different order for A/B/X/Y buttons, joyaxes, etc.

I've only briefly looked at it and I don't understand why the .ini has to be re-created each time, given that the mapping is the same every time ?

retropieuser555

@mitu sorry you mean the gameID.ini or the controller profile.ini?

You can test and see if you can find a way, but

The documentation is outlined here

https://wiki.dolphin-emu.org/index.php?title=GameINI_(Controller_Settings)

PadProfile1 = Name of Profile

PadProfile is only mapped to Gameid.ini entries, it doesn't appear to work on the dolphin.ini file. It'd be great if it could be mapped to the global setting ini instead

It doesn't recreate the profile .ini, it creates a dummy one at present and if it exists it doesn't save over it everytime.

I do agree it's hard to get a uniformity, I only have 8bitdo and Switch Pro Controllers so I'm limited what I can test. But oddly Dolphin seems to apply it's own layer to controllers on top of evdev, so it names buttons, EAST, NORTH etc. but that's not the button namings from linux's results in say evdev or jstest

Anyway I'm open to ideas and changing the approach to make this workable

mitu

@retropieuser555 said in Dolphin - GameID Identifier script help:

@mitu sorry you mean the gameID.ini or the controller profile.ini?

Not sure which one is it, but the one where you're storing the mappings between the controller and the emulator inputs.

I do appear it's hard to get a uniformity, I only have 8bitdo and Switch Pro Controllers so I'm limited what I can test.

That's true, but I don't see how you think it would work in general - each controller type/model has potentially a different input numbering. That's why in EmulationStation there's a configuration dialog - each controller is mapped to ES's actions with the detected input rather than make some assumptions about the input order, whether the controller has a D-Pad as a HAT or AXIS, etc.

But oddly Dolphin seems to apply it's own layer to controllers on top of evdev, so it names buttons, EAST, NORTH etc. but that's not the button namings from linux's results in say evdev or jstest

Dolphin can use Evdev or SDL (on Linux at least). SDL can use the Joystick Subsystem or the Gamepad Subsystem, the latter having the advantage of a uniform input naming. AFAIK, the Gamepad support - which merged this year - shoul do some automatic mapping based on this standard/uniform naming present in SDL's Gamepad subsistem (i.e. the uniformity offered through the SDL GameControllerDB mappings). It's not always straightforward what's used and that's why I've put on hold my input auto-configuration script.

Anyway I'm open to ideas and changing the approach to make this workable

Honestly, I don't see how that would work, given the lack of dynamic input assignment, which is kind of the point of the script IMHO.

retropieuser555

@mitu said in Dolphin - GameID Identifier script help:

Not sure which one is it, but the one where you're storing the mappings between the controller and the emulator inputs.

You mean the ini from function check_and_create_ini? That's created into opt/retropie/configs/gc/Config/Profiles/GCPad.

That's true, but I don't see how you think it would work in general - each controller type/model has potentially a different input numbering. That's why in EmulationStation there's a configuration dialog - each controller is mapped to ES's actions with the detected input rather than make some assumptions about the input order, whether the controller has a D-Pad as a HAT or AXIS, etc.

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.

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.

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

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.

But then of course I completely agree, making these assumptions I can't say with confidence how a vendor/controller developer would have chosen to map their own controller when they mapped it to the input driver when making it. South might be mapped to North, Mode instead of Select etc

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

mitu

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

retropieuser555

Okay I have edited the previous setup process so it now mimics the same as the setup for automapping emulators like Daphne or Pisnes.

I've added to the script an emulationstation config script for dolphin and a startup script that reads the gameID and maps the controller. It also maps the hotkey & start as the exit for the controller that's plugged in

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

Have only been able to test this on the controllers I own so I can't guarantee how it'll behave with things like ps4 controllers, so someone will need to test a few and report back

mitu

@retropieuser555 The script looks better and it's good that's no longer hardcoding the input values since now it runs with the configuration values from EmulationStation.

The main drawback - which I also encountered trying to create an automatic mapping script - is that controller names are not always identical between the naming assigned by libev (i.e. evdev type controllers) and SDL (i.e. sdl type controllers). SDL applies some normalization and/or renaming for some controller names so whatever is sent by SDL to the mapping script may not be what's shown in /dev or /sys.
For instance, the PS3 controllers are detected by udev as PLAYSTATION(R)3 Controller, but SDL names them simply PS3 Controller. This is the reason that RetroArch configuration profiles now contain the device vendor and product ids (exported by ES since this commit).

Now, you could switch from using evdev in the profile files to sdl (i.e. instead of evdev/0/PLAYSTATION(R)3 Controller to have sdl/0/PS3 Controller) and adjust the generated mapping syntax. However the main problem is still that at runtime you have to adjust the detection of the controller name to match between the udev naming that you find under /sys or /dev to the name generated by SDL. Same thing with the PS4 controller.

Looking briefly at the scripts, there are a few things that could need improvement (for instance - don't enumerate everything under /proc/bus/input/devices, just look at /dev/input/jsX for joysticks) and also some errors (i.e. sed for hotkeys replacements doesn't quote one of the /, there's no checks for profile existance when trying to map the hotkeys).

I'm also not so keep on using the game tool to generate the game.ini profiles, isn't there another way of just modifying gcpadnew.ini with the profile names or just using the CLI to load the profiles ?

EDIT: forgot to add the most important part - the evdev input IDs don't always match what libsdl returns, i.e. when you map button X coming from the ES mapping, the X may not be the same as it apears in jstest or evtest when pressing the button. It's rare, but it can happen for some gamepad buttons.

retropieuser555

@mitu said in Dolphin - GameID Identifier script help:

Now, you could switch from using evdev in the profile files to sdl (i.e. instead of evdev/0/PLAYSTATION(R)3 Controller to have sdl/0/PS3 Controller) and adjust the generated mapping syntax. However the main problem is still that at runtime you have to adjust the detection of the controller name to match between the udev naming that you find under /sys or /dev to the name generated by SDL. Same thing with the PS4 controller.

So this won't work for dolphin as it's naming for SDL isn't the same as Emulationstations, there's weird differences like capitalisations and so on.

Looking briefly at the scripts, there are a few things that could need improvement (for instance - don't enumerate everything under /proc/bus/input/devices, just look at /dev/input/jsX for joysticks) and also some errors (i.e. sed for hotkeys replacements doesn't quote one of the /, there's no checks for profile existance when trying to map the hotkeys).

That's fine, I can switch it to look for JS controllers as that is effectively the same process/result.

I could change that hotkeys bit around, but for hotkeys it just maps the first controller as the exit for each session. I could check and stack multiple controllers for exiting the system

I'm also not so keep on using the game tool to generate the game.ini profiles, isn't there another way of just modifying gcpadnew.ini with the profile names or just using the CLI to load the profiles ?

I suppose you could copy the profile at startup over to gcpadnew each time, but one drawback is the user won't get a pop up telling you which controllers is mapped to which controller port when dolphin starts if they're doing multiplayer.

It's annoying but dolphin.ini doesn't have the option to select profiles, for whatever reason it's mapped to those game specific configs.

EDIT: forgot to add the most important part - the evdev input IDs don't always match what libsdl returns, i.e. when you map button X coming from the ES mapping, the X may not be the same as it apears in jstest or evtest when pressing the button. It's rare, but it can happen for some gamepad buttons.

Is there any good examples of this? Or specific controllers that this happens to?

Also the naming convention like the PS3 controller, I could add a check to look at the evdev name and if it's different to the ES name to use the evdev one, that may get around the problem?

mitu

@retropieuser555 said in Dolphin - GameID Identifier script help:

Is there any good examples of this? Or specific controllers that this happens to?

I think the PS4 controller had this issue - see https://github.com/RetroPie/RetroPie-Setup/pull/2992#issuecomment-587286442

Also the naming convention like the PS3 controller, I could add a check to look at the evdev name and if it's different to the ES name to use the evdev one, that may get around the problem?

How exactly are you going to do that ? You don't know how many controllers are connected and assuming that the configured controller is the only controller present may not be true.

retropieuser555

@mitu said in Dolphin - GameID Identifier script help:

I think the PS4 controller had this issue - see https://github.com/RetroPie/RetroPie-Setup/pull/2992#issuecomment-587286442

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?

Also the naming convention like the PS3 controller, I could add a check to look at the evdev name and if it's different to the ES name to use the evdev one, that may get around the problem?

How exactly are you going to do that ? You don't know how many controllers are connected and assuming that the configured controller is the only controller present may not be true.

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.

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. Edit: we'd probably need some other examples to check and see what the difference becomes like the PS3 controller above you mentioned

Other trouble is I don't own Xbox and Sony controllers, I can only have 8bitdo ones which while they run in modes that simulate those controllers it probably isn't representative

mitu

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