added a simple helper print method to know what key/button is being pressed,
controlled via a bool cvar "in_namePressed" 1 or 0.
I tested it and it works with keyboard, mouse and gamepad.
- treat DPad as 4 regular buttons (was already the case mostly, but now
the code is simpler)
- rename in_invertLook to joy_invertLook and in_useJoystick to
in_useGamepad and remove unused CVars
- make controller Start button generate K_ESCAPE events, so it can
always be used to open/close the menu (similar to D3BFG)
- move mousecursor with sticks, A button (south) for left-click,
B button (east) for right-click (doesn't work in PDA yet)
- removed special handling of K_JOY_BTN_* in idWindow::HandleEvent()
by generating fake mouse button events for gamepad A/B
in idUserInterfaceLocal::HandleEvent()
- renamed gamepad/joystick actions and keys to have some meaning
for buttons (instead of just JOY1, JOY2 etc)
- compiles with SDL1.2 again (there gamepads aren't supported though)
- shorter names for gamepad keys/axis in the key bindings menu
If in_ignoreConsoleKey is set, the console can only be opened with
Shift+Esc, not `/^/whatever, so you can easily type whatever character
is on your "console key" into the game, or even bind that key.
Otherwise, with SDL2, that key (KEY_SCANCODE_GRAVE) always generates the
newly added K_CONSOLE.
in_kbd has a new (SDL2-only) "auto" mode which tries to detect the
keyboard layout based on SDL_GetKeyFromScancode( SDL_SCANCODE_GRAVE ).
Wherever Sys_GetConsoleKey() is called, I now take the current state of
Shift into account, so we don't discard more chars than necessary, esp.
when they keyboard-layout (in_kbd) is *not* correctly set.
(TBH the only reason besides SDL1.2 to keep in_kbd around is to ignore
the char generated by the "console key" in the console..)
If a key is pressed whichs SDL_Keycode isn't known to Doom3 (has no
corresponding K_* constant), its SDL_Scancode is mapped to the
corresponding newly added K_SC_* scancode constant.
I think I have K_SC_* constants for all keys that differ between
keyboard layouts (which is mostly printable characters; F1-F12, Ctrl,
Shift, ... should be the same on all layouts, which means that e.g.
SDL_SCANCODE_F1 always belongs to SDLK_F1 which the old code already
maps to Doom3's K_F1).
What's extra nice (IMO) is that when Doom3 requests a *localized* name
of the key (like for showing in the bindings menu), we actually use the
name of the SDL_Keycode that *currently* belongs to the scancode, and
esp. the "Western High-ASCII characters" (ISO-8859-1) supported by Doom3
like Ä or Ñ are displayed correctly.
(I already implemented a very similar hack in Yamagi Quake II and
reused the list of scancodes)
This should fix most of the problems reported in #323
the tables contain character constants like ('ä') that are supposed to
be interpreted as ISO8859-1 or WINDOWS-1252 or sth, but that doesn't
seem to work with MinGW (anymore) - seems like it assumes UTF-8 by
default, and for some reason -finput-charset=ISO8859-1 doesn't help
either, it complains about multichar character constants then..
Anyway, now the table entries are represented as the corresponding
integer constants which seems to work as intended.
Fixes#238
Don't include the lazy precompiled.h everywhere, only what's
required for the compilation unit.
platform.h needs to be included instead to provide all essential
defines and types.
All includes use the relative path to the neo or the game
specific root.
Move all idlib related includes from idlib/Lib.h to precompiled.h.
precompiled.h still exists for the MFC stuff in tools/.
Add some missing header guards.
