Joystick_Read

Ohh… I forgot all about this thread. Funnily enough, before getting distracted with GitLab access, I was prototyping some enhancements so that…

1. we cover more buttons on the vanilla Acorn Joystick_Read
2. there is a SWI to list all of the currently connected joysticks
3. the complete button+axes data can be read for a device

I think it could be extended further for ‘other’ data sets, like those for the force feedback.

I’ll see about getting a build together with my proposal in there (alongside a test app). I would like to stick it all into git sooner rather than later, so I just need to get over my hurdles with SimpleGit.

we cover more buttons on the vanilla Acorn Joystick_Read

Yay! (because even dirt cheap SNES style controllers have lots of buttons)

Well, it has taken me long enough, but I’ve stopped mucking about with it for long enough to see what others think.

Updated USBJoystick. More buttons. And also a PROTOTYPE set of reason codes for joystick discovery and axes enumeration. Obviously, this is a moving target, so don’t release anything using it. Just have a look and please leave any feedback here or on the JASPP forum.

https://forums.jaspp.org.uk/forum/viewtopic.php?t=618

Looking good so far. I’ve made an early start on upgrading SDL 1.2’s joystick code to use the new enumeration APIs, and I have a few initial questions:

• What would be the proper method for handling extended axis values? SDL returns a value ranging from -32768 to 32767, but the APIs provide quite a bit of info about them. How much do I need to handle?
• Is it worth making POV hats (like the D-pad on the Xbox 360 controller) a distinct input type from buttons and axes?
• Can I assume that other Joystick modules will return an error if I attempt call Joystick_Read with the new reason codes?

I’ll probably have more questions when tackling the more advanced joystick API in SDL2 and SDL3, but I’ll get to that once joystick support in SDL 1.2 is a bit more complete.

I tried to keep things simple, and just present what the USB HID spec says, with a nod to thinking it could actually work for a non-USB device in future. So for each axis, you will get a min ands max. If they are not -32768 and 32767 then you will need to scale the values. I do this inside USBJoystick for the classic RISC OS API, to 8-bit or 16-bit values.

I wasn’t aware of any differences between the HAT/DPAD inputs, compared to sticks, so it made sense to me (and the original XMAME code which gave me the idea) that they are modelled as axes with very small inout ranges (-1 to 1).

Good question about the older module behaviour. I had not considered that! I suppose there are previous versions of USBJoystick to consider too… Maybe I should add in something to read the capabilities? But that does seem a bit heavy-handed: maybe I don’t need to.