Game pad and joystick support
Dave Higton (1515) 3404 posts |
I wouldn’t. I’m not arguing on the grounds of any difficulty in making the module behave as you say – it’s dead easy. My reasons are:
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Jeffrey Lee (213) 6046 posts |
If the game doesn’t have configuration options then it’s a bad game and you should ask for your money back :-)
If you’re talking about device-specific issues (e.g. Dave’s GM-1300 having a Y axis that’s inverted when compared to the Joystick SWI spec) then I’d expect those issues to be handled internally by the USB joystick driver. E.g. by reading the USB descriptors to work out which axes need inverting. Or if the descriptors don’t offer that information then the USB joystick module can easily provide a config file or *command as appropriate. There are some settings which it might make sense to have at the API level, e.g. calibration/deadzone controls, just like how OS’s have a common interface for setting the mouse speed and double click delay. But for something as fundamental like making sure negative Y = down I’d expect it to be fully managed by the driver, as the API spec clearly states what directions the different values should correspond to. And if not, it’s a bad driver and you should ask for your money back :-) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Rick Murray (539) 13406 posts |
Which assumes that all future devices will be compatible with this API…
This is why we need nice pointy-clicky configuration options, not mucking around in obscure files. ;-) If it is not a trauma to do, I would say to give an option to invert the settings (X, Y, or X&Y). Why? If we have an odd joystick (or odd user), having the option means the user might be able to make the joystick work the way it is desired. If we have no such option, then there’s no flexibility for oddities. Two examples. When I was at college, there was a girl who preferred to use her mouse upside down. One of the nerds put together a custom DOS mouse driver for her. Second example – my (musical) keyboard. I don’t remember what way around my sustain pedal is (close circuit on press, I think). If the pedal operated the other way around, you are supposed to press and then release it as you switch the keyboard on. Then the keyboard remembers the pedal setting is not the usual way around… tl;dr – options are good ;-) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Dave Higton (1515) 3404 posts |
Options are what turned Microsoft’s products into the complicated bloatware they are. Specifications are good. Sticking to specifications is good. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Steve Pampling (1551) 7932 posts |
aaah, sweet. Result? |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Steve Pampling (1551) 7932 posts |
Options are what turned Microsoft’s products into the, high volume sales, complicated bloatware they are. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Malcolm Hussain-Gambles (1596) 811 posts |
The irony is Microsoft has now reversed this trend with the likes of server 2012. But there again there is Windows 8.1…. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Chris Evans (457) 1614 posts |
I certainly remember a number of customers complaining that the joystick control on some BBC games was the wrong way! I’m not a frequent games player but can’t recall ever seeing an option in a game to reverse joystick up/down. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Jon Abbott (1421) 2601 posts |
My requirement is for legacy games. They’ll require shim modules to go from the existing API’s to any future API, so I can include configuration options to allow the user more control over the Joystick behaviour. My original thinking was a Joystick configuration applet which handled all the configuration on a per Joystick basis centrally and one generic HID Joystick driver. The API can have zero configuration options, so long as whatever sits between the API and the user provides options. We also need the ability to map Joysticks to keys / Mouse etc, which I planned on implementing at the shim layer, although centrally would be better, be it within the API or via a driver. Perhaps it would help make things clearer if we defined the interface layers from USB through to the game. Do both application and device layer drivers register with the Joystick API, which acts as a transport layer between the two? ie USB > HID driver > Joystick API < Joystick Module < Game The Joystick Module in this scenario being the existing Acorn / RTFM / VOTI Joystick interface modules rewritten to interface to the hardware through the API. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Rick Murray (539) 13406 posts |
I’m sorry… This forum is a cgi-bin program? What’s this Ruby thing? Why is it on Rails? Why is my blog written using something different? Why do we talk about C and Lua and such when we have BASIC? Options are good. You can’t use an example of a poorly implemented swiss army knife to demonstrate that options are bad, because anybody can ask you who your provider is and why you picked them…
The problem is, any idiot can write a specification. Even now, in the left corner the EU is trying to standardise mobile phones to use a common charger (which is likely to be something akin to MicroUSB)….and in the right corner, they’ve gone all “whoo!” over Apple’s Lightning connector so they’re bashing out a spec for a reversible USB connector (seems to me to be a solution in search of a problem, or maybe just patent-bait? ;-) ).
Mmm… You were saying? (^_^) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Rick Murray (539) 13406 posts |
She used her mouse happily upside down, with the back of her palm to push the buttons, everybody else scratched their heads. I think the guy might have written a Windows 3.1 driver for her as well, but I don’t recall. When I last saw her (~’93), she was trying to get to grips with TurboPascal and WordPerfect (and not much liking either). |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Dave Higton (1515) 3404 posts |
Options are not necessarily good. They can make all sorts of things less clear. I don’t want to get the thread sidetracked into a debate about specifications that are irrelevant to what we are talking about here. We have a specification for the Joystick module. It specifies the relationship between stick movement and resulting number unequivocally. That’s good. There is no doubt about what we’re dealing with. All existing applications that use joysticks have been written according to that specification. The USB HID standard is equally unequivocal about the relationship between stick movement and resulting number. That’s good. Any driver that I or anyone else comes up with can be expected to work consistently. The relationship between stick movement and what happens on screen is the province of the application developer. To suggest making the driver inconsistent in its behaviour, is to put forward a solution in search of a problem. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Dave Higton (1515) 3404 posts |
The most difficult thing that a USB joystick driver system has to do, is to parse the HID descriptors of attached USB devices. I was trying to work my way through a set of descriptors these last two evenings. (The mists may be clearing, ever so slightly.) Is there any mileage in a generic HID parser that can be asked to determine whether particular functionality exists in a HID? This is just a naive idea. I can’t help thinking that all sorts of HID parsing functionality will be duplicated if we don’t produce a generic parser. But, equally, a generic parser might be too difficult to achieve. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Andrew Conroy (370) 724 posts |
Is it worth trying to contact Paul Reuvers at Xat, as his !HID claims to have a “full HID class parser” in the USBHID module. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Jon Abbott (1421) 2601 posts |
The API should follow the USB standard and shouldn’t need any configuration. I think the point being made is that there should be a user configurable GUI that allows for inversion, button mapping etc. This should sit at the module level. Forget about the existing Joystick module, we can drop it and create a shim module that mirrors it’s behaviour through for existing games, likewise for RTFM and VOTI. A lot of this depends on how application layer modules interface back to the API, hence why I suggested firming up where the API sits and how drivers / Joystick modules interface with it.
It would make sense, as it may not need too much work to get running on the current OS build. I’m surprised it doesn’t work already, but I’ve not tried on either a Pi or the Iyonix. I would expect it to work on the Iyonix and fail on the Pi. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Dave Higton (1515) 3404 posts |
There is no particular reason to change the RISC OS API to match the USB standard. (Clearly the joystick system has to communicate with USB devices according to the USB specification, but the two things are not connected.) I would expect the joystick system to conform where possible with the existing RISC OS Joystick module API. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Jon Abbott (1421) 2601 posts |
We haven’t defined the API yet. The exist Joystick module was pretty much killed off when the OS went 32bit, you can count the number of 32bit games that support joysticks on one hand. I’d suggest starting again from scratch and defining a new API that better matches modern hardware and create a shim “Joystick” module to provide the existing Joystick API. My view would be to have an API that both the drivers and the application interface modules register with, along the lines of GraphicsV … ie JoystickV We have an opportunity to start with a clean slate. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Rick Murray (539) 13406 posts |
I concur. For an example of why, compare OS_Mouse with modern pointing hardware – and I don’t just mean tablet touch displays; think about scroll mice, pen pressure, touchpad behaviours. If we are to support any of that sensibly, we’d need an entirely new protocol and a compatibility bodge. Now, look carefully at the joystick API and at modern joysticks. Is the API feature complete? Here is one to ponder that I had to consider with my MIDI stuff – what happens if the joystick “disappears” in the middle of a game? The beauty of USB plugs is the damn things have no resistance to force, the slightest big of enthusiastic whoo-hoo will have you looking at a disconnect. So what does your envisaged driver do? What happens if the user hastily shoves the plug back in, will it resume? What if it wasn’t plugged into the same socket it fell out of? Would your driver choke at that or attempt to make guesses? What if the game is querying the joystick state in the mean time? Will you report fake values? Silently fail? Or raise an error? If you have seen my MIDI document, you might have noticed a fair few bodges in there to attempt to keep broadly the same API as Acorn designed in the mid ‘80s while dealing with the then-unforeseen possibility that the MIDI device may suddenly vanish. I mean, AKA10 podules just don’t fall out, so you either had MIDI hardware or you didn’t. With USB MIDI, the hardware is at the other end of a USB connection, so the driver has to be aware of this and in my case I silently discard data while flagging a new error byte value. It is either that or raise an error that I’m pretty damn sure nothing is going to know how to handle. I want to design a newer better API that is more relevant to modern equipment, but need to finish implementing the old way first. I tell you all of this to point out some obvious limitations in older protocols. Now I shall tell you this too: I only ever used one joystick on RISC OS. It was a big chunky thing that plugged into the mouse port and faked mouse movements. It worked quite well with Interdictor. My other joystick is attached to an old PS2. I’m kind of crap at Ghost In The Shell, but I like Liberty City because if you don’t pick up Tony you are fairly free to do alsorts in the big sandbox. Let’s just say it is a fun way to blow off some steam. I’d love to explore the Resident Evil (Veronica) world, but there appear to be no built in cheats for that, and I suck so hard I’m dead before I get outside. I much prefer to get immersed in a good story than test my ninja skills (don’t have any). Pretty much the only game in recent times that has interested me has been “The Last Of Us”. Just a bunch of random thoughts, feel free to ignore, but please don’t be constrained by an ancient protocol when you have a rare opportunity to do something better. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Jon Abbott (1421) 2601 posts |
API needs to be something along the lines of: JoystickV Entry:
Reason codes:
Reason code 1:
Reason code 2:
Reason code 3:
Reason code 4:
Reason code 5:
Device capabilities list: A list of device buttons etc, terminated with FFFFFFFF
Input Types:
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Rick Murray (539) 13406 posts |
I’m a believer in not making things more long winded than they should be. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Jon Abbott (1421) 2601 posts |
That’s just a rough idea of the sort of API I was expecting, so feel free to change any if it or replace with something better. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Jeffrey Lee (213) 6046 posts |
Muhahahaha!
Also, you need to take into account how games are going to use the API. Making it easy for games (or other software) to use should really be the driving factor in the design, at least for the bits which the game is meant to interface with. One thing which I think would be nice from a games perspective would be an OS_ReadVduVariables-type call, where you give it a joystick ID, a list of inputs you want to read, and a buffer for the results. Advantages:
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Jon Abbott (1421) 2601 posts |
Games need to go through an application layer module which hooks into JoystickV. Modules being Joystick / VOTI and RTFM module emulators and a new one (or extend Joystick) that we need to define which supports feedback etc |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Dave Higton (1515) 3404 posts |
Well, I’ve just been driving a radio controlled mini around the computer room here, controlled by the GM-1300. So I have achieved one small experimental stage of progress: I have written a Joystick module, dedicated to the GM-1300. Strictly, it’s dedicated to one of the three modes of the GM-1300. This leads on to another problem: I don’t know how to tell the modes apart by means of USB. I can see which colour an LED is showing (red, green, orange), but that’s no use to the module. The values given out in one of the modes are hugely different from the others. The further I go, the less likely I think I am to take this to any useful generalised state. It’s going to be considerably more difficult than the USB Audio class driver – and even less rewarding. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
SeñorNueces (1438) 160 posts |
Hi, It’s 2016 and I was wondering about joystick support on modern Risc OS. Has anything happened regarding this in these two years? |