When Q2 runs in windowed mode, SDL can never switch to the wrong the
resolution. The resolution isn't switched, of course. The work around
prevented Q2 from creating Windows larger than the resolution of the
primary display. For example a primary display of 1280x1024 prevented
a window size of 1680x1050 on the much bigger secondary display.
Normally stdout and stderr are buffered. In case of a crash the last
lines aren't written to the stdout.txt, making post mortem debugging
difficult. Forcing both FDs to unbuffered mode ensures that everything
gets written. The performance impact is negliable.
Even tough it is a multi user os, due to BeOs heritage and being backwards
compatible with, the desktop runs as root, thus its dog get eaten after all...
Combs all Raw search paths to find game dirs containing PAK/PK2/PK3
files. If multiple uniquely-named directories exist, then show a "mods"
option on the "Game" menu and allow selection of desired mod on new
eponymous submenu. Includes fix for memory leak of mapnames (read from
"maps.lst") when changing games.
When the "game" directory is changed, clear the current list of maps in
the "start network server" menu so that it will be re-initialized the
next time the menu is accessed.
so it waits for about the time of one frame at 60fps, but independently
of the actual framerate.
Without this fix, wait is broken unless vsync is on, because
CBuf_Execute() is called about 1000 times per second by Qcommon_Frame(),
even if no render- or packet-frame is executed.
(vsync "fixes" this because then we have a real wait at the end of each
renderframe)
We busy-looped for 5000 microseconds, i.e. 5 milliseconds, which reduces
the framerate to < 200fps
I guess the value was copypasted from Sys_Nanosleep() below, but
that was nanoseconds of course..
Anyway, busy-looping for 5 *micro*seconds instead fixes it.
Angle kicks are used for weapon recoil, damage kicks and the like.
Setting the `cl_anglekicks` to `0` ignored them, they're read from
the network but not displayed. The cvar is cheat protected, it's
reset to `1` on server connect.
Rquested by Martin via mail.
In coop it's often hard to get on the same elevator together, because
they're immediately triggered once the first player steps on it.
This cvar sets a delay (1 second by default) for the elevator to wait
before moving, so other players have some time to get on it.
If you like elevators/platforms that suck, just set it to `0` :-P
Currently only used in func_plat, if it turns out that other entities
are used for automatically triggered platforms, we'll have to adapt
those as well (I guess wait_and_change() is generally useful for that).
We're not bumping the savegame version because they should only break in
an uncommon corner case: *Coop* savegames created with clients including
this change will not work on older clients - SP savegames are not
affected and old savegames on new clients also still work.
In coop a weapon can be picked up only once. That's annoying, because in
coop ammunition is sparse and not getting the ammunition that comes with
a weapons make things worse. When `coop_pickup_weapons` is set to `1` a
weapon may be picked up if:
1) The player doesn't have the weapon in their inventory.
2) No other player has already picked it up.
This is one these constructs which makes you wonder how it could ever
work. When querying a cvar by calling Cvar_Get(), the default value
(given in `var_value`) is copied into `cvar_t->default_string`. If a
NULL pointer is given in `var_value`, the NULL pointer is passed to
CopyString() and dereferenced. The game crashes. There's already a NULL
pointer check in the 'cvar wasn't found' branch, but none in the 'cvar
was found' branch... Moving the check to the beginning of the function
isn't an option, because at least lithium2 doesn't implement a NULL
pointer check either. We would just move the crash from the server into
the game.dll. Therefore copy an empty string into
cvar_t->default_string` when a NULL pointer was passed in `cvar_value`
and the cvar was found. Pass the empty string trough `CopyString()` to
get an Z_MAlloc() allocation for it, otherwise we would call `Z_Free()`
on an unallocated object further down below.
Reported by Chris Stewart.
ogg_enabled doesn't prevent music from playing, it just toggles if the
ogg backend should be enabled or not. If the user does something like
`ogg_enable=0; snd_restart` everything is okay. If they just set
`ogg_enable=0` strange things happen because the backend stays
initialized and will play tracks as requested. Work around the by
shutting the backend down if `ogg_enable == 0 && ogg_started == true`.
Closes#583.
This allows really bug configuration files up to 32k. It would be better
to switch the global buffer to something allocated at runtime, but thats
non-trivial... This change should be save, since the buffers are global
(allocated in the BSS) and not included in savegames nor send over the
network.
Closes#582.
It's an often reported, that the q2ded dedicated server consumes huges
amounts of CPU time. That's because users don't know that `busywait`
must be set to `0`. Since there's no point in using busywaits in the
dedicated server (the network jitter is always bigger than the
jitter caused by nanosleep() and equivalents), just force q2ded to
use nanosleep().
Some projectiles like grenades or rockets are classified as enemies.
Their explosion spawn a sound entity, monsters should move to that. But
the projectile is destroyed when exploding, it's entity struct is set to
NULL. Therefor the self->enemy pointer is also NULL. The self->enemy
check was removed in bc5f5698. Work around this by pretending that the
enemy is already there.
This was reported by @Soldy, closesyquake2/xatrix#56.
This is a special case, the bug was already present in Vanilla Q2: If a
server is offering assets for download but is missing some files the
USP download code runs in an endless loop. CL_ParseDownload() detects
that something is wrong and calls CL_RequestNextDownload() which tries
to download the same file again... Work around this by skippig over that
file.
This closes#552.
The new ordering was introduced in 16ee007, fixing some problems with
the wrong sound getting played when an entity triggers several sound at
the same timestamp. This broke the behavior of the mods, in #558 dday
was mentioned, muzzle flashe sound prevent the firing sound from getting
played.
Since we don't control the source of all mods, add a simple band aid
fix: Use the new ordering for baseq2, xatrix and rouge. Use the old
ordering for everything else.
An alternative approach is being discussed in #564.
I don't remember why we restricted it to client startup. The original
code executed it everytime when `game` changed... Revert to that
behavior. Look here if some problems come up. ;)
Closes#544.
Adaptive vsync is a often requested feauture and easy to implement. Set
`r_vsync` to `2` to enable. This is untested because my system doesn't
support it.
There already was one (that I only recently fixed) for semicolon, but
the same problem can happen with quotes or $ (which is used in macros)
(single-quote ' is probably not affected, added it just to be sure)
regardless of keyboard layout, with a special exemption for layouts
where that key generates a quote character (like the Brazilian one)
because you may wanna type a quote into the console.
(It's SDL_SCANCODE_GRAVE, that key between Esc, 1 and Tab)
The old hack of matching for ^, ~ and ` in Char_Event() didn't work very
well for layouts we didn't anticipate, which is especially relevant with
the recent Scancode fallback, which for example allows binding the ^ key
on Belgian keyboards (which is on SDL_SCANCODE_LEFTBRACKET, far away
from the "console key"), but in that case would *also* open the console.
This is mostly straight-forward, except for a small hack to prevent the
key from generating text input (on German layouts you otherwise get
"^" in the console when closing+opening it), which requires the
"console key" to be pressed without any modifiers like Shift or AltGr.
Yes, it's ugly, but it works and all the uglyness is contained in
IN_Update() and on the other hand Char_Event() becomes less ugly :)
If we can't map a SDL_KEYDOWN/KEYUP events SDL_Keycode to a known
Quake2 K_* keycode, we try to map the SDL_Scancode to one of the new
K_SC_* YQ2 scancodes instead.
The scancode name corresponds to the key at that position on US-QWERTY
keyboards *not* the one in the local layout, for example the German 'Ö'
key is K_SC_SEMICOLON.
This way (hopefully!) all keys on common keyboards can be bound,
regardless of their layout. The key name won't be immediately obvious
to the user, but it's only a fallback and better than nothing.
fixes#543
this way it's easier to tell if a key constant is not handled.
Also, there was a half-finished workaround to allow binding a ';' key
(which apparently in configs would otherwise be interpreted as
command separator), now that should actually work (=> special case
it in Key_KeynumToString())
This is an enhancement to the previous `yield` work:
* Don't enforce `-march=armv8-a` for aarch64 builds, because it is the
initial ARMv8 revision and compilers will either use that or something
newer.
* Refine preprocessor guards around `asm("yield");` so the code isn't
compiled in if unsupported by the current `-march='.
Submitted by @smcv in #535.
On MacOS texture is cleaned up after render and code have to copy a whole
screen to texture, other platforms save previous texture content and can
be copied only changed parts.
YQ2 has a much more precise Sys_Milliseconds() than Vanilla Quake II and
it always start at 0, not some other semirandom value. If the client is
started by `./quake2 +connect example.com" or all user just walk their
way to the menu there's a very high propability that two ore more
clients end up with the same qport... We can't use rand(), because we're
always starting with the same seed, so all clients generate more or less
the same random numbers and we end up in the same situation.
So just call time(). It's portable and more or less in line what the
original code did for Windows. It may be necessary to implement some
kind of fallback logic just in case that still two clients end up with
the same qport, but that's a task for another day.
Closes#537.
This was introduced in 220f0a9 as fix. The submitter, @DanielGibson and
myself missunderstood the code:
* If net_interface is NULL (which in the current code can never happen),
an empty string (the user sets the `ip` cvar to an empty string) or
"localhost" (the default) we want to set `Host` to the unspecified
address. getaddrinfo() will return in6addr_any fot it and we'll bind
to any available address.
* "0.0.0.0" isn't the IPv4 any address, it's the unspecified address.
Thats correct and the code was working fine for IPv4. But at least
the submitter and me confused it with the any address (which is
0.0.0.0/0). So setting `Host` in the IPv6 to `::/128` (the lowest IPv6
address) or `::/0` (any IPv6) is wrong, it must be `::` (unspecified
IPv6 address)!
Have a look at RFC 3493 for the details.
I'm doing the change only for the Unix code path, not for Windows. For
some reason everything besides `::/128` or `::1` doesn't really work on
Windows and I don't know why. Even more scary is that changes to the
IPv6 case also break IPv4 sockets. Since the whole network.c for Windows
is confuse and rather hard to understand (there's still IPX support in
it) I'm leaving things as they are.
C11 _Noreturn is only accepted on function declarations, not on function
pointers, so we can't use it on callbacks like game_import_t.error and
refimport_t.Sys_Error. Use a separate macro for those.
The problematic situation doesn't currently happen because the Makefile
hard-codes -std=gnu99, which disables C11 features; but removing
-std=gnu99 (resulting in the compiler's default, currently gnu11) causes
compilation failures with at least gcc 9.x.
Signed-off-by: Simon McVittie <smcv@debian.org>
Until now CFGDIR was hardcoded to YamagiQ2 on Windows and .yq2 on
everything else. Sometimes it's desireable to have a separate dir
for some tasks, for example whentesting things that introduce new
cvars. Add -cfgdir to override CFGDIR.
This allows for longer arguments passed to cvars, gl_nolerp_list is a
good example for a case were a token length of 128 is too short. Keep
the mapname[] buffer in the server struct at 128 bytes to preserve
savegame compatibility.
Closes#526.
In the vanilla code show_hostile was a qboolean what's clearly wrong.
For wome reasons I don't remember I changed it to an integer and added
the casts. This is problematic because show_hostile is derived from
level.time which is a float. The loss in precision broke some corner
cases like monsters becoming activated when they shouldn't.
Found, analyzed and reported by @BjossiAlfreds #525. Closes#525.
Until this commit a cinematic was aborted as soon as any key were
marked down when finishing the user command and sending it to the
server. The whole logic to detect if a key is down is broken, for
example `vid_restart` may leave keys marked down that are in fact
up. And there's the possibility to inject fake key events from
nearly everywhere. I'm not really sure but I suspect that even the
server may be able to inject key events.
Therefore untangle the cinematic abort code from the user command
processing, it should depend only on real key strokes:
1. Introduce a new global variable `abort_cinamatic` and set it to
`cls.realtime` as soon as a key down event is detected. The only
exceptions are Escape and Shift, because opening the menu and
toggeling the console should never abort a cinematic.
2. When starting a cinematic `abort_cinamatic` is set to INT_MAX,
because it needs to be higher than the current `cls.realtime`.
3. When a cinematic is running, `cls.key_dest` is set to `key_game`
(`key_menu` and `key_console` are ignored, keys send to the menu
or the console should never abort a cinematic; `key_message`
can / should never happen while a cinematic is running) and
`abort_cinamatic` is less than `cls.realtime` the cinematic is
aborted.
`abort_cinamatic` less than `cls.realtime` is necessary because the
client needs one frame to pop up the menu or toggle the console and set
the `cls.key_dest` accordingly. `abort_cinamatic == cls.realtime - 1`
is not possible because not every frame finishes a user command.
This closes#502.
An option like this was often requested since I fixed the gun field of
view in e466554. Since the software renderer is missing the ability to
alter the persepective matrix (e.g. something like glFrustrum()) this
fix fakes the offset by manipulating the guns transformation marix.
That's not perfect, the gun distorts if `sw_gunzposition` is set to
anything but `0`. Values up to `8` are more or less okay. Defaults
to `8` which matches the GL renderer default.
Pushing all entities slightly away from non-horizontal may let items to
slide to unreachable locations, or let monsters getting stuck.
This is part of yquake2/xatrix#50
In such case sound system left uninitialized and without cvars.
----
Thread 1 "quake2" received signal SIGSEGV, Segmentation fault.
0x00005555555956a1 in OGG_PlayTrack (trackNo=7) at src/client/sound/ogg.c:351
351 if((trackNo == 0) || ogg_shuffle->value)
(gdb) bt
#0 0x00005555555956a1 in OGG_PlayTrack (trackNo=7) at
src/client/sound/ogg.c:351
#1 0x000055555557bded in CL_PrepRefresh () at src/client/cl_view.c:367
#2 0x000055555556e1a0 in CL_Precache_f () at src/client/cl_main.c:472
#3 0x00005555555a40dc in Cbuf_Execute () at src/common/cmdparser.c:229
#4 0x000055555556f0f9 in CL_Frame (packetdelta=<optimized out>,
renderdelta=<optimized out>, timedelta=<optimized out>,
packetframe=packetframe@entry=true,
renderframe=renderframe@entry=false) at src/client/cl_main.c:803
#5 0x00005555555aa0c5 in Qcommon_Frame (usec=5) at src/common/frame.c:626
#6 0x00005555555aa48e in Qcommon_Mainloop () at src/common/frame.c:163
#7 0x00005555555aaae6 in Qcommon_Init (argc=1, argv=0x7fffffffdfa8)
at src/common/frame.c:377
#8 0x000055555555e564 in main (argc=1, argv=0x7fffffffdfa8) at
src/backends/unix/main.c:123
----
The Intel display driver for Windows 10 destroys the DisplayPort audio
device when the resolution changes. It's recreated at an unspecified
later time. This is a work around to recover from that:
* Check every frame if OpenAL is still connected.
* If not, wait for 2.5 seconds, after that inject a 'snd_restart'
into the command buffer.
Samples send to the OpenAL backend while disconnected are skipped.
This fixes#483.
It's been over two years since we merged it into the master. @0lvin has
done a wonderfull job in maintaining it, he fixed a lot of bugs, did a
fair amount of enhancement, etc. There weren't any bug reports for the
last 6 month, it looks like that it's more or less stable right now. So
don't scare the users by calling it experimental.
and make sure that after vid_restart (or starting the game) it's used
correctly in GL3.
While at it, made sure that it's *not* applied to textures from
gl_nolerp_list, because they're supposed to always use GL_NEAREST
independent of this setting (used so console font and crosshairs don't
look blurry)
On Windows last_position_x/y (from SDL_GetWindowPosition()) was 0, 0 when
coming from fullscreen, and creating a window at position (0, 0) cuts off
the window decorations (SDL-Bug?) so the window can't even be moved
around anymore.
So now we only use the last_position_* if last_position_y was > 24, so we
have enough of the title bar to move the window around with the mouse.
This is part of #484
The docs "forget" to mention that. So it's not enough to check for
SDL_WINDOW_FULLSCREEN alone, we would trigger the code intented for the
real fullscreen if we're switching to / running in fullscreen desktop
mode. Add and addition check that SDL_WINDOW_FULLSCREEN_DESKTOP isn't
set.
This may fix issue #484.
With this quicksaves can be loaded from the menu. They cannot be saved.
That's an artificial limitation to match the behavior of autosaves. I
think both should behave the same because their comment string are
formatted the same...
This is somewhat hacky. Until now the menu assumed that all savegames
are named from save0 to saveX, where save0 is the autosave slot. There
were 16 slots per page * 2 pages = 32 savegame slot, so the highest slot
was save31. I've reduced the slot per page to 14 to make room for one
quicksave slot and one empty line between it and the first regular slot.
That alone would reduce the number of slots to 28, making the four
highest slots unreachable. So I've increased the number of pages to 4,
there're now 14 slots per page * 4 pages = 56 slots.
The quicksave slot is shown on every page, because it was the easiest
way to integrate it into the existing code. Everything else would
require the paging logic to be rewritten in a way that different pages
can have a different number of slots and a different layout.
This is part of #473.
Demos are special. To the client they're more or less the same as normal
maps, the only difference is that the client never joines the server. So
we're never getting the first valid frame txpaht indicates the end of
the connection process. We're using that one to drop out of pause
mode... As a result the client stays in pause mode forever and "hangs".
Work around this by entering pause mode only if the local server is in
state ss_game. Demos are ss_demo. There're some more states for
cinematics, pictures, etc. Since the player can't save in those states
it should be save not check them.
sw_image.c:
203: The potential null pointer is passed into 'memcpy' function. Inspect the first argument. Check lines: 203, 192.
368: The null pointer is passed into 'free' function. Inspect the first argument.
401: Expression '!pic' is always false.
401: There are two 'if' statements with identical conditional expressions. The first 'if' statement contains function return. This means that the second 'if' statement is senseless. Check lines: 394, 401.
565: The potential null pointer is passed into 'memcpy' function. Inspect the first argument. Check lines: 565, 564.
sw_model.c:
215: The 'model' pointer was used unsafely after it was verified against nullptr. Check lines: 210, 215.
985: The 'header->lumps[12].filelen / sizeof (int)' expression was implicitly cast from 'size_t' type to 'float' type. Consider utilizing an explicit type cast to avoid the loss of a fractional part. An example: double A = (double)(X) / Y;.
1277: Function 'RE_BeginRegistration' argument 1 names different: declaration 'map' definition 'model'.
sw_surf.c:
239: There might be dereferencing of a potential null pointer 'sc_base'. Check lines: 239, 236.
sw_main.c:
1345: The if condition is the same as the previous if condition
1466: Function 'R_GammaCorrectAndSetPalette' argument 1 names different: declaration 'pal' definition 'palette'
2063: The 'swap_buffers' pointer in the expression could be nullptr. In such case, resulting value of arithmetic operations on this pointer will be senseless and it should not be used. Check lines: 2063, 2061.
sw_aclip.c:
180: Variable 'j' is reassigned a value before the old one has been used.
sw_alias.c:
209: Function 'R_AliasTransformVector' argument 3 names different: declaration 'm' definition 'xf'.
sw_draw.c:
78: Function 'RE_Draw_CharScaled' argument 3 names different: declaration 'c' definition 'num'.
149: Function 'RE_Draw_GetPicSize' argument 3 names different: declaration 'name' definition 'pic'.
173: The scope of the variable 'u' can be reduced.
267: Function 'RE_Draw_PicScaled' argument 4 names different: declaration 'factor' definition 'scale'.
sw_scan.c
593: Function 'D_DrawSpansPow2' argument 1 names different: declaration 'pspans' definition 'pspan'.
745: Function 'D_DrawZSpans' argument 1 names different: declaration 'pspans' definition 'pspan'.
Save current player position and compare with a position in the previous
frame, if position is same refresh only changed rectangle in zbuffer.
zBuffer can be damaged by models, particles and static transparent spans.
zBuffer damage is not useful for the screen refresh minimize for now,
as result of explosion can change texture light value.
Especially after savegame load not all slots in the edicts array may be
used. Check if the current entity has a classname string. This is
another part of #430.
It's unclear were this comes from, maybe it's a bug in the collision
detection. Because the collision detection is ununderstandable for
people without 'special brain type game programming' like me and even
bugfixes to it have a very high chance to break things, work around
it. Save current position, perform move, check if we're in the world
model. If we are revert to old position.
Debugged and work arounf suggested by @BjossiAlfreds. Fixes#443.
This is another code inconsistency, we must not clamp the current health
to the client max health (which apparently is always 100) but to the
current max health of the player entity.
Analyzed and fix suggest by @BjossiAlfreds, fixes#441.
This is another corner case. Parasites have a bbox height of 24,
walkmonster_start_go() hardcodes a viewheight of 25. Therefor most
traces in other functions like visible() overshoot the parasite.
Fix this by not overriding the monster viewheight.
Analyzed and fix suggested by @BjossiAlfreds. Closes issue #440.
This rather sophisticated command prints all entities of one or more
given classes and their coordinates. Possible classes are:
* ammo
* items
* keys
* monsters
* weapons
Classes can be combined into one command, e.g. `listentities ammo keys'
would print all ammunition and all keys. The special class `all` prints
all entities, regardless of their class.
The command is protected by `cheats 1`.
This is part of issue #430.
A command that teleports the player to abitrary locations was often
requested and may be helpfull for debugging, so finally add it. It works
like a normal teleporter: It moves the player to the requested location,
clears all movements, tells the server and clients that the entity just
teleported and telefrags everything that's in the target location.
The implementation does not verify if the requested location is save,
the player may teleport into the world model or even the void. But the
requested Z coordinate is elevated by 10 units to prevent the player
getting stuck in the floor.
The command is protected by sv_cheats.
This is part of issue #430.
The fallback logic is: r1q2 style URLs -> q2pro style URLs -> UDP. In
case that an r1q2 or q2pro server is missing files, we may fall through
to UDP and download files over abysmal slow UDP that are available over
HTTP. To work around this problem we reset the precacher iterations back
to 0 and start over with r1q2 style URLs. This works as long as we're
able to download all files. But if one or more files are unavailable
over all three download options we'll run into an endless loop. Mitigate
this by starting over only once. This comes with the drawback that on
servers that miss more than one file downloads might done over UDP were
HTTP is available. In that case the server should be fixed.
This closes#429.
This prevenits the worlds from advancing during client connect. The
player won't get attacked by monsters or hurt by the environment. Note
that in baseq2 there're still 4 world frames processed by the game and
100 world frames if the player enters a level that he or she already
visited. Both aren't a big problem, 4 world frames are hardly enough
for monsters starting to attack and in most levels the starting area
can't be reached by monsters and is free from environmental effects.
Pause mode is only entered for local servers and only in single player
mode. This should prevent problems with coop and deathmatch games.
The behaviour can be controlled by `cl_loadpaused`:
* `0`: Do not enter pause mode, Vanilla Quake I behaviour.
* `1`: Enter pause mode at load and leave it at first regular server
frame.
* `2`: Enter pause mode at load, never leave it. The player must leave
it by hand.
This was requested in issue #417.
cvar operations are special commands that allow the programmatic
manipulation of cvar values. 'reset' resets a given cvar to it's
default value, e.g. `reset r_mode' would reset `r_mode` to `4`.
'resetall' resets all known cvar with the exception of `game`.
The code is based upon q2pro.
This is part of issue #414.
44472722e added some sanity checks to the AI code. The checks in
ai_run() are likely wrong because the enemy entity might be already
NULL if we arrive their. By aborting early the code is unable to
determine a new enemy or return the monster to idle state, so the
monster will wait forever for an enemy that'll never come.
This happens only in monster vs. monster fights. Never in monster vs.
player, that game ends if the player dies.
In theory this change should be harmless, because if the enemy entity is
gone it won't generate sound targets now be visible. If the game crashes
by self->enemy being NULL we've got a problem elsewere.
This was reported by @BjossiAlfreds in #483. He also suggested the fix.
When searching for the player FinTarget() always goes after sound
targets and aborts as soon as it finds one. So if the player is
constantly generating sounds - for example firing the machine gun -
there's a high chance that monsters will only hear but never see
him. Work around this by adding a small timeout to player noises, make
sure that at least 3 frames passed since the last noise. This gives
monsters 2 frames to see the player.
This bug was present in the original code, this is a small gameplay
change.
The problem was analysed by @BjossiAlfreds in #436. He also suggested
the fix.
M_MoveFrame() calls first the AI functions that decide if a monster
should attack or not. After that the monsters think function is called
which walks through berserk_frames_stand[]. Even if the AI function found
an enemy and decided to attack, the monster is still standing for this
frame and berserker_fidget() is called. It may override the earlier
earlier decision, aborting the attack. Even worse this may let the
berserker stuck, because AI_STAND_GROUND may be cleared which prevents
further attacks.
This bug was present in the original code, so this is small gameplay
change. It's likely also present in both addons.
Reported and analyzed by @BjossiAlfreds in issue #433. He also suggested
the fix.
Like most other cvars 'sensitivity' allowes for float values. But until
now mouse events were handled as integers which led to some confusing
problems. This was especially noticeable at values lower than 1, small
mouse movements were cut to 0 and discarded. Since the clients movement
code is written in floats and we're already using floats for joystick
movement switch the mouse event handling over to them, too.
This should have any impact on configs were 'sensitivity' is ste to
integral values. If it was set to decimal values the behaviour is now
correct.
This fixes#419.
Check if we're in the requested mode after the fullscreen window was
created. If not: Try to switch again in the requested mode by calling
SDL_SetWindowDisplayMode(). If that's successfull set the new window
size with SDL_SetWindowSize(). That shouldn't be necessary, at least to
SDLs crappy doku, but without the subsequent SDL_GetWindowDisplayMode()
call fails with 'Invalid Window'. Use that call to check if we're now
in the requested mode. If yes, process. If not abort and trigger the
fallback magic. It'll set `r_mode 4` and `vid_fullscreen 0`.
Caveat: In the worst case this will switch the display mode 3 times.
To create the window, to work around the bug and to set a refresh rate.
No problem for flat panels, but my unforgotten Trinitron CRT would
have cried in pain.
* Normaly SDL chooses a sane refresh rate for fullscreen windows. Users
may want to override that, so provide a new cvar `vid_rate`. If it's
set to a value greater than 0, we're trying to get a mode close to the
requested resolution and refresh rate and switch to that.
* A bug in SDL may leave us in the wrong mode, detect that condition and
abort. See https://bugzilla.libsdl.org/show_bug.cgi?id=4700 for details.
This is part of issue #302.
Print a list of all available modes as soon as SDLs video backend
initializes and the real display mode after the window was created
or altered.
This hopefully helps debbuging problem with display mode selection, see
issue #302 for an example.
-Add back use of last_position_x and last_position_y
-last_position_x and last_position_y will be set to undefined when the window is shutdown IF the current display used is not the desired display
-last_display will be set to desired display at window shutdown if not the same
-vid_displayindex clamped using ClampDisplayIndexCvar() at startup and window shutdown
-We only need to init the display indices once in GLimp_Init
-We only need to clear the display indices once in GLimp_Shutdown
-Remove extra 'displayindex' variable
-SDL_GetNumVideoDisplays() will always remain the same after the call to SDL_Init(SDL_INIT_VIDEO), so it makes sense to set in GLimp_Init where we do this.
Otherwise the entities origin might be in the surface, which causes it
to be rendered in full black. This fix is a port from KMQuake2, reported
by @m-x-d. Closes#407.
There's an "enable alt joy keys" command now. If a key is bound to that
command, all joystick buttons (incl. hat and triggers) are turned from
K_JOYx into K_JOYx_ALT, which allows two keybindings on the same key,
one with the altselector pressed and one without.
If there's no keybinding for K_JOYx_ALT, it will use the binding for
just K_JOYx as a fallback (if it exists).
This is especially handy to create direct bindings for all the weapons
on the (limited amount of) Joystick buttons.
Seems like AMDs Windows driver doesn't like it when we call
glBufferData() *a lot* (other drivers, incl. Intels, don't seem to
care as much).
Even on an i7-4771 with a Radeon RX 580 I couldn't get stable 60fps
on Windows without this workaround (the open source Linux driver is ok).
This workaround can be enabled/disabled with the gl3_usebigvbo cvar;
by default it's -1 which means "enable if AMD driver is detected".
Enabling it when using a nvidia GPU with their proprietary drivers
reduces the performance to 1/3 of the fps we get without it, so it
indeed needs to be conditional...
use GL3_BufferAndDraw3D() instead of glBufferData() and glDrawArrays()
in each place it's needed.
This by itself doesn't make anything faster, but it will make trying out
different ways to upload data easier.
The developers tested their maps without the fix and decided that it
looked good. Add a new cvar gl_fixsurfsky defaulting to 0 that enables
the fix if someone really want it.
The software renderer already did this, but not the GL renderers. Maybe
the logic was lost somewhere on the long way... Without this change a
fullbright lightmap is generated for SURF_SKY surfaces and without the
SURF_DRAWSKY flags the surfaces aren't skipped in RecursiveLightPoint()
and GL3_LM_CreateSurfaceLightmap(). This isn't a problem under real
skyboxes, but in cases were SURF_SKY is abused fpr interior lightning.
rmine2.bsp in rogue is a good place to see the problem
Reported by @m-x-d, fixes#393.
At least with MinGW on Windows vsnprintf() treats buffer < size as an
error, returning -1 instead of the number of characters that would have
been printed without size restrictions. Therefor msgLen may be wrong,
leading to all kind of funny mistakes further down below... Buffer
overflow included. Work around this by handling the msgLen < 0 case and
adding an explicit terminating \0.
This is another case of "I wonder why nobody has never noticed this",
the GL1 renderers extension string triggered the buffer overflow each
time the game started.
I guess it makes sense to apply gamma to the color, we do the same
for the standard round particles.
Also, this way the fragment shader for square particles references the
uniCommon UBO (gamma is part of it) - apparently the Intel HD4000
(from Ivy Bridge) GPU driver for Windows has a bug that uniform blocks
that exist in the shader source but aren't actually used can't be found
(with glGetUniformBlockIndex(prog, name)), which we treat as an error
in gl3_shaders.c initShader3D().
fixes#391
If the vsync is enabled missuse it to slow the client down, e.g.
calculate the target framerate, add an security margin of 20% and
let the vsync handle the rest. This hopefully solves some problems
with frametime spikes. This is an idea by @DanielGibson.
If the vsync is disabled use a simple 1s / fps calculation.
GetSystemTimeAsFileTime() is okay as long as the game runs fullscreen.
For some reasons it's resolution degraded to ~16ms as soon as the game
runs widowed... Better use GetPerformanceCounter(), its more reliable
and the recommended API for timecounters.
Apparently the lightsource for exploding rockets/grenades is very close
to the surface, so the dot-Product between surface-normal and the
vector between the light and the pixel returns 0, basically disabling
the dynamic light for that surface.
As a workaround, move the lightposition (only for that dot product)
a bit above the surface, 32*surfaceNormal looks good.
fixes#386
The real needed size can't be derived from the .bsp file size, because
* many generated structs contain pointers
* there's lots of data generated per face..
* _especially_ for warped faces that are subdivided
introduced FS_GetFilenameForHandle(fileHandle_t) for this
this helps if a map has been started with "wrong" case, which doesn't
immediately fail if it has been loaded from a pack, but will result
in invalid savegame names that (with case-sensitive FSs) will fail to
load (when going back to a formerly played level)
The r1q2 code prioritized pak files over all other files, e.g. as soon
as a pak file was requested no more file were added to the download
queue until it finished downloading. That way one could be sure that
assets included in the pak file weren't downloaded in parallel as single
files.
This is a better, bugfixed and more robust implementation of the same
logic. With this back in place we can switch back to parallel downloads
which gives a nice speedup on Windows. Maybe, just maybe some day
Microsoft will fix Windows crappy I/O...
Working with getter and setters was a good idea as long as we had one or
two quirks. Now we're at three with maybe more to come so it's easier to
use a struct to communicate quirks between the precacher and the HTTP
download code.
The stores it's text in the key_lines array which is NUM_KEY_LINES *
MAXCMDLINE chars long. The code never checked for overflows, it just
assumed that a line will never be longer then 256 chars * 8 = 2048
pixel. With modern displays we can have higher vertical resolutions,
so the array will overflow sooner or later.
Fix it by clamping the maximum line width to MAXCMDLINE - 2 chars (1
for the prompt and 1 for the terminating \0). While at it increase
MAXCMDLINE to 1024 chars * 8 = 8192 pixel, which is more then 8k
resolution and should be enough for the years to come.
This is belived tot fix at least a part of issue #368.
While loading a savegame the global edict arrays is free()ed and newly
malloc()ed to reset all entity states. When the game puts the first
client into the server it sends it's entity state to us, so as long as
there's only one client everything's okay. But when there're more
clients the entity states if all clients >1 are dangeling. Hack around
that by reconnecting the clients >1 entity states "manually".
I'm not 100% sure if this is okay for q2pro, but at least in my simple
tests r1q2, q2pro and now yq2 generate the same URL. Nevertheless it's
somewhat inconssistent to search generic files at /moddir/... and the
filelist at /moddir.filelist
This closes issue #370.
Until now the softrenderer calculated the fov relative to a hard coded
aspect of 4/3. That's wrong, because we're supporting arbitrary aspects
and we aren't calculating a fov but just a scaling factor to the global
fov which takes the aspect into the account.
Fix this by not taking any aspect calculations into account. BUT: While
this renders the gun with a correct perspective it's positioned much
nearer to the camera / player then in the GL renderers. The GL renderers
work around that problem by enforcing a minimal Z distance of 4 units,
which can't do because we're just calculating a scaling factor...
This fixed bug #357 - the problem was that
client->resp.coop_respawn.weapon and .lastweapon (pointers to gitem)
were not properly initialized when loading a savegame.
Now those fields are saved (=> we had to bump the savegame version)
and for old savegames client->resp.coop_rewspawn is initialized
from client->pers, as a hack for backwards-compatibility.
Until now the UDP download code prohibited downloading of maps from all
pak files. That was some kind of copy protection, without the limitation
demo users could download assets from the full version. Don't apply that
protection for all paks, but only for numbered .pak files.
This could be enhanced by limiting the protection to pak0 to pak2 for
baseq2 and pak0 for both xatrix and rogue.
The r1q2 URL generator was, like everything in this game, buggy. It took
cl.gamedir into account when generating the URLs, but overlooked that it
is only set when 'gamedir != BASEDIR'. So baseq2 assets ended up with
/maps/foo.bsp and mod assets with /mod/maps/foo.bsp. q2pro fixed that
to always include the gamedir...
Work around this by refactoring the HTTP -> UDP fallback logic to be
more generic: Count the number of iterations and depending on the
iteration set the gamedir to be used by the URL generator or force
UDP downloads.
Cleaning the download queue as soon as a file finished downloading leads
in combination with only one parallel download and multiple precacher
runs to an ugly problem: The generic filelist is requested several time
which can lead to cycles. Hack around this by rembering if we already
requested it and reset set reminder as soon as the precacher finished.
Yes, I'm feeling dirty.
If the server sends us an URL with trailing slash we're generating URIs
like http://example.com//maps/foo.bsp. While double // are perfectly
valid they might me rejected by some servers. So let's play save.
While at it replace the crappy Z_TagMalloc() with the standard malloc().
Z_TagMalloc() ist just a wrapper arround malloc(), there's no functional
change.
This looks easy, but is rather hacky... Downloading is implemented
through the precacher. The server sends an asset list, while loading
the map another one is generated. CL_RequestNextDownload() goes
through this list, in the order models / maps -> sounds -> images,
calls CL_CheckOrDownloadFile() for each file. CL_CheckOrDownloadFile()
checks if the file is already there, return true if it is and false
if not. If the return code is false CL_RequestNextDownload() itself
returns, it's called again by CL_ParseDownload() as soon as the just
queued file finished downloading. This way all missing files are
downloaded one after the other, when CL_RequestNextDownload() finally
reaches it's end (all files are there) it send 'begin' to the server,
thus putting the client into the game.
HTTP downloads are parallel, so CL_RequestNextDownload() cannot track
which files are there and which are missing. The work around for that is
to queue the file but have CL_CheckOrDownloadFile() return true. So
CL_RequestNextDownload() thinks the file is already there, continues
with the next one, until all missing files are queued. After that it
polls CL_PendingHTTPDownloads() and sends the 'begin' as soon as all
HTTP downloads are finished.
If a HTTP download fails we cannot just queue it as UDP download,
because the precacher things that the file is already there. And we
can't tell the precacher that it's not because the precacher tracks
files only by the number of downloaded files per asste type and not
their name. Just decreasing the number of downloaded files isn't
possible since the precacher may have progressed to the next asset
type.
So: On the HTTP side it's tracked if there was an error or not. After
CL_RequestNextDownload() has queued all files and waited for all HTTP
downloads to finish it checks the HTTP error status. If there was an
error the precacher state is reset and CL_RequestNextDownload() recurses
into itself to take another run. All files that couldn't be downloaded
are queued again, this time as UDP downloads.
My solution to this problem is somewhat hacky. A newly added function
OGG_SaveState() can be called to save the state and OGG_RecoverState()
at a later time to restore it. There's only one state and it works
only iff OGG is state playing.
This closes#347.
If we're passing file handles to libcurl to write the data into, the
game may crash under Windows due to incompatible C runtimes between cURL
and quake2. This is even mentioned in the official cURL doku.
Since the moment I took a very first look at the download code I wasn't
a friend of parallel downloads. There're several reasons for that:
- Parallel downloading needs some ugly hacks. For example downloading a
pak file has a high chance to make asset downloads running in parallel
unnecessary.
- Parallel downloads are hard to debug.
- There's just no need for them. I've tested several connection, 1
GBit/s LAN, 50 MBit/s DSL, 6 MBit/s DSL, and there wasn't a
significant difference between 1, 4 or even 16 parallel downloads.
I'm leaving the parallel download code in place. I someone really wants
parallel downloads he can bump the MAX_HTTP_HANDLES define.
The signal handler was always fishy since it modified the global process
state but worked on all common platforms. libcurl turns the process into
a multithreaded environment, thus breaking that fragile construction.
After the signal handler was called the global state is inconsistent and
there's a high chance of things going wrong. For example at the net curl
download or when setjmp() is called in Qcommon_Frame().
Until now download queues entries were created for each file, but only
removed in the unlikely event of changed download server. This leaked
about 4200 byte per file. Fix this by:
- Create a new function CL_RemoveFromQueue() that removes a queue entry
and call it everytime when a download either finished, failed or
aborted.
- Retire the 'download done' state, just the queue entries associated
with a download handle to NULL to communicate that the handle is
unused.
- Cleanup the full queue at shutdown.
Loading libcurl at runtime instead of linking it at compile time makes
things a lot easier and more reliable on Windows. On other platform
libcurl can be installed as optional dependency instead as an hard one.
We're printing only the two relevant informations: A download was queued
and a download finished or failed. That's enough to see what's going on
and not too noisy.
...and fix the bugs, that were worked around with that crap, instead.
This removes some corner cases like cancelation of all HTTP downloads
and fallback to UDP if too many 404 errors were generated. If this is
still a problem in reality - for example HTTP servers blocking the
client after too many 404 or even crashing HTTP server - fix the server
and don't force the clients to work around that.
We aren't in 1997 anymore, todays broadband connections are fast enough
to handle multiple large files. This may download some assets twice if
the server provides both a pak file with all assets and the assets as
plain files.
There's no need to parse the HTTP header on our side of things, CURL can
do that. And the old buffer code was overcomplicated, simplify it. While
at it switch to normal malloc().
While the download speed calculations may be useful their implementation
is crappy and the integration into the console is rather fragile. If we
really want to support the progress bar with HTTP downloads this needs
to be reimplemented.
The URL generation logic was buggy, it took the local fs_gamedir into
account when determining the files path on the server. That could have
worked in r1q2 or q2dos since they assume that the executable dir is
also the config dir. But it breaks in YQ2 were the executable dir and
the config dir differ.
These are:
- CL_ResetPrecacheCheck(): Resets the precacher, forces it to reevaluate
which assets are available and what needs to be downloaded.
- FS_FileInGamedir(): Checks if a file (and only a real file, not
somthing in a pak) is available in fs_gamedir.
- FS_AddPAKFromGamedir(): Adds a pak in fs_gamedir to the search path.
This is a very first cut:
* It compiles
* It doesn't crash
What's missing:
* cmake integration
* CURL should be loaded dynamically
* Integration between download code and filesystem
* Likely UTF-8 stuff
* cl_http.c needs cleanup
* Windows support
We're taking indices and converting them to pointer relative to the
hunks base. Yes, that's dirty. Since the indices are stored as 32 bit
values and hunks are generally small using 32 bit pointers is enough,
even on 64 bit platforms. So the code took the size of void* / 2...
See the problem? Yes, that's not a good idea on 32 bit platforms. Bite
the bullet and just take the size of void*. Shouldn't be a problem,
because the indices are the first thing that's loaded and the hunk is
trimmed right after it anyways. If, and just if, we really need each and
every byte in the early stages of map loading we need two cases. One for
64 bit and one for 32 bit.
This fixes issue #346. Kudos to @ricardosdl for the analysis.
Lost time is time that we spend but didn't account. So the lost time
doesn't shorten a second (in fact that would mean that we'll lose the
time twice), it lengthen a second. Since has a small but noticeable
impact on timing when running with vsync enabled.
In src/backends/unix/network.c:
* line 181: Assignment of function parameter has no effect outside the function. Did you forget dereferencing it?
* line 276: The scope of the variable 'tmp' can be reduced.
* line 665: The scope of the variable 'mcast_addr' can be reduced.
* line 665: The scope of the variable 'mcast_port' can be reduced.
* line 666: The scope of the variable 'error' can be reduced.
* line 775: The scope of the variable 'i' can be reduced.
In src/backends/windows/network.c:
* line 186: Assignment of function parameter has no effect outside the function. Did you forget dereferencing it?
* line 287: The scope of the variable 'tmp' can be reduced.
* line 707: The scope of the variable 'mcast_addr' can be reduced.
* line 707: The scope of the variable 'mcast_port' can be reduced.
* line 1049: The scope of the variable 'err' can be reduced.
* line 1163: The scope of the variable 'i' can be reduced.
In src/client/menu/menu.c
arrayIndexOutOfBounds:
* line 1921: Array 'creditsIndex[256]' accessed at index 256, which is out of bounds.
variableScope:
* line 332: The scope of the variable 'item' can be reduced.
* line 533: The scope of the variable 'x' can be reduced.
* line 533: The scope of the variable 'y' can be reduced.
* line 838: The scope of the variable 'b' can be reduced.
* line 864: The scope of the variable 'b' can be reduced.
* line 1910: The scope of the variable 'n' can be reduced.
* line 2199: The scope of the variable 'str' can be reduced.
* line 2812: The scope of the variable 'length' can be reduced.
* line 2813: The scope of the variable 'i' can be reduced.
* line 3838: The scope of the variable 'c' can be reduced.
* line 4112: The scope of the variable 'scratch' can be reduced.
* line 4181: The scope of the variable 'i' can be reduced.
* line 4345: The scope of the variable 's' can be reduced.
In src/game/player/hud.c
arrayIndexOutOfBounds:
* line 132: Array itemlist[43] accessed at index 255 which is out of bounds.
Itemlist assigned only once, and has only 43 items, better ignore unexisted items.
variableScope:
* line 82: The scope of the variable 'n' can be reduced.
* line 217: The scope of the variable 'x' can be reduced.
* line 217: The scope of the variable 'y' can be reduced.
* line 218: The scope of the variable 'cl' can be reduced.
* line 583: The scope of the variable 'cl' can be reduced.
With this change the code matches the comment. While most packet frames
are renderer frames, we must not take the render frame time into account
when calculating the average time spend processing the packet frames. I
dont's think that this change makes any measureable difference since the
packet frame time is just a very small fraction of the renderer frame
time.
I guess that these calls were added since dlopen() might ignore the
global LD_LIBRARY_PATH if EUID != UID. In Yamagi Quake II this isn't
a problem because we're enforcing EUID == UID in main() and don't use
LD_LIBRARY_PATH anyways.
These calls broke the jack audio server and maybe some other programs.
The problem was debugged by @ScrelliCopter. This commit closes issue
#270.
* Take the cache line roundings into account when allocating a hunk.
* Use size_t were apropriate.
* remove some unnecessary and likely broken calls.
Another case of: "How could this ever work"?
We need to reset the avgrenderframetime and avgpacketframetime variables
when we recalculate the average times spend rendering frame and / or
processing package frames. Otherwise the result will be much too high,
leading to lost frames down below. I wonder why nobody complained about
this until now.
While at it lower the security margin from 2% to just 1%. On the one
hand we need a small security margin, because Quake II is not that
precise and out average times spend may be too low. On the other hand
the margin must not be too large, because the bigger the margin is the
bigger is the risk of missing frames... Both 2% and 1% is very small,
in fact often they don't even make a difference because of float ->
int conversations. For example 16 * 0,02 = 0,32 -> cut to 0. But there
are some extrem cases were it matters and my empirical testing showed
that 1% is slighty better then 2%. At least on my system. An it's
better to f*ck up the timing for a small number of frames than missing
a frame. A broken timing is hard to recognize, a missed frame is much
more annoying.
In issue #296 it was pointed out that the menu shows ogg_shuffle
always as disabled, even if it's set to 1. This was an oversight,
the menu code was still checking the ogg_squence cvar removed in
the big OGG/Vorbis refactoring. Update it to match reality.
@DanielGibson pointed out that _SC_PAGESIZE itself is too big,
_SC_PAGESIZE - 1 is correct. Also apply a small performance
optimization by querying _SC_PAGESIZE only once.
This prevents gibs and debris being easily destroyed with the rocket
launcher but leaves enough room for the entities being destroyed by
elevators, doors and the like if necessary.
The gibs and debris per frame must be limited to prevent server mem
map overflows. Until now debris and gibs were handled the same, the
debris spawned by rockets and grenates could prevent the actual gibs
of the killed monster from spawning.
Before this change 20 entities were spawned at max. Now up tp 40
enties can be spawned. This needs some testings.
Fixes issue 323.
A long time ago in 2b4f223 I introduced a small logic change to the
handling of stacked entities. If two entities were standing on each
other the original code set the movement speed of the upper entity
to 0. It would be pushed or dragged by the lower entity. I changed
that in way that the upper entity got the same speed as the lower
entity. With that change it wasn't pushed or dragged but moving on
it's own. I hoped to fix some of the 'elevator hurts player or monster'
bugs.
That hope was wrong, at a later time we quirked all elevators that hurt
the player. Additionally the change lead to physics bugs if entities are
standing on high speed elevators (more than 200 units per seconds). So
revert it.
The actual fix was already committed as part of 69b6e5a. This is just a
little cleanup commit, mainly for documentation purposes.
This closes#320.
When killing the enforcer with one shot (instead of damaging him first
without killing, which will switch to the bloody skin), the skin wasn't
changed. Now it is.
1) Do not increment the frame rate returned by SDL by 1. Incrementing
is unnessecary, more or less up to date versions on Nvidias, AMDs
and Intels GPU driver on relevant platform return an value that's
either correct or rounded up to next integer. And SDL itself also
rounds up to the next integer. At least in current versions. In fact,
incrementing the value by one is harmfull, it messes our internal
timing up and leads to subtile miss predictions. Working around that
in frame.c would add another bunch of fragile magic... So just do
it correctly. If someone still has broken GPU drivers or SDL versions
that are rounding down the could set vid_displayrefreshrate.
2) The calculation of the 5% security margin to pfps in frame.c was
wrong. It didn't take into account that rfps can be slightly wrong
in the first place, e.g. 60 on an 59.95hz display. Correct it by
comparing against rfps including the margin and not the plain value.
Until now the server just called remove() to delete the servers state
from the HDD. That was fine on Linux were UTF-8 is used but failed
silently on Windows in case that the working dir path had some Unicode
characters. Replace remove() by Sys_Remove(), on Linux it's just a
wrapper around remove() on Windows it does a UTF8->UTF-16 conversion
and calls _wremove(). This fixes issue 318.
After some pondering I realised that the changes was stupid. It
introduces some new subtile bugs, for example in some cases SDL
still rounds 59.95hz down to 59hz...
In the old world GLimp_GetRefreshRate() was called once at renderer
startup. Now in the new world with SDL 2.0 only it's called every frame
and thus the target framerate git increased by one every frame... That
lead to subtile timin problem in case that the vsync is enabled.
While here remove the hack added for some Windows GPU drivers by AMD.
Older versions returned 59 on 59.95hz displays, leading to small timing
problems. This is fixed in newer version so we don't need to work around
it. Removing the hack gives us somewhat more overall timing precision.
If someone really needs the hack vid_displayrefresh can be set to 60 to
get the old behaviour.
Until now we just called OGG_Stop() as soon as we read the last samples
from a Vorbis files. OGG_Stop() flushed all unplayed samples (about 12
seconds of playback) from the OpenAL playback queue... Instead just set
our internal state of STOPPED, open the next file and be done.
Make sure that the window is destroyed at gl renderer shutdown and
recreated by the soft renderer. Don't deinitialize SDL in the
softrenderer, that's done by vid.c. And make sure that we start the soft
renderer with a clean GL state.
I've chosen the minimal invasive way for this:
* Import miniz and remove -lz linker flags.
* Create a short header minizconf.h roviding everything we need
originally defined by zconf.h and not provided by miniz.
* Replace zlib.h with miniz.h and minizconf.h.
The input system backend was once used in the client and the renderers,
but for some years now it has been an integral part of the client only.
Move it there.
The last commits did some bigger changes to the interaction between the
GL renderers and the client. The code is now SDL 2.0 conformant, window
and context creation are strictly distinct operations. SDL is only
initialized when necessary. Since this broke the client <-> renderer
API, bump it's version.
There a lot of things left to do for dark and cold winter evenings:
* The software renderer implements it's own window handling and
reinitialized SDL whenever vid_restart is called. This is highly
problematic.
* vid_fullscreen is abused to communicate changes to renderer config
throughout the code. That's a very ugly, messy and potential very
problematic hack. But not easy to remove.
* Some funtion calls between the client and the renderer are
unnecessary.
The changes to the client <-> renderer interaction fixed issue #302.
In the old world we deinitialized and reinitialized SDL each time we
restarted or changed the renderer. That would clear the whole GL state.
In the new world we let SDL running and just recreate the windows. In
some cases parts of the old renderers state would leak into the new
renderer, leading to strange problems.
* Sync both files as much as possible.
* Another round of general cleanup.
* Fix stencil tests.
* Simplify gamma handling, hardware gamma is now default.
* Support new client <-> renderer API.
* Another round of general cleanup.
* Introduce gl3_libgl cvar to force a libGL.
* Fix stencil buffer tests.
* Further untangle window <-> context stuff.
The window is now fully at client side, the context at renderer side.
This is another break of the renderer API. And at least GL1 needs to
track this, it's broken for now.
* Even more syntax and code style fixes.
* Rename functions to match their actual purpose.
* Fix comments.
* SDL initialization and shutdown is now client side only. With
SDL 1.2 finally gone there's no need to involve the renderers
in it.
This breaks the client <-> renderer API. I haven't bumped the API
version with this commit because there're likely more changes when
I'm going through the renderer side of things. The VID backend also
needs a lot of love...
It might be a good idea to move this SDL backend files into the client
and rename them. We'll decide that at a later time.
* Some globals could be made static.
* Add comments were appropriate.
* And format the file to one coding stile. What is so hard with
keeping to one style?! MY IDE is even able to interfere the
style from existing code...
