Commit graph

747 commits

Author SHA1 Message Date
Bill Currie
8a411dc120 [joy] Clean up some redundant cvar flags
No need to or CVAR_NONE with other flags.
2022-04-24 17:23:46 +09:00
Bill Currie
b02e29ea89 [x11] Clear up some signed/unsigned ambiguity
I don't remember what gcc does with unsigned-int, but obviously clang
produces another unsigned, which is most definitely not wanted.
2022-03-31 00:34:40 +09:00
Bill Currie
63e5655f68 Clean up some enum sanity checks
It seems clang defaults to unsigned for enums. Interestingly, gcc was ok
with the checks being either way. I guess gcc treats enums that *can* be
unsigned as DWIM.
2022-03-31 00:18:53 +09:00
Bill Currie
d53b0b0064 [sw] Clean up use of vid.colormap8
The main goal was to not update the colormap pointers when only the
viewport or fov changed.
2022-03-29 14:43:38 +09:00
Bill Currie
18aae8205e [glsl] Implement screen warp when in liquids
Finally, after a decade :P Looks pretty good, too, and is (almost)
properly scaled to the resolution (almost because the effect is a little
squashed, but I think the sw renderer does the same).
2022-03-25 09:01:27 +09:00
Bill Currie
00362e9f4e [gl] Explicitly request compatibility profile
And core profile for glsl
2022-03-25 09:01:11 +09:00
Bill Currie
0c437492b4 [renderer] Move to using dynamic frame buffers
For now, OpenGL and Vulkan renderers are broken as I focused on getting
the software renderer working (which was quite tricky to get right).

This fixes a couple of issues: the segfault when warping the screen (due
to the scene rendering move invalidating the warp buffer), and warp
always having 320x200 resolution. There's still the problem of the
effect being too subtle at high resolution, but that's just a matter of
updating the tables and tweaking the code in D_WarpScreen.

Another issue is the Draw functions should probably write directly to
the main frame buffer or even one passed in as a parameter. This would
remove the need for binding the main buffer at the beginning and end of
the frame.
2022-03-24 12:56:29 +09:00
Bill Currie
4c90c3c4bb [sw] Remove pixbytes from sw_ctx_t
It's no longer needed as the sw renderer is 8-bit only.
2022-03-21 14:37:28 +09:00
Bill Currie
b82a353a20 [vid] Remove VID_InitBuffers
Its guts have been moved to D_Init temporarily while I work on the
frame buffer design. This is actually a big part of that work as it
moves most of the frame buffer creation into the one place, making it
easier to ensure I get all the sub-buffers and caches created.
2022-03-21 14:35:11 +09:00
Bill Currie
3b4608a0cd [vid] Update glx handling to ensure GL 3.0
With what I have planned for frame buffers etc, GL 3.0 will be needed
even for the fixed-function GL renderer, and then I might even take the
GLSL renderer to 4.6 (dunno yet). This means that wgl will need to be
updated too, and I've found the info I need for that, but it's a bit
much to take on just yet.
2022-03-20 12:52:20 +09:00
Bill Currie
5477352e93 [renderer] Abandon sw32 altogether
I'd been considering it for a while, but in the end, all the issues it
presented made me decide it wasn't worth merging and was never really
worth keeping: it was a neat proof of concept but of little actual use,
especially now everyone either has an OK GPU or would want to stick to
8-bit rendering anyway (sorry L-Havoc).

However, both it and my merge work are preserved in git history :)
2022-03-09 21:36:15 +09:00
Bill Currie
19348f678f [win] Get the software renderer hobbling
16 and 32 bit rendering are disabled at the moment because there's a
weird segfault I need to fix, but the 8-bit dynamic lights are doing
weird things (for x11, too) when updating the light maps.
2022-03-09 20:00:59 +09:00
Bill Currie
6377734e32 [renderer] Merge the two software renderers
I got tired of having to maintain two separate software renderers, but
didn't want to just nuke sw32, so its core changes are merged into sw.

