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 game was frozen (the main menu and console worked though) when
switching from the Radiant to the engine (with F2 or that button).
Turned out common->ActivateTool( false ) must be called if the game window
has forcus, so idSessionLocal::Frame() doesn't return early (and thus not
run the game code).
Furthermore, there was no sound when switching from Radiant to the game,
because the SoundWorld was set to sth editor-specific. Fixed that as well.
as we do int buttonIndex = ev.button.button - SDL_BUTTON_LEFT;
it's only consistent to do if(ev.button.button < SDL_BUTTON_LEFT + 8)
it doesn't really make any difference as long as SDL_BUTTON_LEFT is 1,
but this way it's safe for SDL3 or whatever future version might break
the ABI.
The first row of AZERTY-Keyboards (used in France and Belgium) doesn't
have numbers as keys but ², &, é, ", ', (, -, è, _, ç, à, ), =
(with small differences between France and Belgium).
For some of those keys we don't have keycodes - and neither does SDL2.
See also https://bugzilla.libsdl.org/show_bug.cgi?id=3188
As a workaround, just map those keys to 1, 2, ..., 9, 0 anyway, as those
are keys Quake2 already knows (and those chars are printed on the keys
too, for typing they're reachable via shift).
This workaround only works for SDL2, as SDL1.2 doesn't have Scancodes
which we need to identify the keys.
This should obsolete one part of pull request #135
It's an SDL_TEXTEDITING event which we seem to get on Windows whenever
the Window gains focus (or is created). I think it can be safely
ignored, so that's what I do.
I also changed how those warnings are printed - as a hex number now,
because they're defined as hex numbers in the SDL source and it's easier
to find out what kind of event it is this way.
If res_none (event with .evType == EV_NONE) is returned,
idEventLoop::RunEventLoop() will assume there are no more events this
frame => pending events will be delayed til next frame (or later if
again res_none is returned in the meantime).
So res_none shouldn't be returned just because there was an SDL event
we didn't care about or we did care about but don't generate a doom3
event for (but toggle fullscreen or something).
Instead we should just fetch and handle the next SDL event.
There used to be a bug (discussed in #40), that ALT was still set after
using ALT-Tab. Thus when next pressing enter fullscreen was toggled.
This should now be fixed by unsetting the modifiers when focus is
regained (SDL_ACTIVEEVENT or SDL_WINDOWEVENT_FOCUS_GAINED).
New CVar "in_kbd" to set the layout for the keyboard. SDL 1.2
doesn't offer any way to determine it, and we need this feature
to use the same key for toggling the console independent of the
keyboard layout.
The old "in_nograb" from the Linux backend is still supported.
