[Api request] totatlly disabling "Analog to Digital" for specific cores

[barbudreadmon]

Follow-up of #12562

Some cores like FBNeo don't want that setting, because they are already dual mapping to dpad & analog left in a safe way, in which case i can only see that setting as dangerous (and i also heard some devices like the nintendo switch set it on by default). Having a mean to prevent that setting to be appliable at all for specific cores would be great.

[barbudreadmon]

tagging @jdgleaver about this

[hizzlekizzle]

Since AtoD mapping is a RetroArch thing rather than a libretro thing, I wouldn't think it would make sense to go into the API itself, but I was thinking RetroArch just recently got the ability to disable it on some cores automatically. I don't remember the circumstances that cause it to auto-disable, though. (I thought it was any time the analogs were actually initialized by the core, which should theoretically cover FBN, too, if it's doing it on its own)

[markwkidd]

This is an issue for MAME 2003/+ as well, where we also have analog to digital in the core.

[jdgleaver]

With #12562, AtoD mapping should always be disabled for cores that use analog input, unless the user explicitly chooses one of the 'forced' mapping options (which are never selected by default). So this issue report only covers these 'forced' options - i.e. should some cores override the user setting to guarantee properly working inputs?

Since AtoD mapping is a RetroArch thing rather than a libretro thing, I wouldn't think it would make sense to go into the API itself

That's an excellent point! So if we did want to do something like this, it would probably be more appropriate to add a new field to the core info files - adc_disabled - to enable a frontend override without messing with the API.

[markwkidd]

@mahoneyt944 I wonder if you have thoughts and advice about this

[barbudreadmon]

One matter of concern is that, in the few topics about that setting, i always see users recommending to use the "forced" setting (there might be a reason the non-forced isn't popular ?).

That's an excellent point! So if we did want to do something like this, it would probably be more appropriate to add a new field to the core info files - adc_disabled - to enable a frontend override without messing with the API.

It sounds like an excellent idea

[hizzlekizzle]

So if we did want to do something like this, it would probably be more appropriate to add a new field to the core info files - adc_disabled - to enable a frontend override without messing with the API.

I had considered adding "needs_keyboard"/"needs_mouse" fields to the infos but didn't bother now that we can query the core directly (IIRC), but something like "needs_analogs = true" could auto-disable frontend AtoD.

On a related note, the info files now include a lot more information about the core capabilities if we wanted to auto-disable/hide some risky options, such as runahead and/or rewind (or savestates, or even 'controls' and/or 'cheats' menus). It could also be nice to include logging warnings based on these fields (e.g., "core needs fullpath, so softpatching is unavailable").

[mahoneyt944]

@markwkidd the forced options ignore analog input and send a digital signal only. So the analog stick would would be picked up as a dpad input.

The non-forced options only do this if the core does not support analog natively, therefore if it does support analog, the setting is ignored.

This doesn't effect mane2003+ since we map analog and digital to our games. So we wouldn't need to use a to d mode. If you set it to a non- forced mode the setting is ignored since we support analog. If you use a forced mode the analog stick will map as a dpad. Which still works too since we map our dpad.

The non-forced options aren't as popular since they don't work if the core supports analog.

So why would a user try to use a to d? If a user wants to play pacman for example, this game expects a digital input. The analog stick wouldn't work here. So by using a forced option the analog stick would pretend to be a dpad and then work. If the user selected a non- forced option and core supports analog, nothing would change and the analog stick wouldn't work for pacman.

In mame2003+ we internally check our analog input to a threshold and report that to mame as digital press. So everything just works no matter what.

[ghost]

That's not how we fixed it we had to map the digital and analog to directions. If you just map one only one will work for the relevant control. The main problem before was dual inputs when setting controls in the ui fwiw of corse game focus mode should resolve these issues If there is any

[mahoneyt944]

@grant2258 these are both a key part. Though mapping both is not enough for analog to work in a digital input game.

https://github.com/libretro/mame2003-plus-libretro/compare/Test

To test this theory, disabling our threshold check doesn't allow a analog stick to play mspacman even though they are both mapped....

We fixed the issue by mapping both inputs and by checking this threshold so that analog can be used in a digital input game.

[ghost]

It's always been this way @mahony just the refactoring caused some analog issues. It's what you map on the ui in plus.. Goto input this game and just map the digital hat left analog controls won't work just the dhat mapping.

Sorry I had to edit it was on the phone.

Well I had a look never knew this option changed and had a look.

Analogue to digital type: left sends the analogue
Analogue to digital type: left(forced) sends the digital dhat.

As far as I can tell this is how it should work perhaps renaming it to.
Analogue to digital type: left (analogue)
Analogue to digital type: left (digital)

and perhaps add the old behaviour back.
Analogue to digital type: left (analogue & digital)

As far as i can see the issue has been resolved already if you understand what its doing. Before is was sending both signals.

[mahoneyt944]

It's always been this way @mahony just the refactoring caused some analog issues. It's what you map on the ui in plus.. Goto input this game and just map the digital hat left analog controls won't work just the dhat mapping.

Sorry I had to edit it was on the phone.

Well I had a look never knew this option changed and had a look.

Analogue to digital type: left sends the analogue
Analogue to digital type: left(forced) sends the digital dhat.

As far as I can tell this is how it should work perhaps renaming it to.
Analogue to digital type: left (analogue)
Analogue to digital type: left (digital)

and perhaps add the old behaviour back.
Analogue to digital type: left (analogue & digital)

As far as i can see the issue has been resolved already if you understand what its doing. Before is was sending both signals.

Right that was my opinion as well. And maybe where some of the confusion is in talking about this 🙃.

The option Analog to Digital "left" sends analog if the core natively supports analog or else it sends digital when it doesn't.

The way I understand it, "left" is more decisive on what to send based on the core's hookup of analog. "Forced" just ignores everything and sends digital.

[ghost]

How do your set the core to be digital only? This could be handy it would be even better it the retropad can tell you. Some controllers are monsters though. The dragonwise arcade controller defaults to analog but send 0 on off and full analog on press unless you press the mode button to put it digital then it sends to the dhat.

[mahoneyt944]

Edit:
If you use forced mode that is digital only. So force it ha

[mahoneyt944]

Left (Forced) - is digital only

Left - is analog if supported by the core otherwise digital

[ghost]

@mahoneyt944 "Left - is analog if supported by the core otherwise digital" Im not sure what you mean by this when is it not supported is it dependant on the retropad type?

@markwkidd
Slightly off topic looking at the input screen as far as the mouse goes looks great in udev you get this.

however when you get a driver that doesnt support device names you get this and it looks like the mouse isint available (linux x in this case)

.

[mahoneyt944]

@grant2258 that's more of a question for @jdgleaver since I believe he configured how RA decides this or not. maybe he can elaborate on this. I assume it's looking to see if a call to an analog type was made or not?

[ghost]

Im just curious myself would be a handy thing to know.

[mahoneyt944]

There's a few commits 3a82cf9

You maybe able to find the answer to this.

[jdgleaver]

@grant2258 that's more of a question for @jdgleaver since I believe he configured how RA decides this or not. maybe he can elaborate on this. I assume it's looking to see if a call to an analog type was made or not?

Please refer to the original comment for the PR that enabled this functionality: #12562

disable mapping if core attempts to read analog input means exactly that: it is disabled if a core polls analog stick input (i.e. it is purely dependent upon the core's behaviour)

[ghost]

Makes sense if no analog is polled return dpad else act normal. I don't see any issues with this apart from mapping cores that don't use analog properly to use the l or r stick. This setting will have no issues for plus as we poll analog anyway.