For example, on Windows with AMDs drivers, GLES3 isn't supported,
so CreateSDLWindow() will fail. We should just try the regular GL3
renderer then instead of exiting with Com_Error()
Also make (Windows') Sys_Error() print to stdout (in addition to stderr),
so errors end up in stdout.txt as well (like all other messages).
SDL2 provides different gyro readings between Windows and Linux/Mac for
the Switch Pro Controller. To keep the natural sensitivity scale intact
(in-game turn = controller turn), the normalization factor is handled
differently by platform, at least for now.
Also, now giving info when there's no gyro sensor available/detected.
And green light for the DualShock 4, because why not :)
Cvar to choose between "yaw" (0) or "roll" (1) axis of the controller
to turn (change your yaw) in-game.
Cvars to change pitch and yaw gyro sensitivities.
Updated cvar documentation with new section "Game Controller".
SDL 2.0.16 and a controller with a gyroscope required to make it work.
Manual calibration of the gyro sensor is needed to avoid "drifting"; a menu
option to do it is included.
New cvar 'gyro_mode' for mode of operation, and to assign action to the new
"+gyroaction" button: disable or enable the gyro.
Several effects use dlights which are rendered for only one frame.
Muzzle flashes are an example. While this worked on 1997th computers,
todays hardware renders way too many frames for these dlights to be
visible at all. Work around that by enforcing a minimal display time
of 32 milliseconds for each dlight.
Fixes part of #815.
When a key/button name is too long, and its bound to an inventory element, its
display in the inventory screen misaligns the item it is bound to, even pushing
it out of the inventory frame.
This commit limits its display to the maximum of 6 characters the inventory
screen allows.
Adds menu bitmap struct, drawing of a menu bitmap and highlighting if bitmap menu item is in focus.
Allows items that are gray (inactive) to be skipped when adjusting the menu cursor.
Removed switch case from Menu_SelectItem, all items either do or do not call their callback functions.
.. by running a packet frame if the current renderframe is closer to
the time the packet frame *should* be run than the next renderframe
(presumably) will be.
This should also help when using cl_maxfps -1 on a slow system that
can't reach the desired rfps (vid_maxfps or display refresh rate).
Without this change, we might run int the problem described in the
following example:
Imagine having cl_async 1, cl_maxfps 100, no vsync and a system that
mostly only reaches about 60fps. So rfps is 100 and pfps is 50.
But then (without this change) running at 60fps means that only every
second renderframe is a packetframe, so the packetframerate
*effectively* is 30, which can cause movement/clipping/physics bugs
(for example when hugging some non-perpendicular walls, like the right
wall with the window that leads to the last room in base1).
With this change the packet framerate would effectively be 60 (every
renderframe is also a packetframe), which is less buggy and also closer
to 50 than 30 is.
(this is the default value of that cvar now)
In Qcommon_Frame(), if cl_async is 1, the packet framerate should
ideally be a fraction of the render framerate, and to avoid movement
glitches and such it should be between 45 and 90, ideally around 60.
With cl_maxfps set to -1, pfps now is set to such a value automatically.
When setting rfps based on GLimp_GetRefreshRate() and vid_maxfps,
take into account that GLimp_GetRefreshRate() might return a value
that's slightly too low (like 58 or 59 when it's 59.95 and should be 60)
The 20% tolerance that, in case of vsync enabled, used to be handled
with `packetdelta < 0.8 * 1000000/pfps` (and the same for rfps) is now
instead added to rfps (and thus implicitly pfps, if it's >= refreshrate)
It could make things stutter, especially if cl_maxfps was deliberately
set to a fraction of the display refreshrate (as it'd target a few
frames less).
The 0.95 factor was supposed to ensure that we don't have more packet
frames than renderframes (or two packet frames in a row without
rendering in between), as that apparently breaks the movement prediction
code. We now ensure the same thing my not running a packet frame if no
render frame is run at the same time.
May be unreliable on some devices, e.g. Nintendo Switch Pro Controller.
Works great on others, e.g. DualShock 4.
Delay added to gamepad initialization on hotplug, gives time to the OS to
recognize the device.
Allows to bind buttons that only will work with "+joyaltselector" active.
The definition of another "scope" of keys was needed, to identify ALT bindings.
Handles game controller button bindings exclusively.
Classic "customize controls" option now handles only keyboard / mouse bindings.
This separation is achieved with the new order of QKEYS in keyboard.h, and
binding functions in menus (especially "MenuKey" functions) now take into
account the "scope" where they operate: keyboard/mouse only, controller only,
or both.
Streamlined menu inputs by making most "*_MenuKey(key)" functions to use
Key_GetMenuKey(). "Backspace" is not a special case anymore, so any menus
that have a "delete" option can already handle any input expected, like the
backspace or delete keys, or the "Y" button of the controller, to run it.
Also, fixed a bug where changing the key for "team chat" also changes the one
for "chat" in the "multiplayer" -> "customize controls" menu.
This removes the usage of SDL_Joystick for joystick buttons and hat, and
relies exclusively on SDL_GameController for input. This allows to identify
buttons in a consistent manner across multiple types of controllers, which
in turn allows to assign specific tasks to them without worrying of breaking
usability, like having "A" to accept and "B" to cancel in menus.
Init and Shutdown logic of game controller have been separated from main SDL
Init and Shutdown functions.
Old style button names "JOYx" have been removed.
If your gamepad has paddles or other extra buttons, you'll need at least
SDL version 2.0.14 to use them.
because on some systems (like RPi4 with my experimental GLES3 branch)
the overhead of a FBO is really noticeable, so no reason to pay for it
when it's not needed
Can be disabled with gl3_usefbo 0.
Mostly this adds an underwater warping effect, like the soft-renderer,
and also like the vulkan renderer (the shader is based on the vk one).
When this is enabled, the v_blend effect (for fullscreen overlay with
one color, like when hit or to make the screen white-ish when under
water) is now applied in the shader used for rendering the FBO instead
of rendering a fullscreen quad in blendmode.
This fixes the framecounter in the soft renderer when `viewsize` is set
to something smaller than 100. This requires the renerer to rerender
bigger parts of the borders which has a measurable speed impact. About
5 frames less with the framecounter enabled on my system. No impact with
`viewsize 100`.
The GL renderers require that the borders are redrawn after every
glClear() call, the damage tracking doesn't take that into account.
Since the speedup by the damage tracking is neglibiable in the GL
renderers, don't use it. Just redraw everything when we're running
with everthing which isn't the soft renderer.
I think this looks ugly, I always called it nightmare and it was one of
the first changes I've made to Quake II. But for the sake of peace and
quiet change it to be standard conformant. Closes#809.
both if GL pointparameters are used or not
(though depending on driver and hardware the pointparameters-based
particles *might* be always square or always round, regardless of
gl1_particle_square - that's driver-bugs which we can't fix, disable
pointparameters with `gl1_pointparameters 0` to work around it, or
just use the GL3 renderer)
r_lerp_list is to allow exceptions to r_2D_unfiltered (like for having
pixely UI in general, but filtered console background).
r_videos_unfiltered controls whether videos should be filtered or not
I also made r_nolerp_list CVAR_ARCHIVE, like users probably expect it.
