Joystick_Read
Pages: 1 2
Jon Abbott (1421) 2651 posts |
Would there be any objections to changing the spec of Joystick_Read 1 to support 32 buttons. eg from:
to:
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Rick Murray (539) 13839 posts |
I’ll briefly come out of hiding to say – please do this. Even a basic SNES style joystick has ten buttons, which can’t be fully used with an eight bit value. Now to crawl back under my rock… |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Cameron Cawley (3514) 157 posts |
No objections from me. For SDL, it would also be useful to have SWIs to list how many joysticks exist, and what features they have – SDL 1.2 on RISC OS currently hardcodes 1 joystick with 2 axes and 8 buttons since there isn’t a reliable way of looking this up. For SDL2, it would also be good to have a way of getting the named elements for all buttons including A, B, X and Y so that the game controller API will work without requiring the user to manually provide a mapping string. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Jeffrey Lee (213) 6048 posts |
Sounds good to me.
Borrowing a few ideas from this old thread, and the SDL 2 API perhaps a sensible course of action would be:
That should give us a reasonably feature-rich API without requiring too much effort to design & implement it. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Jon Abbott (1421) 2651 posts |
I’ve revised the documentation for Joystick_Read 1 to support 32 buttons and noted that it previously supported only 8. I’ll hold off doing anything about a better API until there’s been more feedback. I would particularly like to see feedback from game authors and Richard Walker. My suggestion in the OP is primarily centred around XB/PS controllers and needs expanding/changing to cover HOTAS, steering wheels and other forms of HID that games are likely to need. Jeffrey’s suggestion of using a naming standard that already exists is worth investigating. I’m inclined to lean towards an existing Microsoft, Sony or Linux standard, as I expect every game API has it’s own naming convention. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Charles Ferguson (8243) 427 posts |
I wouldn’t bother extending the definition of the Joystick_Read 1 SWI. As a user of the proposed interface, you don’t know what the buttons are, and no existing client using the interface before any such change would know that they were there. Therefore only new clients who explicitly want to use the new buttons would know to look for them. And they wouldn’t know what they meant – how to present them or what they could do with them. As such, any client wanting to use them only gains the ability to look for buttons but cannot present any interface to help the user any better than before. Essentially I think that just defining new buttons on that API is too narrow and if you’re going to make changes it should be in a more significant manner – otherwise you’re immediately going to throw away what you’ve got because the existing interface is too limited. The suggestion of an extra SWI is redundant, as the mechanism for extending the Joystick reading interface is through Joystick_Read – just create new reason codes, don’t start creating new SWIs when they aren’t needed. If you were doing something other than a ‘Read’ operation then it’d be reasonable, but… you’re not. If it were me doing it, I’d create a registration interface where hardware drivers can register with the Joystick module to provide their functions. However, using Jeffrey Lee’s suggestion to vector the interface so that multiple clients can be connected at once would work equally. Start by working out what features a Joystick has – because the current implementation is limited (and the proposal identifies a few but only for specific instances).
Knowing what sorts of input devices exist, an interface should be designed which gives the ability to represent the bulk of the forms, even if they are not used right now. Simplified interfaces will be required for those who don’t need the full set, and just want to know ‘are they pressing a button’, or ‘where is the joystick relative to its rest position’ (eg like we currently have)? It might be useful to decide whether the input to the system is intended to be instantaneous, or buffered. At present input readings are essentially instantaneous – you make a request for the current state and you get it. Just ignore the fact that you might have missed some clicks or whatever. Is that reasonable? Can a mechanism be given which allows this? That’s some quick thoughts… I’ll throw down some more thoughts that I’ve had this evening later, but it’s late and I’m pretty sure my eyes are glazing over… |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Charles Ferguson (8243) 427 posts |
A few hours after I’d seen this and I’ve written up some ideas on how I would go about providing an extensible interface to allow multiple joystick drivers, a reasonable numbers of buttons, a variety of linear controllers, enumeration and informational interfaces, and how the interfaces could be made to work with older clients. Initally introductory section just outlines some of my thoughts for how it would work. Service calls expected to be used are listed. Errors which would be returned are listed with each SWI. Outstanding issues that I can think of are listed at the bottom. Inter-driver interface is not defined here; it would essentially fall out of the external interface and how the Joystick controller module would operate. I suspect some of this won’t format well… Oh for a sensible documentation format… Joystick interfaceIdeas for a proposed Joystick interface, replacing the dedicated hardware vendor supplied driver with a generic This does not allow for an upgrade path for existing Joystick driver modules. There may be up to 255 joysticks using the current selection mechanism (joystick 255 reserved). Joysticks are registered through a Joystick_Register, and deregistered with a Joystick_Deregister SWI. On registration the joystick supplies a descriptor block that describes the joystick’s name (if any), Inputs:
Outputs:
Joystick_Read calls are split into sections:
Joystick_Register=> R0 = pointer to joystick descriptor (will be copied): +0 pointer to name of the joystick device (or some identifing mark), will be copied +4 pointer to entry point for joystick requests +8 private word to pass on calls to entry point in R12 +12 joystick support flags (must be 0, to define future interfaces) (might include flags indicating support for force feedback or LED returns) +16 number of inputs supported +20 pointer to input definition blocks (one for each input): +0 input type (see below) +4 input usage (see below) +8 input location (see below) +12 minimum value (only for linear controls) +16 maximum value (only for linear controls) +20 rest position (only for linear controls) +24 pointer to default mapping of buttons to input identifiers (terminated by -1) +28 input identifier for the default linear control <= R0 = joystick number Errors possible: CannotRegister Joystick_Deregister=> R0 = joystick number Errors possible: NotRegistered Service_Joystick 0 – Joystick module initialisedIssued on a callback by Joystick when the Joystick module starts to allow drivers to register themselves. Service_Joystick 1 – Joystick module finalisedIssued on Joystick module finalisation, for Joystick drivers to become quiescent. Service_Joystick 2 – Joystick registered
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Rick Murray (539) 13839 posts |
Right now I’d settle for expanding the buttons to return all of the bits. Remapping a joystick should be something a user does if they want to change the default assignments, or they have a notably different joystick, not a necessity because ten bits are arbitrarily stuffed into eight, with two bits thrown away. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Jon Abbott (1421) 2651 posts |
Point taken.
That is covered by the other Joystick thread which is focused on the hardware layer interface
Features are already defined by the USB HID standard, I don’t think we need reinvent the wheel.
Agreed
As we’re defining a new standard, I don’t think we need to provide multiple application interfaces. The existing Joystick_Read has the simplest form of use coverage for most games.
Buffering has not been an issue to date as generally a user can’t mash the buttons quick enough, but I understand your point. Provided a game checks inputs during any framesync delays, non-buffered should be sufficient.
I believe we’ve already reached a consensus that we will use JoystickV for the hardware interface in the other Joystick thread With regard to the remainder of your 2nd post, although very thorough, I would say its overly complicated for a game developer to implement and some of what you’ve detailed needs to shift over to JoystickV as its hardware layer.
We’re defining a new interface so do not need to consider backward compatibility. Other than USBJoystick and a few I maintain, I’m not sure there are any existing Joystick Modules that run on RISC OS 5. Provided Joystick_Read 0/1 continue to provide basic input from the primary Joystick, we’re not going to break any existing usage. I’d really like to see feedback from developers that are potentially going to be implementing this in games. The OP was based on my experience of getting existing games to support Joysticks under RISC OS 5 over the past year and just an idea to kick off the application layer discussion among application developers.
I agree, I never really understood why Joystick_Read 0/1 were limited to 8 although to be fair, at the time Joysticks only had one fire button. Hopefully, once Richard gets involved in the discussion we can get the extra buttons implemented in the next USBJoystick update.
Also agree, as the alternative leaves the decision to the game developers, many of whom won’t implement reassignment. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Rick Murray (539) 13839 posts |
As someone who has just done this – all I ask for is that all of the buttons be available to be read. I don’t plan on implementing redefinable buttons. There’s no point when there’s a remap command that will do it. A remap command that could also be useful for adjusting the controls of different styles of joystick. In fact, the only thing I think is missing from that (it’s only a small thing, and might be possible – I’ve not tried) is to assign multiple buttons to the same bit in the SWI – so if there are two shoulder buttons instead of one, you can map it so both do the same action.
Brilliant! ;) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Chris Mahoney (1684) 2165 posts |
Not just more buttons, but programmable buttons. For example, the two ‘triggers’ (“L2” and “R2”) on the PS5 controller can have their resistance set by a game, adjusting how hard you need to pull them before they activate. There’s also a trackpad :) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Richard Walker (2090) 431 posts |
Sorry for the lack of response. I’ve had the ‘delight’ of trying to move over the last few months, and it’s still ongoing! I think it seems entirely sensible to go for any quick wins, such as allowing more button statuses to be included in Joystick_Read. I think we can safely say that stuff Acorn might have marked as ‘reserved’ is, well, no longer reserved – they had their chance, and chose to exit the market instead. :) I do like the fully-blown ideas from Charles & Jeffrey regarding a ‘base’ and then having drivers to register/deregister different types of hardware. This is something that has been nagging away in my head ever since I developed USBJoystick: half of it is really ‘joystick’, and the other half is ‘USB’. If someone wanted to knock-up, say, a GPIO interface for a joystick, then it would make sense to split it all out and be able to load multiple modules: Joystick, USBJoystickDriver and BlahGPIOJoystickDriver. However, at this moment, I was only implementing an existing API (for classic games) so all of this is mere implementation detail, and we can change it at any point in the future. Secondly, you can get a USB joystick very cheaply – are people really going to be rigging up other hardware interfaces? USBJoystick has probably been used by less than a dozen people, so I cannot imagine much of a userbase for that! When it comes to extending the API for game writers, I didn’t feel I knew enough about it. I’ve written zero joystick games for RISC OS, and have zero experience of what joystick APIs look like on other platforms (e.g. SDL2 – so thanks Cameron for your comments). Regardless of what gets implemented, never mind when, getting the API right is important, as obviously we can’t go making sweeping changes once it gets a few games using it. I was thinking of something where we could provide: 1) a list of connected controllers 2) a ‘full read’ which would list out each button/axes and the min/max/live values. Further down the line, something which could list and control capabilities like ‘force feedback’. For (2) I was thinking of going closely with the USB HID spec with regard to button and axis names – but maybe that’s not a good idea? I agree with Jon that it would be good to look at what sort of things game authors want (e.g. Rick with ‘more buttons’) and what would make porting games/libraries easier. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Charles Ferguson (8243) 427 posts |
That is one source of information. I wasn’t stating what source were to be used, just that that should be the way that you approach things. Not by randomly shoving extra bits onto an already bad interface. The HID spec is hideously (no intended) complex for handling the different button types, so in my design I proposed I suggested I selected only the two types of inputs which are required right now, and which offer the greatest benefit, and allowing the design to expend to other types with clients being able to identify and expand beyond them without redesigning the API again.
I’ve skimmed that thread. I don’t see much of value in there [I meant until I came across your JoystickV proposal] One thing I see is:
That’s a bad idea. In the first case, vectors are in short supply and adding another would potentially preclude the use on older systems without extended vector numbers. Secondly they’re useful for extension of interfaces, and there’s pretty much no useful way you can provide an extensible interface using a joystick interface which doesn’t involve calling all claimants for them to filter the call – calling everyone and asking them if they’re interested in servicing a call, is a bad interface from a design and performance perspective, particularly for a collection of devices which can appear and disappear dynamically. Similarly the ‘pass SWIs over a vector’ is used by a few modules and really doesn’t help provide a consistent interface. Passing intent over a vector is better, but as stated introduces overhead that you wish to avoid. Providing a registration interface is far more in line with other users. I see a design from yourself in https://www.riscosopen.org/forum/forums/5/topics/2504?page=2#posts-31843 but I strongly disagree with the use of a vector for such things. Also… the API talks about Wimp features… WTF?! nothing in the low level interfaces for joysticks should have anything whatsoever to do with the Wimp. [The actual content has a lot of reasonable things, and is similar to what I proposed in some respects] That was in 2014. I assume that you’re referring to some other discussions or prototypes that someone has put together? Seriously… this sort of work should take just a couple of weeks to put together, not 7 years.
You always consider with backwards compatibility. That consideration can be that we don’t need to worry, but you always consider it. I offered a possible suggested way to make that work, but if you have people who do have such interfaces you need to consider how they will be affected, and whether there is a way forward. Otherwise you have a CDFS 3. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Jon Abbott (1421) 2651 posts |
Jeffrey would not have suggested using a vector if it was a potential issue. It seems like the perfect solution to me as it avoids issuing Services or SWI’s which can cause issues when threaded. An SWI to Register/Unregister as you’ve suggested works equally well – RTSupport uses that method, but generally where driver support has been added, vectors have been the method. eg GraphicsV
What older systems do we need to take into account? We are defining a new standard for a future build of RISC OS 5. Out of scope are all previous versions of RISC OS and all machines that can’t run the latest build of RISC OS 5.
The Configuration app needs to show the Joystick and its buttons for any Configuration extension added, this is to allowing users to reconfigure button/axis mappings, set deadzones, calibrate etc.
In a corporate environment perhaps. Joystick support isn’t exactly a priority as I’m possibly the only developer that has any need for an API at the moment. Up until quite recently nobody was developing games for RISC OS, so there was no need to even support Joysticks under RISC OS 5.
Having intimate knowledge of CDFS, the issue there wasn’t so much backwards compatibility but a lack of open documentation, but I understand your point. I’m not aware of any modern machines that support legacy Joysticks. I suppose you could connect RTFM via Econet on a RiscPC, but that’s not a supported scenario for any existing games. I feel we should stick to USB Joysticks and put everything else out of scope, including precluding a backport of the API to any other OS versions. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Richard Walker (2090) 431 posts |
Just a few comments. I am not interested in older hardware or OS versions. I don’t see the point in worrying about decades-old systems. They can be left alone. On the timescales, yeah, it is mad that things take years. But that is how things are here. RISC OS is a hobby. Before that, I have got a family and a full-time job. I take my hat off to those who can program professionally all day then carry on through the evening – I can’t. I have recently moved house,and the Pi is in a box… Somewhere! The great thing is that anyone is welcome to contribute (to anything). There are people here who do, but there are many more who just talk about it. There are even some who hint at making/having all sorts of treats, but don’t deliver. That is all fine. It is a hobby for everyone, as I say. One thing on my to do list for USBJoystick is to put the source in github/gitlab. I was waiting for a RISC OS git client. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Jon Abbott (1421) 2651 posts |
Over Christmas, I’ll flesh out the Joystick SWI’s and hardware driver API, taking on board feedback from this post and the other thread. Having spent a week pondering, I think I’ll take Charles’ suggestion and use a Register/Unregister SWI for the drivers to register with Joystick as it removes any OS dependency. For the interaction between Joystick and hardware driver Modules, it will be direct code calls (like GraphicsV) to avoid threading issues. Games will remain using Joystick_Read, but with additional reasons to allow querying multiple axis/buttons at once (like OS_ReadVduVariables) and reasons for force feedback etc. The driver Modules will be light touch with no deadzone code or scaling, they’ll simply provide updates of device inputs to Joystick. Joystick will handle scaling, deadzones, normalization, button/axis mappings etc. with a Configuration app to allow the user to remap buttons/axis, device order, set deadzones etc. I might also add a reason for Games to register with Joystick, this is primarily to allow per-game configuration preferences in the Configuration app. For example, if you have an XB360 controller and a Logitech Steering Wheel attached, you’d want Zarch using the XB360 as primary and Saloon Cars the Logitech. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Cameron Cawley (3514) 157 posts |
Sounds good. A few additional comments:
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Richard Walker (2090) 431 posts |
Ahh… Maybe the HID extensions are worth looking at. Are they documented publicly? |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Cameron Cawley (3514) 157 posts |
There’s a section in the manual included in the download that describes both the existing Joystick API and the extensions made to it. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Jon Abbott (1421) 2651 posts |
!HID extends Joystick_Read 1 R1 to 32 buttons as proposed in the OP and is now in the documentation. It also adds: Joystick_Read 2 (SWI &43F40)This is an extension to the existing SWI Joystick_Read. The call returns a pointer to a structure containing all data of the joystick. Entry
Exit
UseThe first word of the structure gives the number of parameters following, so that it can be extended in the future. Your code should check the first word before trying to read past the end of the list. The Joystick module maintains this structure for each channel, so there is no need to make your own local copy of it. Joystick_Info 0 (SWI &43F43)Read global information from the Joystick module. Entry
Exit
Flags
Joystick_Info 1 (SWI &43F43)Read global information about a joystick port. Entry
Exit
Flags
Joystick_Info 2 (SWI &43F43)Read controls calibration. Joystick_Calibrate (SWI &43F44)Provides flexible calibration for each joystick individually. Entry
ExitAll registers preserved. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Jon Abbott (1421) 2651 posts |
My comments relating to !HID and calibration. The Joystick Module will need to jump to v4.00 as HID is v3.x Joystick_Read 2 as implemented by !HID is very specific to a particular Joystick type and isn’t something I’d look to include in any future spec. I’d prefer to let the caller decide what data they want returned. Joystick_Info has never been documented and I’m not even certain it was part of the original Acorn spec. Joystick_Info 0 will need to be implemented (no. of Joysticks connected), although I’m not sure why it needs its own SWI and can’t be a reason code off Joystick_Read. Joystick_Info 1 – I’m unclear as to what this reason code is meant to be doing. Joystick_Calibrate / Joystick_CalibrateTopRight / Joystick_CalibrateBottomLeft – I am not convinced these need to be externally accessible from the Joystick Module. Calibration is something you’d only need to do once and it would be better placed in the Configuration control panel, where each axis can be calibrated individually and the settings linked with an individual Joystick either by name or GUID. For USB Joysticks, calibration is mostly redundant as the HID spec includes the min/max values as part of the spec. and the Joystick Module will scale values appropriately. Where it might be applicable is with legacy Joysticks, but I’m not proposing we include legacy devices, only future-proof and cover deadzones that require calibration scaling. There are some issues around calibration, in particular CalibrateTopRight and CalibrateBottomLeft. Many modern Joysticks do not have a top right/bottom left unless normalized. XB/PS thumbsticks are (almost) circular and normalizing an XB360 thumbstick feels quite unnatural in games such as Zarch . Where normalization might be applicable is when mapping a circular stick to the mouse pointer. Normalization would need to be on a per-app basis and decided by the app itself. For example, BloodLust might want the right stick normalized as it’s controlling the Mouse pointer and the left stick un-normalized for movement. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Steffen Huber (91) 1953 posts |
Just for the sake of clearing up one minor sideline of the discussion…
I think you missed the point, because CDFS 3 was the topic, and I am fairly sure that you have intimate knowledge of CDFS 2, not 3. Because nobody still around has intimate or even a working knowledge of CDFS 3. Amusingly, I had more docs on CDFS 3 than CDFS 2, but never saw it working anywhere. Maybe ROOL have the source? |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Rick Murray (539) 13839 posts |
Can we please stop with this nonsense. What’s the point of being able to set (or reset) calibration, without being able to read it? This isn’t to say that games should concern themselves with this, it’s more the principle of hiding information behind an “internal use only” tag. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Rick Murray (539) 13839 posts |
Also, Joystick_Info 0 and 1. Shouldn’t the “calibrated” flag be per joystick? It would be easy to get rid of call zero entirely. Simply have call 1 return an error for joysticks that don’t exist, so the caller can just count up from zero to X to enumerate the available joysticks. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Cameron Cawley (3514) 157 posts |
Any update on this? Is there anything I can do to help move things forward? |
Pages: 1 2