Alias model rendering is broken, but I know exactly what's wrong and how
to fix it, just need to take care due to asm.
2022-03-09 15:56:19 +09:00
Bill Currie
5eb397dd31 [renderer] Remove more dead code
The back-buffer and video buffer locking code was pretty much never more
than stubs (except maybe in dos quake).
2022-03-07 08:44:53 +09:00
Bill Currie
45c3c6d7be [screen] Clean up some dead declarations 2022-03-05 14:35:56 +09:00
Bill Currie
3cb93d4cbe [input] Add functions to get single axis/button info
Handy for retrieving the current state (raw) of a single axis or button.
2021-12-24 06:45:13 +09:00
Bill Currie
83ec2be2a6 [vid] Add a listener set for palette changes
This was needed to get crosshaircolor working correctly, but is likely
another step towards resizable windows (the listener set types are
generic for any viddef event, not just palette changes).
2021-12-24 06:45:13 +09:00
Bill Currie
d76cf9202d [x11] Create barriers only when grabbing
While using barriers is a zillion times better than actually grabbing
the mouse and keyboard, they're still a pain when debugging as qf is not
able to respond to the barrier-hit events. All the other logic is still
there so even when "grabbing", the mouse will not be blocked if the
window doesn't have focus.
2021-12-06 07:27:08 +09:00
Bill Currie
8b85e422d7 [vulkan] Add a debug stack to the vulkan instance
The stack is arbitrary strings that the validation layer debug callback
prints in reverse order after each message. This makes it easy to work
out what nodes in a pipeline/render pass plist are causing validation
errors. Still have to narrow down the actual line, but the messages seem
to help with that.
Putting qfvPushDebug/qfvPopDebug around other calls to vulkan should
help out a lot, tool.
As a bonus, the stack is printed before debug_breakpoint is called, so
it's immediately visible in gdb.
2021-11-30 18:10:48 +09:00
Bill Currie
b01c38903d [x11] Clamp barriers to the screen
It seems X11 does not like creating barriers entirely off the screen,
though the error seems to be a little unreliable (however, off the left
edge was definitely bad).
2021-11-25 20:23:18 +09:00
Bill Currie
67735182d7 [x11] Protect XInput2 and XFixes code
This will allow QF to be built in the unlikely event XInput2 or XFixes
are not available. nq-x11 seemed to work nicely with both disabled.
2021-11-24 02:17:08 +09:00
Bill Currie
b45acf7974 [x11] Add a comment about grabbing design 2021-11-24 01:51:52 +09:00
Bill Currie
719525a4a1 [x11] Set backed mouse button state for raw presses
Fixes button press events being treated as button releases in the event
handlers.
2021-11-23 23:21:43 +09:00
Bill Currie
28b80d8bf8 [x11] Handle raw motion events (more) correctly
For now, only the first two axis (mouse X and Y) are supported (XInput
treats the scroll wheel events as axes too, so mice have up to 4!), but
most importantly, this prevents the scroll wheel from being seen as the
X axis. Oops.
2021-11-23 23:15:08 +09:00
Bill Currie
78b4e8217e [x11] Fix a optimization compiler warning
With the old headers removed, X11_SetGamma became a stub and gcc
complained about it wanting the const attribute. On investigation, it
turned out the X_XF86VidModeSetGamma was a holdover from the initial
implementation of hardware gamma support.
2021-11-23 12:44:21 +09:00
Bill Currie
af5d92708d [x11] Implement raw keyboard input via XInput2
UI key presses are still handled by regular X events, but in-game
"button" presses arrive via raw keyboard events. This gives transparent
handling of keyboard repeat (UI keys see repeat, game keys do not),
without messing with the server's settings (yay, that was most annoying
when it came to debugging), and the keyboard is never grabbed, so this
is a fairly user-friendly setup.

