because EDICT_NUM() does it already. also move ent->free=false
statement to partial zero-fill case.
Host_ClearMemory(): remove check before free(sv.edicts)
SV_Init(): initialize sv.edicts to NULL (just paranoia)
git-svn-id: svn://svn.code.sf.net/p/quakespasm/code/trunk/quakespasm@1319 af15c1b1-3010-417e-b628-4374ebc0bcbd
ED_Alloc(), therefore such ents will have uninitialized members.
This used to lead to bad crashes with e.g. Rubicon Rumble Pack maps
since svn r1286 when we began allocating sv.edicts using malloc and
only zero-filling when necessary. So, check against sv.num_edicts
and zero-fill the ent properly when necessary.
git-svn-id: svn://svn.code.sf.net/p/quakespasm/code/trunk/quakespasm@1318 af15c1b1-3010-417e-b628-4374ebc0bcbd
MAX_MAP_LEAFS: 65535 -> 70000
MAX_LIGHTMAPS: 256 -> 512
TODO: maybe drop static arrays based on MAX_MAP_LEAFS like, see R_InitVisCache in RMQEngine.
TODO: dynamically allocate the static `lightmaps` array as well; with this last limit increase it's 32MB.
git-svn-id: svn://svn.code.sf.net/p/quakespasm/code/trunk/quakespasm@1312 af15c1b1-3010-417e-b628-4374ebc0bcbd
(just a paranoid safeguard, shouldn't happen in real life.)
git-svn-id: svn://svn.code.sf.net/p/quakespasm/code/trunk/quakespasm@1311 af15c1b1-3010-417e-b628-4374ebc0bcbd
from global to local context, and pass them as params to SV_Accelerate()
and SV_AirAccelerate().
git-svn-id: svn://svn.code.sf.net/p/quakespasm/code/trunk/quakespasm@1309 af15c1b1-3010-417e-b628-4374ebc0bcbd
developer cheat to teleport to a given origin, optionally looking in a given direction.
git-svn-id: svn://svn.code.sf.net/p/quakespasm/code/trunk/quakespasm@1308 af15c1b1-3010-417e-b628-4374ebc0bcbd
The warning from gl_model.c:Mod_LoadTextures() seemed
like a real bug: Eric please check and confirm.
git-svn-id: svn://svn.code.sf.net/p/quakespasm/code/trunk/quakespasm@1301 af15c1b1-3010-417e-b628-4374ebc0bcbd
just in case the compiler toolchain is a multilib one.
git-svn-id: svn://svn.code.sf.net/p/quakespasm/code/trunk/quakespasm@1298 af15c1b1-3010-417e-b628-4374ebc0bcbd
R_Clear only clears the warpimage part of the screen, leading to an unplayable
HOM effect on the rest of the screen.
The workaround is calling GL_SetCanvas(CANVAS_DEFAULT); at the end of
R_UpdateWarpTextures, it should be harmless enough on other systems, so not sure
if it's worth making this workaround conditional.
My guess is glClear in this implementation is wrongly using glViewport as the
area to clear.
git-svn-id: svn://svn.code.sf.net/p/quakespasm/code/trunk/quakespasm@1291 af15c1b1-3010-417e-b628-4374ebc0bcbd
It may be a useful alternative to the existing gamma control for laptops in a bright environment, etc.
(raising contrast gives less of a gray/washed out look than raising gamma, but as a disadvantage, colours near white get clipped to white.)
It's also implemented for both GLSL and SDL gamma ramps, but only if USE_GAMMA_RAMPS is set to 1.
Since USE_GAMMA_RAMPS is 0, currently it only works with GLSL.
git-svn-id: svn://svn.code.sf.net/p/quakespasm/code/trunk/quakespasm@1290 af15c1b1-3010-417e-b628-4374ebc0bcbd
on oms3.bsp on SSE builds.
Thanks to ParuBaru for reporting the issue.
git-svn-id: svn://svn.code.sf.net/p/quakespasm/code/trunk/quakespasm@1289 af15c1b1-3010-417e-b628-4374ebc0bcbd
"The buffers should always be cleared. On much older hardware, there was a technique to get away without clearing the scene, but on even semi-recent hardware, this will actually make things slower. So always do the clear."
Plus it's nice for map development / debugging.
git-svn-id: svn://svn.code.sf.net/p/quakespasm/code/trunk/quakespasm@1287 af15c1b1-3010-417e-b628-4374ebc0bcbd
Previously we were Hunk_Alloc'ing space for 8192 edicts (by default) which zeros all of that memory, this way we only use as much RAM as needed since the unuesd pages aren't dirtied
git-svn-id: svn://svn.code.sf.net/p/quakespasm/code/trunk/quakespasm@1286 af15c1b1-3010-417e-b628-4374ebc0bcbd
Taken from RMQEngine. the idea is to ensure every -condebug log has the gfx driver version logged.
git-svn-id: svn://svn.code.sf.net/p/quakespasm/code/trunk/quakespasm@1284 af15c1b1-3010-417e-b628-4374ebc0bcbd
Some measurements on the size of the sv.edicts hunk allocation, with this change, on various mods (it depends on the number of QC entity fields):
id1 7MB, quoth 11 MB, arcadim 21 MB, rrp 9MB, ne_ruins 16MB.
Since this is a Hunk_Alloc, the whole 10-20MB is cleared to zero which will allocate that much physical ram.
We could probably change it to a malloc later, and not clear the memory, so physical ram is only allocated when the memory is cleared in ED_Alloc.
git-svn-id: svn://svn.code.sf.net/p/quakespasm/code/trunk/quakespasm@1278 af15c1b1-3010-417e-b628-4374ebc0bcbd
N.B.: I verified with the OS X Instruments tool that unused space in the heap isn't dirtied (e.g. we never memset the entire heap, only the portions returned by Hunk_Alloc) so this should have no impact on RAM required.
git-svn-id: svn://svn.code.sf.net/p/quakespasm/code/trunk/quakespasm@1276 af15c1b1-3010-417e-b628-4374ebc0bcbd
after vid_restart TexMgr_ReloadImage reloads textures to tx->source_width/source_height, which might not match oldsize.
fixes: https://sourceforge.net/p/quakespasm/bugs/13/
steps to reproduce (fixed) bug:
-launch at 640x480, windowed, and with "r_oldwater 0"
-do "map start"
-change to 1024x768 windowed
-change to 1920x1080 windowed
-this last mode change makes liquid textures turn into random garbage.
git-svn-id: svn://svn.code.sf.net/p/quakespasm/code/trunk/quakespasm@1274 af15c1b1-3010-417e-b628-4374ebc0bcbd
(640x480 fullscreen -> windowed would give a large 1280x768 window mostly filled with garbage).
Previously, we were only using the fast path on old systems (no VBO support) anyway.
git-svn-id: svn://svn.code.sf.net/p/quakespasm/code/trunk/quakespasm@1272 af15c1b1-3010-417e-b628-4374ebc0bcbd
Uses only 36k extra of hunk memory, less for 32-bit builds, so shouldn't have any negative effects.
git-svn-id: svn://svn.code.sf.net/p/quakespasm/code/trunk/quakespasm@1266 af15c1b1-3010-417e-b628-4374ebc0bcbd
Fixes a obscure bug where:
- a bsp with no textures (pink checkerboard displayed)
- gamma != 1
- nothing else on screen (sbar hidden, r_drawviewmodel 0)
would result in the screen turning to noise.
git-svn-id: svn://svn.code.sf.net/p/quakespasm/code/trunk/quakespasm@1263 af15c1b1-3010-417e-b628-4374ebc0bcbd
Fixes bug where the fog mode was resetting to the default (GL_EXP) after a mode switch, causing fog to look different. This was only affecting SDL1 for me.
git-svn-id: svn://svn.code.sf.net/p/quakespasm/code/trunk/quakespasm@1259 af15c1b1-3010-417e-b628-4374ebc0bcbd
With "r_oldwater 0" and "scr_sbaralpha 0", warp textures wouldn't be rendered and instead you would see a copy of the screen tiled where water surfaces should be.
Thanks to graham for reporting.
git-svn-id: svn://svn.code.sf.net/p/quakespasm/code/trunk/quakespasm@1256 af15c1b1-3010-417e-b628-4374ebc0bcbd
This only affects the case when the developer cvar is set, we already ignore NaN's here.
negke reports getting the nan error with this debug progs.dat: http://negke.fov120.com/files/progsbjp.zip (rename to pak0.pak + install as a mod)
and his sm133_neg!ke.bsp: https://www.quaddicted.com/reviews/sm133_pack.html (walk over the zombie to activate a lightning trap)
git-svn-id: svn://svn.code.sf.net/p/quakespasm/code/trunk/quakespasm@1255 af15c1b1-3010-417e-b628-4374ebc0bcbd
Initially I thought that we would never need to draw an alias model that hadn't been precached when R_NewMap runs, but this assumption turned out to be incorrect. This fixes the issue where progs/bolt.mdl wasn't rendering in the Scourge Done Slick demos.
git-svn-id: svn://svn.code.sf.net/p/quakespasm/code/trunk/quakespasm@1253 af15c1b1-3010-417e-b628-4374ebc0bcbd
This matches the order used in the SDL2 sample applications included with the library.
Seems to fix an issue on Windows 10 with DPI scaling 150%, launching QS 0.90.1 with "-width 1920 -height 1080 -fullscreen", and you get a horrible black flicker every few frames.
see http://celephais.net/board/view_thread.php?id=60452&start=1587
git-svn-id: svn://svn.code.sf.net/p/quakespasm/code/trunk/quakespasm@1249 af15c1b1-3010-417e-b628-4374ebc0bcbd
This removes the Cache_Flush() call that was here, which was there to fix the jam3_tronyn / low heapsize bug, and instead adds a different workaround for that issue.
git-svn-id: svn://svn.code.sf.net/p/quakespasm/code/trunk/quakespasm@1247 af15c1b1-3010-417e-b628-4374ebc0bcbd
new worldspawn keys: _wateralpha, _lavaalpha, _slimealpha, _telealpha, _skyfog (unique to Quakespasm)
The lava/slime/telealpha cvars are non-archived, and default to 0, which means to use the value of r_wateralpha, so they have no effect by default.
The worldspawn keys allow custom maps to set these values in a way that only applies while the map is loaded, and doesn't change the cvar value. (similar to the behaviour of the "fog" worldspawn key.) They are accepted with or without the underscore, like "fog".
see also:
http://forums.insideqc.com/viewtopic.php?f=3&t=5532http://celephais.net/board/view_thread.php?id=60452&start=937
git-svn-id: svn://svn.code.sf.net/p/quakespasm/code/trunk/quakespasm@1238 af15c1b1-3010-417e-b628-4374ebc0bcbd
"flush" command is used by modders to view modified mdl files. need to call GLMesh_LoadVertexBuffers to keep that use case working with GLSL renderer.
git-svn-id: svn://svn.code.sf.net/p/quakespasm/code/trunk/quakespasm@1233 af15c1b1-3010-417e-b628-4374ebc0bcbd
This would only hapen on OS X or Linux (perhaps just luck or windows is more leniant about reading ~40 bytes past the end of a malloc). Note this will only handle cases where the lump size is recorded as being too small, we will still crash if the bsp file itself is truncated since there are generally no checks against the whole .bsp file buffer size.
FYI, the corruption in jam2_tronyn.bsp was caused by a bug in tyrutils which is fixed now: http://disenchant.net/git/?p=tyrutils&a=commit&h=5111c5485c96918b937843715f9b8f51f263e40e
Not sure about kellbase1.bsp (quoth).
git-svn-id: svn://svn.code.sf.net/p/quakespasm/code/trunk/quakespasm@1228 af15c1b1-3010-417e-b628-4374ebc0bcbd
The logic to prevent pausing the demo loop was preventing pausing in some valid cases, and there's no special reason not to allow pausing a demo loop.
git-svn-id: svn://svn.code.sf.net/p/quakespasm/code/trunk/quakespasm@1218 af15c1b1-3010-417e-b628-4374ebc0bcbd
- .ent, .lit not found in COM_FindFile (they will usually be missing, we print a message with "develoepr 1" when they are found)
- "trying to load" .ent file
- "bad chunk length"
git-svn-id: svn://svn.code.sf.net/p/quakespasm/code/trunk/quakespasm@1214 af15c1b1-3010-417e-b628-4374ebc0bcbd
Have heard these are confusing players and mappers/modders; people assume there is an error or a limit in QS is exceeded, but the messages are only about exceeding the limits in vanilla WinQuake/GLQuake.
git-svn-id: svn://svn.code.sf.net/p/quakespasm/code/trunk/quakespasm@1211 af15c1b1-3010-417e-b628-4374ebc0bcbd
Now an 8-bit stencil buffer is requested when using a 24-bit depth buffer (the default).
git-svn-id: svn://svn.code.sf.net/p/quakespasm/code/trunk/quakespasm@1209 af15c1b1-3010-417e-b628-4374ebc0bcbd
cl.stats[STAT_WEAPON] was being used before the high 8 bits were filled in, which is done with the SU_WEAPON2 byte.
Moved the block which clears the viewmodel lerp state to be after handling SU_WEAPON2.
git-svn-id: svn://svn.code.sf.net/p/quakespasm/code/trunk/quakespasm@1208 af15c1b1-3010-417e-b628-4374ebc0bcbd
e.g. fixes light_flame_small_yellow entity (progs/flame2.mdl) with alpha 0.5 showing up as solid (most of the pixels on flame2.mdl are fullbright)
git-svn-id: svn://svn.code.sf.net/p/quakespasm/code/trunk/quakespasm@1207 af15c1b1-3010-417e-b628-4374ebc0bcbd
mh suggest that not doing this may cause performance
issues: http://forums.inside3d.com/viewtopic.php?t=2408
It's also mentioned in a "Depth In-Depth" document from AMD.
git-svn-id: svn://svn.code.sf.net/p/quakespasm/code/trunk/quakespasm@1203 af15c1b1-3010-417e-b628-4374ebc0bcbd
This fixes a weird bug on Windows/AMD, where under some conditions, the
world would be drawn totally corrupted. Conditions for the bug were:
- gl_clear 0
- gamma 1
- glsl alias code in use
- status bar hidden, or, scr_sbaralpha 1
- map e1m1, look around the start position
git-svn-id: svn://svn.code.sf.net/p/quakespasm/code/trunk/quakespasm@1202 af15c1b1-3010-417e-b628-4374ebc0bcbd
Works around buffer underruns with directsound and SDL2, but also will
make Sleep()/SDL_Dleay() accurate to 1ms which should help framerate
stability.
git-svn-id: svn://svn.code.sf.net/p/quakespasm/code/trunk/quakespasm@1200 af15c1b1-3010-417e-b628-4374ebc0bcbd
keep the cross-build stuff only in the scripts. update the explanations in
windows and darwin makefiles.
git-svn-id: svn://svn.code.sf.net/p/quakespasm/code/trunk/quakespasm@1183 af15c1b1-3010-417e-b628-4374ebc0bcbd
treat '-F dir' the same as '-Fdir' and fails, so directly use -Fdir as
LDFLAGS, instead of -Wl,-F,dir .
git-svn-id: svn://svn.code.sf.net/p/quakespasm/code/trunk/quakespasm@1182 af15c1b1-3010-417e-b628-4374ebc0bcbd
Fixes a bug where if you do "map e1m6" then "kill", the fullbright part of the key texture is missing (drawn in black) - this bug was introduced in 0.90.0.
git-svn-id: svn://svn.code.sf.net/p/quakespasm/code/trunk/quakespasm@1168 af15c1b1-3010-417e-b628-4374ebc0bcbd
When cvar vid_desktopfullscreen is set to 1, fullscreen mode ignores vid_width/vid_height and uses the desktop resolution. SDL docs recommend using this, it's supposed to offer better OS integration.
git-svn-id: svn://svn.code.sf.net/p/quakespasm/code/trunk/quakespasm@1164 af15c1b1-3010-417e-b628-4374ebc0bcbd
Prior to r1153 it was 32 for maps and MAX_OSPATH for mods.
git-svn-id: svn://svn.code.sf.net/p/quakespasm/code/trunk/quakespasm@1158 af15c1b1-3010-417e-b628-4374ebc0bcbd
Avoids general bugginess of hardware gamma, doesn't affect the whole screen in windowed mode like HW gamma. Should fix http://sourceforge.net/p/quakespasm/bugs/5/
git-svn-id: svn://svn.code.sf.net/p/quakespasm/code/trunk/quakespasm@1157 af15c1b1-3010-417e-b628-4374ebc0bcbd
TODO: currently using a char[MAX_OSPATH] buffer to store map/mod names in the completion list which is probably unnecessairly large
git-svn-id: svn://svn.code.sf.net/p/quakespasm/code/trunk/quakespasm@1153 af15c1b1-3010-417e-b628-4374ebc0bcbd
Copied from the "map" autocompletion code, now I should probably refactor because most of the code could be shared.
git-svn-id: svn://svn.code.sf.net/p/quakespasm/code/trunk/quakespasm@1152 af15c1b1-3010-417e-b628-4374ebc0bcbd
In GL_MakeAliasModelDisplayLists, after saving the standerd triangle strips and fans onto the hunk, if the system is GL2 capable, we also save a second version of the mdl on the hunk designed to be loaded into a VBO (GL_MakeAliasModelDisplayLists_VBO). In R_NewMap, and on video mode changes, we call GLMesh_LoadVertexBuffers which loops over all precached mdl's and loads the data into a pair of VBO's (vertices and vertex indices).
Finally, in R_DrawAliasModel, assuming no rendering options are disabling the fast-path (r_drawflat 1, r_lightmap 1, or r_fullbright 1 would disable it), we call GL_DrawAliasFrame_GLSL, which sets up all of the bindings and draws the (possibly lerped) mdl in one glDrawElements call.
Special thanks to MH for some of the code from RMQEngine and the general concept.
git-svn-id: svn://svn.code.sf.net/p/quakespasm/code/trunk/quakespasm@1151 af15c1b1-3010-417e-b628-4374ebc0bcbd
Reasoning is, we default to the higher-quality settings for everything else except this.
git-svn-id: svn://svn.code.sf.net/p/quakespasm/code/trunk/quakespasm@1150 af15c1b1-3010-417e-b628-4374ebc0bcbd
This is done by adding an extra 'demopaused' flag to client_static_t, separate from cl.paused because we don't want a svc_setpause inside the demo (caused by the player pausing during recording) to actually pause demo playback. The only potential failure case is, if the demo contains a svc_stufftext of the command "pause", the demo will pause itself when being played.
git-svn-id: svn://svn.code.sf.net/p/quakespasm/code/trunk/quakespasm@1147 af15c1b1-3010-417e-b628-4374ebc0bcbd
Fixes a bug where if you launched QS and immediately did "playdemo [something]", after the demo finished, demo1.dem would start to play instead of returning to the console.
git-svn-id: svn://svn.code.sf.net/p/quakespasm/code/trunk/quakespasm@1146 af15c1b1-3010-417e-b628-4374ebc0bcbd
This fixes a bug seen in jam3_tronyn.bsp (which only has a density value in the worldspawn), where the fog color of the last map played would carry over.
git-svn-id: svn://svn.code.sf.net/p/quakespasm/code/trunk/quakespasm@1140 af15c1b1-3010-417e-b628-4374ebc0bcbd
This moves some of the OpenGL implementation to a background thread, and makes draw calls block for a shorter amount of time. AFAIK, this is the default mode on most other OS'es, not sure why you have to explicitly ask for it on OS X.
N.B. the kCGLCEMPEngine constant is available on 10.4+ so I don't bother checking the OS X version.
More info: https://developer.apple.com/library/mac/technotes/tn2085/_index.html
git-svn-id: svn://svn.code.sf.net/p/quakespasm/code/trunk/quakespasm@1137 af15c1b1-3010-417e-b628-4374ebc0bcbd
This fixes:
e2m3:
- The wallpiece that blocks the way out of the Well of Wishes (when open).
git-svn-id: svn://svn.code.sf.net/p/quakespasm/code/trunk/quakespasm@1136 af15c1b1-3010-417e-b628-4374ebc0bcbd
This fixes:
e2m3:
- The floorpiece (when down) and wallpiece (when open) by the crates opposite the normal exit.
git-svn-id: svn://svn.code.sf.net/p/quakespasm/code/trunk/quakespasm@1135 af15c1b1-3010-417e-b628-4374ebc0bcbd
This fixes:
e1m4:
- The secret doors in the room with the five quake-logo buttons on the floor (when open).
e2m2:
- The platform in the water behind the gold key door (when down).
- The wallpiece that pushes the player into the gold key room (when "closed").
git-svn-id: svn://svn.code.sf.net/p/quakespasm/code/trunk/quakespasm@1134 af15c1b1-3010-417e-b628-4374ebc0bcbd
It was possible, but unlikely, to see artifacts from the previous code in some circumstances, e.g. "host_maxfps 10" and spin around quickly near a flashing light e1m1, you may see a surface drawn with an out-of-date lightmap for one frame.
git-svn-id: svn://svn.code.sf.net/p/quakespasm/code/trunk/quakespasm@1130 af15c1b1-3010-417e-b628-4374ebc0bcbd
This is consistent with toggling the in-game console off, and fixes stray '`' or '~' (or '^' or '\' or ..., depending on the keyboard layout) characters.
git-svn-id: svn://svn.code.sf.net/p/quakespasm/code/trunk/quakespasm@1116 af15c1b1-3010-417e-b628-4374ebc0bcbd
1. Remove Key_IgnoreTextInput(), and simple always send a Char_Event when
we receive TEXTINPUT (SDL2) or the unicode field of a KEYDOWN event is
filled (SDL1.).
2. Remove handling of K_KP_* in the menu/console, since they cannot be
relied on to not also send text (see issue described above). The handling
of K_KP_ENTER can stay, since we do know that it never sends text.
3. Remove the interpretation hack for the numpad, since it will no longer
be needed (and doesn't currently work for SDL2 anyway); if a numpad key
generates text we will handle it (because of "1"), if not then it will
simply be if ignored (because of "2”).
git-svn-id: svn://svn.code.sf.net/p/quakespasm/code/trunk/quakespasm@1110 af15c1b1-3010-417e-b628-4374ebc0bcbd
was no longer needed and was causing issues typing underscores (US keyboard layout) on Linux/SDL2 where SDL_TEXTINPUT is delivered before the SDL_KEYDOWN.
git-svn-id: svn://svn.code.sf.net/p/quakespasm/code/trunk/quakespasm@1109 af15c1b1-3010-417e-b628-4374ebc0bcbd
* in_sdl.c: Remove the over-zealous "no events for unknown keys" checks introduced in r1085. Events for unknown keys can be useful for "press any key" situations.
* keys.c: In input grab mode, update the "lastkey" member only for key down events.
* keys.c/console.c: Adapt input grab mode to properly support catching "any key" presses.
git-svn-id: svn://svn.code.sf.net/p/quakespasm/code/trunk/quakespasm@1089 af15c1b1-3010-417e-b628-4374ebc0bcbd
On my old laptop, when running "./quakespasm -fsaa 2", quakespasm would error out with a "Couldn't create window" message. Our "no FSAA available" fallback was applied at OpenGL context creation time, but according to the SDL2 wiki FSAA settings should be done before creation of the window (see https://wiki.libsdl.org/SDL_GLattr#multisample). Moved it there.
git-svn-id: svn://svn.code.sf.net/p/quakespasm/code/trunk/quakespasm@1084 af15c1b1-3010-417e-b628-4374ebc0bcbd
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
interpret -missionpack and [-]game missionpack as the same as a new
QuakeSpasm extension. besides, do not let loading of the mission pack
directory twice.
git-svn-id: svn://svn.code.sf.net/p/quakespasm/code/trunk/quakespasm@1011 af15c1b1-3010-417e-b628-4374ebc0bcbd
* make 'game' command to strip all mission pack support
* make 'game' command to accept an optional second mission pack argument,
i.e. -hipnotic, -rogue or -quoth.
* so the new behavior does:
game id1 --> really returns to bare id1 game, doesn't accept any mission pack arguments
game xxx -hipnotic --> strip down to id1 game, load hipnotic and load xxx on top of them
game xxx --> strip down to id1 game and load xxx on top of it
* additionally, some extravaganza:
game xxx --> if the game is already xxx, but the engine was started with -hiptonic
or -rogue or -quoth, strip down to id1 and reload xxx on top of bare id1
game xxx -hipnotic --> if the game is already xxx, but the engine was started without
-hiptonic, strip down to id1, load hipnotic and reload xxx on top of them
git-svn-id: svn://svn.code.sf.net/p/quakespasm/code/trunk/quakespasm@1010 af15c1b1-3010-417e-b628-4374ebc0bcbd
Also surround the SDL version by "#if defined(USE_SDL2)" and "#endif", this
suppresses an unused function warning when building for SDL1. (Building for
SDL2 still gives an unused variable "modstate" warning though.)
git-svn-id: svn://svn.code.sf.net/p/quakespasm/code/trunk/quakespasm@1002 af15c1b1-3010-417e-b628-4374ebc0bcbd
Not totally sure about this but i think it's a decent idea. I'm using 800x600 as a reference screen size (arbitrary choice but it's the default QS resolution). So if your resolution is 600 pixels tall this will make no difference. On higher resolutions this will make the console a bit faster than before.
git-svn-id: svn://svn.code.sf.net/p/quakespasm/code/trunk/quakespasm@992 af15c1b1-3010-417e-b628-4374ebc0bcbd
PF_VarString is only called on the server, in:
- PF_error, PF_objerror, PF_dprint to print error / debugging messages
- PF_bprint, which calls SV_BroadcastPrintf which copies the string into a 1024-byte buffer, then sends that to clients in a svc_print message
- PF_sprint, which sends the string in a svc_print message using MSG_WriteString (without copying into an intermediate buffer)
- PF_centerprint, which sends the return value of PF_VarString in a svc_centerprint message (without copying into an intermediate buffer)
On the client:
- svc_print reads the payload string with MSG_ReadString (2048-byte buffer), then Con_Printf is called (4096-byte buffer)
- svc_centerprint uses MSG_ReadString then calls SCR_CenterPrint (1024-byte buffer)
I also checked the original quake source and the client-side buffers for MSG_ReadString, Con_Printf, and SCR_CenterPrint are all the same sizes as in QS.
Admittedly I want to support sock's ITS mod, but as far as I can see, it's a totally safe to increase this to 1024.
git-svn-id: svn://svn.code.sf.net/p/quakespasm/code/trunk/quakespasm@985 af15c1b1-3010-417e-b628-4374ebc0bcbd
It caused a dramatic slowdown on my machine on windows (50% slower)
git-svn-id: svn://svn.code.sf.net/p/quakespasm/code/trunk/quakespasm@983 af15c1b1-3010-417e-b628-4374ebc0bcbd
The glBegin(GL_POLYGON), for() loop with GL_MTexCoord2fFunc()/glVertex3fv() calls, and glEnd () per polygon is replaced by a memcpy() and a glDrawArrays() call per poly.
My guess is this only saves function call overhead, but it gives a decent ~20% speedup (36 -> 42fps) on my machine on orl’s map.
Note: glDrawArrays() is in OpenGL 1.1, but the glClientActiveTextureARB function is part of the GL_ARB_multitexture extension but not GL_SGIS_multitexture. Instead of splitting into two code paths, I just dropped support for GL_SGIS_multitexture.
git-svn-id: svn://svn.code.sf.net/p/quakespasm/code/trunk/quakespasm@981 af15c1b1-3010-417e-b628-4374ebc0bcbd
To make this work with the drawing order we use in gl_rmain (world excluding water, opaque ents, world water, transparent ents), I made each texture_t have two texture chains, one for world and one for bmodels. This way they can be cleared during entity drawing without having to regenerate the world ones.
Other than this the changes are mostly minor adjustments to the R_DrawTextureChains_* functions so they can work for things other than the world.
git-svn-id: svn://svn.code.sf.net/p/quakespasm/code/trunk/quakespasm@979 af15c1b1-3010-417e-b628-4374ebc0bcbd
With that alone, the console would come down and slide up when the map changes in a demo.
I added a SCR_BeginLoadingPlaque() call in CL_ParseServerInfo, only done during demo playback, which shows the loading plaque and prevents the console from appearing and sliding up.
git-svn-id: svn://svn.code.sf.net/p/quakespasm/code/trunk/quakespasm@976 af15c1b1-3010-417e-b628-4374ebc0bcbd
for a test case, play a demo from: http://www.quaketastic.com/upload/files/demos/otp_honey100.zip
for the honey map pack: http://www.quaketastic.com/upload/files/single_player/maps/honey.zip
on a slow pc that gets signifigantly less than 72fps, or with host_maxfps lowered (e.g. set to 33).
with QS 0.85.9, the demo will play in slow-motion; with QS 0.85.6 (without the cross-map demo support) it plays normally.
admittedly this is a fringe scenario, but it's imo a legitimate bug in the Pa3PyX cross-map demo playback code.
git-svn-id: svn://svn.code.sf.net/p/quakespasm/code/trunk/quakespasm@974 af15c1b1-3010-417e-b628-4374ebc0bcbd
Ozkan Sezer
Eric Wasylishen
Steven
Sander van Dijk