between StyleI.player and MenuI.player is that StyleI is set even
if there's no attached MenuButton, and MenuI.player is set even
if there's no attached column. That's an odd distinction, anyway.
Move input.MenuI.player to input.pn. This also puts it in the
same place as input.mp.
essentially being used as a hack to see if the style is set, and
as a shortcut for converting from StyleInput back to GameInput,
complicating InputEventPlus in the process. Remove it, and just
pass along the PlayerNumber when it's actually needed.
(incremental commit)
- 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.
Glenn Maynard