At first, I wasn't too keen on capturing them from the root window
(thinking about the user's security), but after a lot of investigation,
I found a post by Peter Hutterer
(http://who-t.blogspot.com/2011/09/whats-new-in-xi-21-raw-events.html)
commenting that root window events were added to XInput2 specifically
for games. Since application focus is tracked and unfocused key events
are dropped very early on, there's no way for code further down the
food-chain to know there even was an event, abusing the access would
require modifying the x11 input code, in which case all bets are off
anyway and any attempt at security anywhere in the code will fail,
meaning that nefarious progs code and the like shouldn't be a problem.
2021-11-23 11:39:48 +09:00
Bill Currie
0c1927d631 [x11] Remove -nomouse handling
After a lot of thought, it really doesn't make sense to have an option
to block mouse input in x11 (not grabbing or similar does make sense, of
course). Not initializing mouse input made perfect sense in DOS and even
console Linux (SVGA) what with the low level access.
2021-11-22 23:54:31 +09:00
Bill Currie
c3ce12de4c [x11] Use root window for barriers
It turns out that if the barriers are set on the app window, and the app
grabs the pointer (even passively), barrier events will no longer be
sent to the app. However, creating the barriers on the root window and
the events are selected on the root window, the barrier events are sent
regardless of the grab state.
2021-11-22 15:42:22 +09:00
Bill Currie
ce8eac5ca0 [x11] Send app focus loss/gain events
Other subsystems, especially low-level input drivers, need to know when
the app has input focus. eg, as the evdev driver uses the raw stream
from the kernel, which has no idea about X application focus (in fact,
it seems the events are shared across multiple apps without any issue),
the evdev driver sees all the events thus needs to know when to drop
them.
2021-11-22 14:59:32 +09:00
Bill Currie
e8a7e8218e [x11] Check hit barrier is valid before releasing pointer
It turns out to be possible to get a barrier event at the same time as a
configure notify event (which rebuilds the barriers), and trying to
release the pointer at such a time results in a bad barrier error and
program crash. Thus check the event barrier against the currently
existing barriers before attempting to release the pointer.

This does mean that a better mechanism for sequencing window
repositioning and barrier creation may be required.
2021-11-22 14:59:32 +09:00
Bill Currie
3ac6d2aa22 [x11] Use barriers to trap the pointer in the window
This should be a much friendlier way of "grabbing" input, though I
suspect that using raw keyboard events will result in a keyboard grab,
which is part of the reason for wanting a friendly grab.

There does seem to be a problem with the mouse sneaking out of the
top-right and bottom-left corners. I currently suspect a bug in the X
server, but further investigation is needed.
2021-11-22 14:59:27 +09:00
Bill Currie
3af078b77a [x11] Send app_window event when window moves
This is needed for getting window position info into in_x11 without
exposing more globals, and is likely to be useful for other things,
especially as it doubles as a resize event when that's eventually
supported.
2021-11-22 13:20:13 +09:00
Bill Currie
4391b87d04 [x11] Grab focus when the pointer enters the window
This is necessary in focus-follows-mouse environments (at least for
openbox, but it wouldn't surprise me if most other WMs behave the same
way) because the WMs don't set focus when the pointer is grabbed (which
XInput does before the WM sees the enter event). This is especially
important when the window is fullscreen on a multi-monitor setup as
there is no border to *maybe* catch the mouse before it enters the
window.
2021-11-21 23:42:33 +09:00
Bill Currie
a32f83d50f whitespace 2021-11-21 23:42:33 +09:00
Bill Currie
e45d19835c [x11] Add initial support for XInput2
Right now, only raw pointer motion and button events are handled, and
the mouse escapes the window, and there are some issues with focus in
focus-follows-mouse environments. However, this should be a much nicer
setup than DGA.
2021-11-21 23:42:33 +09:00
Bill Currie
4944c40f86 [x11] Remove the magic number for mouse buttons
The current limit is still 32. Dealing with it properly will take some
rather advanced messing with XInput, and will be necessary assuming
non-XInput support is continued.
2021-11-21 22:16:08 +09:00
Bill Currie
26a1f66b4e [x11] Split up in_x11_init into three stages
There's now IN_X11_Preinit, IN_X11_Postinit (both for want of better
names), and in_x11_init. The first two are for taking care of
initialization that needs to be done before window creation and between
window creation and mapping (ie, are very specific to X11 stuff) while
in_x11_init takes care of the setup for the input system. This proved
necessary in my XInput experimentation: a passive enter grab takes
effect only when the pointer enters the window, thus setting up the grab
with the pointer already in the window has no effect until the pointer
leaves the window and returns.
2021-11-21 21:22:11 +09:00
Bill Currie
95becc5c05 [x11] Add some braces around an if block 2021-11-21 21:16:55 +09:00
Bill Currie
fe2dd013be [x11] Clean out some unnecessary includes 2021-11-21 21:16:55 +09:00
Bill Currie
8988008ad6 [x11] Don't mess with the mouse when going fullscreen
This was always a horrible hack just to get the screen centered on the
window back when we were doing fullscreen badly. With my experiments
with XInput, it has proven to be a liability (I'd forgotten it was even
there until it started imposing a 2s delay to QF's startup).
2021-11-21 20:59:49 +09:00
Bill Currie
925a55f6cc [input] Allow drivers to initialize cvars early
Input driver can now have an optional init_cvars function. This allows
them to create all their cvars before the actual init pass thus avoiding
some initialization order interdependency issues (in this case, fixing a
segfault when starting x11 clients fullscreen due to the in_dga cvar not
existing yet).
2021-11-21 11:33:58 +09:00
Bill Currie
e080bb333c [win] Update windows input for new binding system
Seems to work nicely for keyboard (though key bindings are not
cross-platform). Mouse not tested yet, and I expect there are problems
with it for absolute inputs (yay mouse warp :P).
2021-11-19 13:52:40 +09:00
Bill Currie
b892ce637a [input] Nuke IN_Move from orbit
gotta be sure :)

