Sys_GetEvent()
* renamed res_none to no_more_events, because that's what the
caller assumes when getting that event
* don't return res_none on unhandled events, instead get the next event
until there is a handled event or no more events
(=> if -> while, return res_none -> continue)
* Mapping to Doom3 keynum handled differently for SDL1 vs SDL2, see below
For SDL2 we don't use SDL_KeyToDoom3Key on the keysym anymore, but map
the SDL2 scancode to Doom3/Direct-Input scancodes instead (the keynum_t
K_* constants are really used as scancodes!).
This mapping is done in sdl2_scancode_mappings.h scancodeToKeyNum[].
In sdl_events.cpp there are static SDLScanCodeToKeyNum() and
KeyNumToSDLScanCode() functions that use this scancodeToKeyNum[] array.
Sys_GetKeyName() now does something sensible for SDL2 by using
KeyNumToSDLScanCode()
This is also used to implement idKeyInput::LocalizedKeyName() for SDL-targets
(for SDL1.2 the behavior doesn't change much, though, as it doesn't have
consistent scancodes - Sys_GetKeyName() will just return NULL and
idKeyInput::LocalizedKeyName() will fall back to the old default)
turns out that both d3bfg and cegui use direct input scancode numbers
to represent keys internally.. now isn't that fucking convenient!
d3bfg was missing some, though, so I added them
strdup() and free() aren't really the right tool if the size of the
buffer is known anyway (and quite small, currently 32 chars)
while at it, I renamed s and s_pos to str and str_pos for better
readability
* Tested in Linux with both XBox360 wireless and Logitech F710 gamepads.
Should work with any XBox gamepad clone wired/wireless.
* Works well using SDL 1.2 or SDL 2.0
* SDL scan values are currently hard-coded. Note sure how to implement
remapping at the moment (config file, GUI, ...).
note, that it is expected that this libjpeg is newer, therefore some files needs to be patched
to compile.
This patch is used for Debian -- Debian uses libjpeg-turbo, but I assume that it will also compile
against a recent libjpeg.
Commit 7e21048 introduced a change in the save game files strutcure.
This makes the game crash whenever you load saved games created with a prior version of the code.
This commit tends to fix this issue.
However, save game files created between commit 7e21048 and the current one will not load correclty.
Unless the user change the saved game's saveVersion number in game.details.
