Add input sensitivity/offset options for Stelladaptor-like physical paddle devices

[jdgleaver]

As reported here: https://github.com/libretro/stella2014-libretro/pull/76#issuecomment-846499454, when the input device type is set to Paddles (Stelladaptor) for 'real' paddle support, the physical range of the controller does not necessarily map 1:1 to on-screen motion. In the user's example, input values from -2,000 to 30,000 correspond to the full screen width; considering that the controller has a range of -32,767 to 32,767, this severely limits accuracy.

This PR addresses the issue by adding two new core options:

• Stelladaptor: Paddle Sensitivity
• Stelladaptor: Paddle Centre Offset

These options replicate exactly the paddle sensitivity/centre settings in upstream Stella. By reducing sensitivity and increasing the centre offset, relative motion can be mapped easily to the full -32,767 to 32,767 range of any Stelladaptor-like input device.

The existing paddle sensitivity options have been prepended with a Gamepad: tag, which along with updated sublabels provides a distinction between settings that affect the two controller types. Moreover Stelladaptor: and Gamepad: options are only shown when at least one user's input device is of the appropriate type.

[alijani1]

@jdgleaver, I tested this and it works perfectly! Thank you so much. I will be posting a video next weekend, This will make a lot of people happy :)

[jdgleaver]

Excellent! Thank you for confirming that it works correctly now :)

[alijani1]

Hi @jdgleaver

I was talking to the Stella developers ( @sa666666 ) to see if they could add this fix also to the core and as it turns out, they requested your assistance because they felt now that libretro is supported in mainline Stella, all development should move to https://github.com/stella-emu/stella .

They mentioned originally Retroarch Stella support was done outside main Stella development for years because It was based on Stella 3.9.x, which is what all the 'outside' systems seemed to be using. R77 had similar issues. Because Stella 4.0 went to hardware acceleration and SDL2, and the others never made the jump. But now that libretro is supported in mainline Stella, all development should move there. Their thoughts is there shouldn't be any further development on stella-2014. For changes, it should rebase it on the current Stella (ie, the main branch). If you could develop against the main branch and submit a PR to them, then they could get it added. That way, it will be released each time we do a new release.

See this thread on that depository for more info

Would you be willing to try to do a PR on that depository and assist with your fix?

[inactive123]

While we are happy to contribute to upstream and will continue to do so, we reserve the right to work on any fork of Stella at our own choosing, as per the freedoms that the GPL license affords everyone.

It has to be noted that just like current mainline MAME, current mainline Stella will be too slow on many older platforms that we personally care about. That's why a fork of an older version exists. We wouldn't maintain these older versions if there was no reason for it, since otherwise it'd add nothing but maintenance burdens for us. Current mainline Stella or MAME are not going to run well on these older platforms, hence why this core exists. Why is this an issue? Let endusers choose whatever they want. In this case on the platform this is targeted towards, there is no other viable option. It continues to be baffling why this is an issue, as all of this is completely acceptable by the standards and freedoms that the GPL license affords everyone. To argue against this is to disrespect the core tenets of the license, to be free to tinker as one chooses with source.

I'd really appreciate if endusers stay out of this and they desist making divisive issues that devs across projects then start infighting about. Often times the situation is unnecessary and it's down to the enduser's greed and entitlement that things get misinterpreted and developer relations are ruined in the process. In situations like this, this kind of prodding honestly just keep making situations for us that we then have to unfortunately deal with and attempt to correct. It doesn't have to happen and it definitely does way more harm than any good.

[alijani1]

@twinaphex, I apologies as the intent was only good and not to raise any conflict. Both teams are great folks and they can certainly co-exist as they have been and by no means I meant to make this a divisive issue. As you saw from the comments of upstream stella project, they are perfectly fine with this staying as is and its only a suggestion to also apply fixes upstream if at all possible. I have no greed and I was getting lots of requests from users of icode adapters and i was only looking for a possible solution for the community. I love both projects and as I improve my knowledge in this area, I will certainly try to contribute to both.

[inactive123]

No problem, I just wanted to pre-emptively stop this from escalating into drama as I felt there was a real and concrete danger of it resulting in that. Thankfully that turned out not to be the case this time.