I read that comment as "bindings for these keys won't execute when in the menu", but it should be read as "no new bindings can be made for these keys through the bindings sub-menu", which is actually correct.
git-svn-id: svn://svn.code.sf.net/p/quakespasm/code/trunk/quakespasm@1074 af15c1b1-3010-417e-b628-4374ebc0bcbd
This never really belonged in keys.c (should have been handled in the backend instead), but now that we have separated Key_Event()/Char_Event() this no longer serves any purpose at all.
git-svn-id: svn://svn.code.sf.net/p/quakespasm/code/trunk/quakespasm@1072 af15c1b1-3010-417e-b628-4374ebc0bcbd
If an entity is visilbe from MAX_ENT_LEAFS (32) or more leafs, don't try to vis-cull it, just send it to the client.
This should completely eliminate any flickering entities, no matter how many leafs they're visible from.
This could potentially increase packet sizes a bit.. but ent->num_leafs == 32 never happens in id1 epsiode 1, so it will not cause any increase on those maps.
hip1m1 has one entity (a rotator) that is caught by this change and will be always sent.
see e.g.
http://forums.inside3d.com/viewtopic.php?f=1&t=5554http://www.celephais.net/board/view_thread.php?id=60452&start=1235
git-svn-id: svn://svn.code.sf.net/p/quakespasm/code/trunk/quakespasm@1069 af15c1b1-3010-417e-b628-4374ebc0bcbd
Before, "gamekey" was the special case, now "textmode" is. We are now more precise about when we activate "textmode", e.g. we only do this when the console, messagemode, or a textfield in the menu are active. The trigger for doing this was this line on the "SDL_StartTextInput" page of the SDL2 wiki: "On some platforms using this function activates the screen keyboard.". Although we currenly support no such platform, it's good te be prepared, and what we do now is more correct anyway.
git-svn-id: svn://svn.code.sf.net/p/quakespasm/code/trunk/quakespasm@1066 af15c1b1-3010-417e-b628-4374ebc0bcbd
in_keys.c: Key_ConsoleBindable: remove redundant check, this is now handled by Key_KeynumToString/Key_StringToKeynum.
in_sdl.c: IN_SendKeyEvents: use a single method for checking whether we have a keydown or keyup event.
git-svn-id: svn://svn.code.sf.net/p/quakespasm/code/trunk/quakespasm@1047 af15c1b1-3010-417e-b628-4374ebc0bcbd
SDL (both 1.x and 2.x) is buggy and can't deal with scaled windows.
But we'd probably want to call this anyway beause it give us full-resolution windows.
git-svn-id: svn://svn.code.sf.net/p/quakespasm/code/trunk/quakespasm@1045 af15c1b1-3010-417e-b628-4374ebc0bcbd
Tested on Linux and Windows with various keyboard layouts. This fixes some text input weirdness on Windows.
Before, we always used the "unicode" field (if available) of SDL's keydown events to overrule the "sym" field with which Key_Event() is called. However, the "unicode" field is only filled for keydown events, so this meant that our keyup events didn't always match their corresponding keydown events. With the introduction of Char_Event(), we can now use the "unicode" field for textinput only, and call Key_Event() with the non-overruled "sym" field. This has the benefit that keyup events now match keydown events, and that we can get rid of several ugly hacks (some platform specific ifdef's and some control character handling).
Note: the translation of the numpad keys to other keys when not in "gamekey" mode was dropped, because otherwise a numpad key could trigger (for intstance) both a textinput and a cursor movement in the console. This is arguably cleaner anyway.
git-svn-id: svn://svn.code.sf.net/p/quakespasm/code/trunk/quakespasm@1042 af15c1b1-3010-417e-b628-4374ebc0bcbd
Before, we stopped processing at the first byte of a multibyte character, now we skip over the bytes of a multibyte character and continue. This will probably not have a noticeable effect, but it's arguably more correct.
git-svn-id: svn://svn.code.sf.net/p/quakespasm/code/trunk/quakespasm@1040 af15c1b1-3010-417e-b628-4374ebc0bcbd
In hindsight this really was "shooting a cannon at a mosquito". Even at a resolution of 320x200 we don't actually draw any keybindings off-screen, we just draw the last one very close to the edge (similar to the version string in the bottom right of the console). Although that is not visually pleasing, it is not that likely to actually occur (not many people will use a resolution of 320x200 or set the 2D scaling to the maximum value), and is not worth always having one keybinding "missing" at any scale setting.
(If we even want/need to readd this, it should work dynamically, e.g. calculate a "virtual resolution" from the actual window resolution and the actual 2D scaling value.)
git-svn-id: svn://svn.code.sf.net/p/quakespasm/code/trunk/quakespasm@1039 af15c1b1-3010-417e-b628-4374ebc0bcbd
R_DrawTextureChains_Multitexture: revert to the way it was before VBO support was added.
gl_texmgr: expose GL_SelectTexture. make the implementation less convoluted and support 3 TMUs.
gl_vidsdl: check GL_MAX_TEXTURE_UNITS
r_brush: only create VBOs if 3 TMUs available
git-svn-id: svn://svn.code.sf.net/p/quakespasm/code/trunk/quakespasm@1035 af15c1b1-3010-417e-b628-4374ebc0bcbd
build_cross_osx-sdl2.sh: new script for me to cross-build on my linux.
git-svn-id: svn://svn.code.sf.net/p/quakespasm/code/trunk/quakespasm@1034 af15c1b1-3010-417e-b628-4374ebc0bcbd
Partial revert of r1024, since the lastKeyDown stuff is actually needed for SDL2 when the keyboard layout has a printable character that isn't '`' or '~' on the default console-toggle-key (the one below 'Esc'). Instead of hardcoding it though, it is now determined by a new Key_ConsoleBindable function. This makes sure that we don't write an unwanted character into the console as a side effect of opening/closing it, but it still does allow the user to type '`' and '~' in chat messages.
git-svn-id: svn://svn.code.sf.net/p/quakespasm/code/trunk/quakespasm@1027 af15c1b1-3010-417e-b628-4374ebc0bcbd
This was hardcoded in in_sdl.c, now it is handled by Char_Console() itself, like it is in Key_Event().
git-svn-id: svn://svn.code.sf.net/p/quakespasm/code/trunk/quakespasm@1024 af15c1b1-3010-417e-b628-4374ebc0bcbd
Instead, make the backend responsible for calling either or both
of Key_Event and Char_Event under the appropriate circumstances.
For SDL2 this means no change, for SDL1 this means call both when
a key is pressed, but call only Key_Event when a key is released.
git-svn-id: svn://svn.code.sf.net/p/quakespasm/code/trunk/quakespasm@1022 af15c1b1-3010-417e-b628-4374ebc0bcbd
- Reverted the addition of the interpret_shift param to Key_Event
- Now, SDL_KEYUP/SDL_KEYDOWN are converted from SDL scancodes to quake keys, and passed directly to Key_Event with no extra conditions / logic
- When SDL2 is used, Key_Console/Key_Message no longer convert keys to characters to insert in the typing buffer, but all other functionality is unchanged
- SDL_TEXTINPUT calls a new function, Char_Event. This calls either Char_Console/Char_Message depending on the keydest. These just insert the typed text into the buffer
This is cleaner than before because it maintains a clear separation between key presses and characters, whereas the old code was converting characters from SDL_TEXTINPUT back into fake keys and then feeding those into Key_Event. This also fixes Ctrl+C / Ctrl+V not working in the console
git-svn-id: svn://svn.code.sf.net/p/quakespasm/code/trunk/quakespasm@1020 af15c1b1-3010-417e-b628-4374ebc0bcbd
This seems to help fps a fair bit on maps with a lot of world polys like jam2_tronyn. Tried on a few computers with intel and nvidia gpus, windows, mac os, linux, and there's always at least some fps improvement. Best case was 70fps -> 96fps on jam2_tronyn, on OS X + nvidia 650gt.
Interested to hear how this works for amd gpu's, just do a timedemo with and without "-novbo".
Only downside is I had to disable the fast path in Vid_Toggle_f() because at least with SDL1, the vbo no longer works after a toggle. So as a result, fullscreen toggles with alt-enter are slightly slower.
git-svn-id: svn://svn.code.sf.net/p/quakespasm/code/trunk/quakespasm@1018 af15c1b1-3010-417e-b628-4374ebc0bcbd
