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
----
If I understand this right it only builds the dedicated server. I think
that Dockerfiles need to be at the project root. Nevertheless I put it
under stuff/, the root dir is already cluttered enough.
Closes#498.
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)
