the same: "a string suitable for display", but just formatted slightly
differently. Handle these the same way (so hopefully a way to merge
them will become visible).
This also fixes the RageInputDevice dependency on RageInput.
- This reduces the number of types associated with input; adding a
distinct input type doesn't introduce a whole new enumerated type
and related functions.
- Special handling for different devices is needed less often. If you
want to respond to an F1 press, simply check for KEY_F1; the device
type doesn't really matter (though it'll usually be a keyboard).
- This allows cleaner support for generalized USB devices. While they're
usually of the traditional classes (keyboard, joystick) with associated
inputs, they don't have to be.
- Forced casts between parallel types can be removed, and weakly-specified
variables (ints instead of the enum type) can be fixed.
Some things that might have been merged havn't; for example, arrow keys
on a keyboard (KEY_UP) are still distinct from axes on a joystick (JOY_UP).
These may or may not be merged in the future.
Some were: removed PUMP_ symbols. Treat them as generic buttons, and just
give them names with GetDeviceSpecificInputString. It's not worth
introducing more special names for something only used in one place.
me, so I'm cleaning it up.
Add "level" parameter to DeviceInput, indicating the degree the axis
or button is depressed. If it's < 0, it's not an analog input; otherwise,
IET_LEVEL_CHANGED events will come in when the level changes.
Add secondary stick axis inputs, so there's a correct place to put them.
Handle these inputs in ScreenCenterImage. Inputs mapped to gameplay
inputs are always a primary input; otherwise, the first stick is translate
and the secondary is scale. Input is analog when possible; holding shift
reverses the map, so keyboard input works roughly the same as before.
Do away with the special Xbox-specific centering code; use the standard
centering matrix. If this doesn't work, any special cases to fix it should be
hidden away in RageDisplay_D3D.
The input maps are likely to work on the Xbox as is, since the SDL driver
maps axes in order, but I can't test it.
This won't work with PS2 converters, since #1: those things map the
secondary axis to seemingly random places (on mine, JOY_Z_UP,
JOY_Z_DOWN, JOY_ROT_Z_UP, JOY_ROT_Z_DOWN), and #2: they
don't identify themselves uniquely. Unless there's a pattern in how they're
mapping that I can't see (since I don't have many converters), this just
can't be done reliably. (No big deal; PCs have keyboards.)
It's also the "preferred" way of doing it, according to the SDL
docs, so maybe it'll work better.
This will reliably queue events, so we can handle coin events during
loads.
It'll queue events a little too reliably; we might want to flush some events
when we load screens.
Steve Checkoway