CONTROLLERDEVICEREMOVED, which increments on each unplug |
Jared Maddox
Guest
|
The data structure would have to depend on what diversity of things you wanted to support. For example, you could break a hypothetical flight-sim throttle into a base unit with a few switches, and a hand-hold with a hat/dpad, maybe a trigger, and a few buttons. Where you wanted to stick the actual throttle axs itself would be an issue, however. I think that the most "powerful" possibility would be to divide devices into "signals" and "groups": Signals: Each button/axis/etc would be assigned a "signal id" in integer form (with multiple e.g. usb-NES controllers presumably having identical ids for the "A" button, just as an example), and querying values/signal types/etc would happen by using a device id and a signal id together. Groups: Each "behavioral component" would be assigned a "group id" in integer form (once again, identical groups on identical devices usually == identical ids), with each "group id"/"device id" pair being associated with a list of "signal id"s. The full API would look something like this: int SDL_GetNumDeviceControls( SDL_DeviceID id ); int SDL_GetInfoDeviceControl( SDL_DeviceID id, int control, SDL_ControlData *dst ); int SDL_GetNumDeviceGroups( SDL_DeviceID id ); int SDL_GetNumDeviceGroupControls( SDL_DeviceID id, int group ); int SDL_GetIDDeviceGroupControl( SDL_DeviceID id, int group, int index ); What type EXACTLY SDL_DeviceID and SDL_ControlData would be, I don't know (though I would prefer SDL_ControlData to be a structure with a caller-populated size value, to support unforeseen future extensions). I do, however, think that this could probably go into an extension library fairly easily, and personally I would want to see everything from joysticks, to keyboards and mice, all rolled into the same system (consider: some of the MMO gamer mice apparently export a keyboard interface to provide extra buttons due to limitations in the USB mouse HID spec... why not represent those buttons via the same interface as the rest of the mouse buttons?). Now, for a throttle you might not need to be able to express that two groups of controls both share a control, but what about weird stuff like the Namco NeGCon (I think there was an even weirder 6DOF one that used a trackball or something for the joint, too)? I doubt that there is any sensible rule of thumb for how to resolve multiple claims on a control for something like that. Your "types" would presumably be applied to control groups. You'd need to do an enumerate cycle to find the particular controls that you wanted (presumably THAT info would be in the SDL_ControlData structure), but it should work fairly well, and it wouldn't require adding yet another input extension (beyond maybe some types or something) in two years. It's also a fairly simple API: five functions, and in the worst case probably no more than three structures. For the *InfoDeviceControl function, maybe a skeleton implementation something like this: struct SDL_ControlData { size_t len; float val; }; struct SDL_ControlData2 { SDL_ControlData cdat; Uint32 type; }; int SDL_GetInfoDeviceControl ( SDL_DeviceID id, int control, SDL_ControlData *dst ) { switch( dst->len ) { case SDL_CONTROLDATA2_LEN: ( (SDL_ControlData2*)dst )->type = ???; dst = &( ( (SDL_ControlData2*)dst )->cdat ); case SDL_CONTROLDATA_LEN: dst->val = ???; break; default: return( -1 ); } return( 0 ); } _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||
|