On a serious note, it was always a problem in that it had
client-specific code and concepts embedded in the libraries.
2021-11-19 08:58:02 +09:00
Bill Currie
793914718f [x11] Implement input names
Mouse axis and button names are handled internally (and thus
case-insensitive).

Key names are handled by X11. Case-sensitivity is currently determined
by Xlib.
2021-11-18 13:01:33 +09:00
Bill Currie
7739972f19 [x11] Block raw inputs if cooked inputs are handled
The cooked inputs (ie_key, ie_mouse) are intended for UI interaction, so
generally should have priority over the raw events, which are intended
for game interaction.
2021-11-16 12:55:55 +09:00
Bill Currie
b95c749438 [input] Add a per-device event data pointer
This might pose a problem with multiple event targets (we'll see), but
it will make connecting input devices to bindings much easier.
2021-11-10 13:22:10 +09:00
Bill Currie
4898a44263 [console] Hook up new input system
This has smashed the keydest handling for many things, and bindings, but
seems to be a good start with the new input system: the console in
qw-client-x11 is usable (keyboard-only).

The button and axis values have been removed from the knum_t enum as
mouse events are separate from key events, and other button and axis
inputs will be handled separately.

keys.c has been disabled in the build as it is obsolute (thus much of
the breakage).
2021-11-08 11:20:04 +09:00
Bill Currie
6dc90c5497 [x11] Remove key focus and destination handling
I'm undecided on how to handle application focus (probably gain/lose
events), and the destination handler has been a stub for a while. One less
dependency on the "old" key handling code.
2021-11-05 14:56:27 +09:00
Bill Currie
31c1eae1ec [x11] Send key events for pasted text
I'm undecided if the pasted text should be sent as a string rather than
individual key events, but this will do the job for now as it gets me
closer to being able to test everything.
2021-11-05 14:54:33 +09:00
Bill Currie
0c8fbf0ce4 [x11] Don't use select for checking for events
It seems that under certain circumstances (window managers?), select is not
reliable for getting key events, so use of select has been disabled until I
figure out what's going on and how to fix it.
2021-11-05 13:30:01 +09:00