[libretro] MS Paddle support using actual spinner, i.e Mouse +-X

[riggles1]

The way MS Paddle support currently is implemented is through controller stick analog input.

Using RA 1.9.4 (since it's the last version with perfectly working CRTSwitchres support) (CRT support is being fixed in the future)

I've been wanting to play games like Galactic Protector and Woody Pop using an actual spinner device however,
those are read as a Mouse device (Mouse +X Mouse -X).

Polling the Mouse input instead of stick input would enable players to either use a spinner device (such as a Spintrak), use a standard mouse, or build their own spinner using an optical mouse as the sensor.

Hopefully this get added, these games play much better with a mouse/spinner for sure :) thanks!

[ekeeke]

Sorry but I don't really have the time/desire to maintain or tune the libretro port of Genesis Plus GX so you will have to reopen this enhancement request in the libretro repository as it does not concern core emulation but instead the libretro backend.

For the record, the main reasons 'analog device' was initially chosen for the libretro implementation were that:

• the Sega Paddle internally behaves more like an analog stick as it reports an absolute position (0 being left-most position and 255 being right-most position), while libretro mouse device reports relative position (amount of movement)
• Retroarch/Libretro is designed to run on the large variety of platforms (like PC but also 3DS, PS3, Wii, Switch, etc) and it was not guaranteed at that time (but maybe it has changed) that all of them provided libretro mouse device drivers, thus making those few Master System games that require Sega Paddle emulation unplayable on some platforms, while analog device drivers seemed more universal

I don't personally have an opinion as to how this should be best handled (with a new core setting to choose between analog and mouse libretro device for this emulated controller ? with a change to libretro implementation to always use mouse device for this emulated controller, assuming that libretro mouse device is simulated by analog sticks if no physical mouse is present ?) and libretro/retroarch developers probably have a better perspective on that matter. In an ideal world, Retroarch drivers would abstract all this peripheral layer and maps any real input controller to the various supported libretro API devices (pad, analog, mouse, gun, pointer, etc) so that the core would not have to worry about which generic libretro device should be chosen for a specific emulated device but as your example shows, this is not the case in reality.